On Tuesday, 29 September 2015 at 08:09:39 UTC, Ola Fosheim
Grøstad wrote:
But doesn't that imply a full scan when you are scanning for
common types that live on leaf nodes in the graph?
Yes, if you want to collect a very common type, you'd need to
scan many types.
But using typed allocations y
On Sunday, 27 September 2015 at 16:54:52 UTC, Martin Nowak wrote:
On 09/24/2015 03:49 AM, Ola Fosheim Grøstad wrote:
I haven't read the paper, but how does this solve collecting
things like strings, or other "leaf types" when you use
separate compilation units?
We'd use runtime typeinfo.
Bu
On 09/24/2015 03:49 AM, Ola Fosheim Grøstad wrote:
> On Thursday, 24 September 2015 at 00:08:18 UTC, Martin Nowak wrote:
>> The key to a low latency/high throughput GC is being able to
>> incrementally collect the heap. There is a very interesting paper that
>> uses the type system to perform incre
On Thursday, 24 September 2015 at 00:08:18 UTC, Martin Nowak
wrote:
The key to a low latency/high throughput GC is being able to
incrementally collect the heap. There is a very interesting
paper that uses the type system to perform incremental
collections.
http://forum.dlang.org/post/mcqr3s$c
On 09/18/2015 09:26 PM, Rory wrote:
> The new GC in Go 1.5 seems interesting. What they say about is certainly
> interesting.
>
> http://blog.golang.org/go15gc
>
> "To create a garbage collector for the next decade, we turned to an
> algorithm from decades ago. Go's new garbage collector is a con
On Tuesday, 22 September 2015 at 09:01:07 UTC, Chris wrote:
But that's very annoying to work with and more pain than gain.
I don't know... unique_ptr in C++ is quite ok for managing
resources, but it does not track "borrowed pointers". But as I
point out one can:
1. do it in runtime in debu
Am Mon, 21 Sep 2015 19:32:21 +
schrieb Ola Fosheim Grøstad :
> On Monday, 21 September 2015 at 18:28:19 UTC, jmh530 wrote:
> > My understanding is that the key benefit of Rust's system is
> > that compile time checks don't have the runtime costs of smart
> > pointers.
>
> + aliasing informa
On Tuesday, 22 September 2015 at 03:59:31 UTC, Ola Fosheim
Grostad wrote:
On Tuesday, 22 September 2015 at 02:15:51 UTC, jmh530 wrote:
Interesting. Not to resurrect the older D vs. Rust thread, but
I have heard it that it can be painful to do some things in
Rust. D often has the ability to do u
On Tuesday, 22 September 2015 at 02:15:51 UTC, jmh530 wrote:
Interesting. Not to resurrect the older D vs. Rust thread, but
I have heard it that it can be painful to do some things in
Rust. D often has the ability to do unsafe things, like disable
the GC. I was looking at how Rust has raw point
On Monday, 21 September 2015 at 19:32:23 UTC, Ola Fosheim Grøstad
wrote:
If the compiler can prove that two pointers point to
non-overlapping memory regions then the compiler can optimize
better. This is one of the reasons why Fortran compilers
managed to do better than C for a long time.
I
On Monday, 21 September 2015 at 18:28:19 UTC, jmh530 wrote:
My understanding is that the key benefit of Rust's system is
that compile time checks don't have the runtime costs of smart
pointers.
+ aliasing information.
If the compiler can prove that two pointers point to
non-overlapping memor
On Monday, 21 September 2015 at 11:01:27 UTC, ZombineDev wrote:
There's also a simple thing called smart pointers which do this
with RAII, copy and move semantics. Smart pointers manage the
lifetime of the object they point to automatically. You just
need to make sure that you access the obje
On Monday, 21 September 2015 at 14:30:19 UTC, Chris wrote:
What's the current state of D's GC. Will std.allocator improve
things eventually?
I don't understand the point of std.allocator.
AFAIK the current GC has very limited compiler support. A smart
compiler could move allocations to the st
On Monday, 21 September 2015 at 12:04:11 UTC, Ola Fosheim Grøstad
wrote:
That is most likely even more work than creating a language
solution?
What's the current state of D's GC. Will std.allocator improve
things eventually?
On Monday, 21 September 2015 at 11:01:27 UTC, ZombineDev wrote:
I prefer library-defined smart pointers than language magic,
because you can easily modify them to fit your needs. What D
needs is a way to enforce that the user can't get unmanaged
references to the underlying object managed by th
On 2015-09-19 17:56:21 +, thedeemon said:
If we carefully use addRoot() and addRange() for data directly pointing
to GC heap I think we don't need to let GC scan everything that can
lead to this data. This is error-prone in general, of course.
Well, that's a different name for malloc & fr
On Monday, 21 September 2015 at 10:25:05 UTC, Chris wrote:
On Monday, 21 September 2015 at 10:18:17 UTC, Ola Fosheim
Grøstad wrote:
On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
I sometimes wonder - and please forgive me my ignorance,
because I'm not a GC expert at all - if it woul
On Monday, 21 September 2015 at 10:25:05 UTC, Chris wrote:
So I'm not completely nuts! Good to know. :) I wonder, if
something like this is feasible in D.
I am too. I'm toying with some ideas, but I think it would work
mostly for shorter programs. Then again, I'm mostly interested in
shorter
On Monday, 21 September 2015 at 10:18:17 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
I sometimes wonder - and please forgive me my ignorance,
because I'm not a GC expert at all - if it would be possible
to create a system where the created objects
On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
I sometimes wonder - and please forgive me my ignorance,
because I'm not a GC expert at all - if it would be possible to
create a system where the created objects know their own life
spans and destroy themselves, once they are no longer
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
The new GC in Go 1.5 seems interesting. What they say about is
certainly interesting.
http://blog.golang.org/go15gc
"To create a garbage collector for the next decade, we turned
to an algorithm from decades ago. Go's new garbage collec
On Sunday, 20 September 2015 at 23:43:29 UTC, Jack Stouffer wrote:
On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote:
That's just bad excuses.
Excuses? Sure. Bad excuses? Not nearly. The other things I
listed are much more important (IMO) than making the GC faster.
The most impo
With Andrei working more on D maybe he will find time to document how the
compiler works better so more of us can contribute.
On Mon, Sep 21, 2015 at 4:23 AM, deadalnix via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Sunday, 20 September 2015 at 23:43:29 UTC, Jack S
On Sunday, 20 September 2015 at 23:43:29 UTC, Jack Stouffer wrote:
On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote:
That's just bad excuses.
Excuses? Sure. Bad excuses? Not nearly. The other things I
listed are much more important (IMO) than making the GC faster.
Most excuses
On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote:
That's just bad excuses.
Excuses? Sure. Bad excuses? Not nearly. The other things I listed
are much more important (IMO) than making the GC faster.
On Friday, 18 September 2015 at 20:46:18 UTC, Jack Stouffer wrote:
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
The new GC in Go 1.5 seems interesting. What they say about is
certainly interesting.
http://blog.golang.org/go15gc
"To create a garbage collector for the next decade,
Dne 19.9.2015 v 21:30 Ola Fosheim Grøstad via Digitalmars-d-announce
napsal(a):
On Saturday, 19 September 2015 at 19:25:31 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak wrote:
No, collection could not occure if we speaking about current D GC
imp
On Saturday, 19 September 2015 at 19:25:31 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak
wrote:
No, collection could not occure if we speaking about current D
GC
implementation. So it safe to set pointer before addRoot.
It can be triggered by ano
On Saturday, 19 September 2015 at 19:17:38 UTC, Daniel Kozak
wrote:
No, collection could not occure if we speaking about current D
GC
implementation. So it safe to set pointer before addRoot.
It can be triggered by another thread.
Wrong:
ptr = somestack.pop();
someglobalptr = ptr;
// ptr reg
No, collection could not occure if we speaking about current D GC
implementation. So it safe to set pointer before addRoot.
Dne 19. 9. 2015 21:00 napsal uživatel "Ola Fosheim Grøstad via
Digitalmars-d-announce" :
> On Saturday, 19 September 2015 at 18:20:16 UTC, Ola Fosheim Grøstad wrote:
>
>> I'm
On Saturday, 19 September 2015 at 18:20:16 UTC, Ola Fosheim
Grøstad wrote:
I'm not sure if the current collector scans all registers, or
just scans the stack?
According to the docs it scans all registers, but even then one
must be careful and do addRoot before the pointer is set,
otherwise th
On Saturday, 19 September 2015 at 17:56:23 UTC, thedeemon wrote:
Yes, good point. One should keep root ranges small too.
If we carefully use addRoot() and addRange() for data directly
pointing to GC heap I think we don't need to let GC scan
everything that can lead to this data. This is error-p
On Saturday, 19 September 2015 at 09:22:40 UTC, Ola Fosheim
Grøstad wrote:
Please, let's stop pretending you only have to scan the GC
heap. You have to scan all pointers that somehow can lead to
something that can lead to something... that points into the GC
heap.
Yes, good point. One shoul
On Saturday, 19 September 2015 at 14:12:10 UTC, Rory McGuire
wrote:
The impression I got reading the article was that their GC was
very much like our current one except that the marking part of
the algorithm was run concurrently.
It is quite different. As mentioned they also protect writes to
The impression I got reading the article was that their GC was very much
like our current one except that the marking part of the algorithm was run
concurrently.
That is the only reason I shared the article. To me it seems one should be
to mark variables/types with which style of memory management
On Saturday, 19 September 2015 at 08:36:51 UTC, thedeemon wrote:
full heap every time. And that leads to different usage pattern
where GC heap should remain small and GC allocation rate low.
Please, let's stop pretending you only have to scan the GC heap.
You have to scan all pointers that som
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
The new GC in Go 1.5 seems interesting. What they say about is
certainly interesting.
They went the way of classical GC-ed language where write
barriers are used actively, allowing to make concurrent,
incremental and (eventually, if no
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
The new GC in Go 1.5 seems interesting. What they say about is
certainly interesting.
http://blog.golang.org/go15gc
Go 1.6 GC roadmap:
https://docs.google.com/document/d/1kBx98ulj5V5M9Zdeamy7v6ofZXX3yPziAf0V27A64Mo/preview
On 18-Sep-2015 23:46, Jack Stouffer wrote:
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
[snip]
The reason Go has a better GC than D is that Go users have no choice but
to use the GC, while D users have a bunch more options.
To put it differently - D is a big language that has lot
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
The new GC in Go 1.5 seems interesting. What they say about is
certainly interesting.
http://blog.golang.org/go15gc
"To create a garbage collector for the next decade, we turned
to an algorithm from decades ago. Go's new garbage collec
40 matches
Mail list logo
