By: Rob Thorpe (rthorpe.delete@this.realworldtech.com), October 19, 2006 2:58 am
Room: Moderated Discussions
Gabriele Svelto (gabriele.svelto@gmail.com) on 10/19/06 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/18/06 wrote:
>---------------------------
>>sp (no@thanks.com) on 10/18/06 wrote:
>>---------------------------
>>The class of "other complications" is large. Java for example has problems taking
>>sub-sections of an array from within an array. GCs can cause trouble themselves.
>>In many GCs all recently allocated memory is passed over in the mark stage to see
>>if it contains pointers.
>
>Yeah, so called generational collection, but that's very fast in practice. It's
>a technique used for replacing the classical long pauses of collection with many
>short pauses followed by a long pause much later. Works very well for commercial
>workloads were you've got tons of temporary allocations but gives you a slight performance
>hit due to the need of a write-barrier when writing pointers to the heap.
Yes. Gen GC provides good worst cases and not-so-good-but-still-OK best cases.
>>This is inefficient if most of that memory contains big
>>numeric arrays.
>
>Modern collectors won't scan arrays (nor objects) which do not contain references.
>I've written two collectors, both for Java and .Net, the first one being also targetted
>at very small applications. Both are conservative yet both will never scan non-pointer
>fields of the objects, let alone arrays.
Yes. I suppose I've come across some not-so-modern collectors still inhabiting the modern world though. Serves me right for living in lisp land I suppose.
>>Its better to have separate rules for these large objects which
>>can't contain references to other things.
>
>Both precise and almost precise collectors will treat them properly.
Yes, if written to do so.
>>Copying arrays around is also unpleasant.
>
>Yeah, unfortunately automatic memory management often makes people think they can
>safely get away with tons of copies of the objects and that ends up in really ugly code.
Yes. Having a language which is effectively copy-on-write helps, but there are still problems.
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/18/06 wrote:
>---------------------------
>>sp (no@thanks.com) on 10/18/06 wrote:
>>---------------------------
>>The class of "other complications" is large. Java for example has problems taking
>>sub-sections of an array from within an array. GCs can cause trouble themselves.
>>In many GCs all recently allocated memory is passed over in the mark stage to see
>>if it contains pointers.
>
>Yeah, so called generational collection, but that's very fast in practice. It's
>a technique used for replacing the classical long pauses of collection with many
>short pauses followed by a long pause much later. Works very well for commercial
>workloads were you've got tons of temporary allocations but gives you a slight performance
>hit due to the need of a write-barrier when writing pointers to the heap.
Yes. Gen GC provides good worst cases and not-so-good-but-still-OK best cases.
>>This is inefficient if most of that memory contains big
>>numeric arrays.
>
>Modern collectors won't scan arrays (nor objects) which do not contain references.
>I've written two collectors, both for Java and .Net, the first one being also targetted
>at very small applications. Both are conservative yet both will never scan non-pointer
>fields of the objects, let alone arrays.
Yes. I suppose I've come across some not-so-modern collectors still inhabiting the modern world though. Serves me right for living in lisp land I suppose.
>>Its better to have separate rules for these large objects which
>>can't contain references to other things.
>
>Both precise and almost precise collectors will treat them properly.
Yes, if written to do so.
>>Copying arrays around is also unpleasant.
>
>Yeah, unfortunately automatic memory management often makes people think they can
>safely get away with tons of copies of the objects and that ends up in really ugly code.
Yes. Having a language which is effectively copy-on-write helps, but there are still problems.
