October 22, 2012
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 anything being collected that's still
>>> referenced. I hadn't thought about "immutable" though, which may turn
>>> out to be a problem.
>>
>> 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.

As immutable data can only refers to immutable data, I don't see a single problem here.

When collection shared and TL, you get a set of root pointer to immutable. All immutable can be collected from such set. All object allocated during the collection is supposed to be live.
October 23, 2012
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.

OCaml, I suppose. It is single threaded (there is no thread-level parallelism in OCaml) and there is nothing in its GC that uses immutability really. It's so fast because of the memory model: to tell if a word is a pointer one just needs to look at its least significant bit, if it's 0 it's a pointer, if it's 1 it's not. That's why native ints are 31-bit in OCaml. With this scheme they don't need to store type layout info and pointer bitmaps. And it is generational (2 gens), which also adds much speed.

A GC which really relies on immutability you can find in Erlang.
October 23, 2012
>
> 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?

October 24, 2012
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 for GC related optimizations?

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 version was 2 times faster than D (29 and 59 seconds on input file of 1 million lines). After disabling GC on reading/parsing stage and doing calculations without allocations and using std.parallelism I made D version work in 4.4 seconds.

One place where immutability really helps is in a generational GC: runtime needs to track all the pointers from old generation to the young generation, if most of the data is immutable there are not so many such pointers, this makes collection faster. When all data is immutable there is no such pointers at all, each object can only have pointers to older ones.
October 24, 2012
> 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 version was 2 times faster than D (29 and 59 seconds on input file of 1 million lines). After disabling GC on reading/parsing stage and doing calculations without allocations and using std.parallelism I made D version work in 4.4 seconds.
>
And that makes it the "fastest GC ever made"?

> One place where immutability really helps is in a generational GC: runtime needs to track all the pointers from old generation to the young generation, if most of the data is immutable there are not so many such pointers, this makes collection faster. When all data is immutable there is no such pointers at all, each object can only have pointers to older ones.

That's true. But you don't need to know about immmutability at compile time to get this benefit.

October 24, 2012
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 immutability really helps is in a generational GC: runtime needs to track all the pointers from old generation to the young generation, if most of the data is immutable there are not so many such pointers, this makes collection faster. When all data is immutable there is no such pointers at all, each object can only have pointers to older ones.
>
> That's true. But you don't need to know about immmutability at compile time to get this benefit.

I agree.

1 2 3 4
Next ›   Last »