On Tuesday, 23 October 2012 at 22:33:13 UTC, Araq wrote:
OCmal's GC is one of the fastest GC ever made. And it is the
case because it uses immutability to great benefice.
According to which benchmarks? And does the fact that an object
is immutable really need to be known at compile time
I haven't seen proper benchmarks but some time ago I wrote in D
and OCaml basically the same simple program which read and
parsed some text and performed some calculations, allocating a
lot of temporary arrays or lists:
https://gist.github.com/2902247
https://gist.github.com/2922399
and OCaml
On Wednesday, 24 October 2012 at 17:42:50 UTC, Araq wrote:
And that makes it the fastest GC ever made?
No, not that, of course. As I said, I haven't seen proper
benchmarks. But OCaml's GC is notorious for its speed and it
performed very well in all comparisons I saw.
One place where
On Monday, 22 October 2012 at 21:19:53 UTC, deadalnix wrote:
Funny thing, immutable was supposed to make it easier to do
concurrency programming.
But not garbage collection.
OCmal's GC is one of the fastest GC ever made. And it is the
case because it uses immutability to great benefice.
OCmal's GC is one of the fastest GC ever made. And it is the
case because it uses immutability to great benefice.
According to which benchmarks? And does the fact that an object
is immutable really need to be known at compile time for GC
related optimizations?
On Oct 18, 2012, at 6:06 PM, Michel Fortin michel.for...@michelf.ca wrote:
All this is nice, but what is the owner thread for immutable data? Because
immutable is always implicitly shared, all your strings and everything else
that is immutable is thus shared and must be tracked by the
On Oct 18, 2012, at 11:56 PM, Alex Rønne Petersen a...@lycus.org wrote:
I'm not really sure how this solves the problem of having pointers from a
thread-local heap into the global heap and vice versa. Can you elaborate on
that?
The problem is that even if you know whether a piece of
On 2012-10-22 19:44, Sean Kelly wrote:
Blocks flagged as shared would be completely ignored by the thread-local GC collection.
Since shared data may never reference unshared data, that should avoid anything being
collected that's still referenced. I hadn't thought about immutable though,
On 10/22/12 3:16 PM, Jacob Carlborg wrote:
On 2012-10-22 19:44, Sean Kelly wrote:
Blocks flagged as shared would be completely ignored by the
thread-local GC collection. Since shared data may never reference
unshared data, that should avoid anything being collected that's still
referenced. I
On Oct 22, 2012, at 12:16 PM, Jacob Carlborg d...@me.com wrote:
On 2012-10-22 19:44, Sean Kelly wrote:
Blocks flagged as shared would be completely ignored by the thread-local GC
collection. Since shared data may never reference unshared data, that
should avoid anything being collected
Le 19/10/2012 08:49, Alex Rønne Petersen a écrit :
On 17-10-2012 16:26, deadalnix wrote:
Why not definitively adopt the following (and already proposed) memory
scheme (some practice are now considered valid when this scheme is not
respected) :
Thread local head (one by thread) - shared heap -
Le 18/10/2012 20:26, Sean Kelly a écrit :
On Oct 17, 2012, at 1:55 AM, Alex Rønne Petersena...@lycus.org wrote:
So, let's look at D:
1. We have global variables.
1. Only std.concurrency enforces isolation at a type system level; it's not
built into the language, so the GC cannot make
Le 22/10/2012 22:44, Andrei Alexandrescu a écrit :
On 10/22/12 3:16 PM, Jacob Carlborg wrote:
On 2012-10-22 19:44, Sean Kelly wrote:
Blocks flagged as shared would be completely ignored by the
thread-local GC collection. Since shared data may never reference
unshared data, that should avoid
On 17-10-2012 16:26, deadalnix wrote:
Why not definitively adopt the following (and already proposed) memory
scheme (some practice are now considered valid when this scheme is not
respected) :
Thread local head (one by thread) - shared heap - immutable heap
This model have multiple benefices :
On 17-10-2012 13:51, Jacob Carlborg wrote:
On 2012-10-17 10:55, Alex Rønne Petersen wrote:
Let's step back for a bit and think about what we want to achieve with
thread-local garbage collection. The idea is that we look only at a
single thread's heap (and stack/registers, of course) when doing
On 18-10-2012 20:26, Sean Kelly wrote:
On Oct 17, 2012, at 1:55 AM, Alex Rønne Petersen a...@lycus.org wrote:
So, let's look at D:
1. We have global variables.
1. Only std.concurrency enforces isolation at a type system level; it's not
built into the language, so the GC cannot make
On 2012-10-18 22:29, Sean Kelly wrote:
It's different in that a variable's address never actually changes. When a
thread completes it hands all of its pools to the shared allocator, and then
per-thread allocators request free pools from the shared allocator before going
to the OS. This is
On 2012-10-19 03:06, Michel Fortin wrote:
All this is nice, but what is the owner thread for immutable data?
Because immutable is always implicitly shared, all your strings and
everything else that is immutable is thus shared and must be tracked
by the global heap's collector and can never be
On 2012-10-19 08:48, Alex Rønne Petersen wrote:
How does it deal with the problem where a pointer in TLS points to
global data, or worse yet, a pointer in the global heap points to TLS?
I'm pretty sure it can't without doing a full pass over the entire heap,
which seems to me like it defeats
How does it deal with the problem where a pointer in TLS points
to global data,
Need to run stop-the-world for shared heap. But it would be
interesting to have blocks that have no shared pointers in them.
or worse yet, a pointer in the global heap points to TLS?
Could you give an
On 19-10-2012 11:07, sclytrack wrote:
How does it deal with the problem where a pointer in TLS points to
global data,
Need to run stop-the-world for shared heap. But it would be interesting
to have blocks that have no shared pointers in them.
The problem with D is that we have a (more or
On Friday, 19 October 2012 at 09:07:55 UTC, sclytrack wrote:
How does it deal with the problem where a pointer in TLS
points to global data,
Need to run stop-the-world for shared heap. But it would be
interesting to have blocks that have no shared pointers in them.
or worse yet, a
Thread-local GC is all about improving scalability by only
stopping threads that need to be stopped. If you can't even do
that, then any effort towards thread-local GC is quite
pointless IMO.
Maybe the goal is to run the thread local garbage collectors very
frequently and the
On 2012-10-19 07:42:53 +, Jacob Carlborg d...@me.com said:
On 2012-10-19 03:06, Michel Fortin wrote:
All this is nice, but what is the owner thread for immutable data?
Because immutable is always implicitly shared, all your strings and
everything else that is immutable is thus shared and
On Oct 17, 2012, at 1:55 AM, Alex Rønne Petersen a...@lycus.org wrote:
So, let's look at D:
1. We have global variables.
1. Only std.concurrency enforces isolation at a type system level; it's not
built into the language, so the GC cannot make assumptions.
1. The shared qualifier
On 2012-10-18 20:26, Sean Kelly wrote:
Well, the problem is more that a variable can be cast to shared after
instantiation, so to allow thread-local collections we'd have to make
cast(shared) set a flag on the memory block to indicate that it's shared, and
vice-versa for unshared. Then when
On Oct 18, 2012, at 11:48 AM, Jacob Carlborg d...@me.com wrote:
On 2012-10-18 20:26, Sean Kelly wrote:
Well, the problem is more that a variable can be cast to shared after
instantiation, so to allow thread-local collections we'd have to make
cast(shared) set a flag on the memory block to
On 2012-10-18 20:54, Sean Kelly wrote:
And back down to a local pool when shared is cast away. Assuming the block is
even movable. I agree that this would be the most efficient use of memory, but
I don't know that it's feasible.
You said the thread local heap would be merged with the
On Oct 18, 2012, at 12:22 PM, Jacob Carlborg d...@me.com wrote:
On 2012-10-18 20:54, Sean Kelly wrote:
And back down to a local pool when shared is cast away. Assuming the block
is even movable. I agree that this would be the most efficient use of
memory, but I don't know that it's
On 2012-10-18 18:26:08 +, Sean Kelly s...@invisibleduck.org said:
Well, the problem is more that a variable can be cast to shared after
instantiation, so to allow thread-local collections we'd have to make
cast(shared) set a flag on the memory block to indicate that it's
shared, and
Hello,
in the discussions thread in the recent blog post which
summarized how GC works(*), the topic of thread-local GC was
further discussed and I pointed out that by default global
variables in D are thread local but I was answered that the types
doesn't tell which global variable are
On 17-10-2012 10:29, renoX wrote:
Hello,
in the discussions thread in the recent blog post which summarized how
GC works(*), the topic of thread-local GC was further discussed and I
pointed out that by default global variables in D are thread local but I
was answered that the types doesn't tell
On Wednesday, 17 October 2012 at 08:55:55 UTC, Alex Rønne
Petersen wrote:
On 17-10-2012 10:29, renoX wrote:
Hello,
in the discussions thread in the recent blog post which
summarized how
GC works(*), the topic of thread-local GC was further
discussed and I
pointed out that by default global
On 17-10-2012 11:50, sclytrack wrote:
On Wednesday, 17 October 2012 at 08:55:55 UTC, Alex Rønne Petersen wrote:
On 17-10-2012 10:29, renoX wrote:
Hello,
in the discussions thread in the recent blog post which summarized how
GC works(*), the topic of thread-local GC was further discussed and I
On 2012-10-17 10:55, Alex Rønne Petersen wrote:
Let's step back for a bit and think about what we want to achieve with
thread-local garbage collection. The idea is that we look only at a
single thread's heap (and stack/registers, of course) when doing a
collection. This means that we can --
Why not definitively adopt the following (and already proposed) memory
scheme (some practice are now considered valid when this scheme is not
respected) :
Thread local head (one by thread) - shared heap - immutable heap
This model have multiple benefices :
- TL heap only can be processed by
36 matches
Mail list logo
