On Tue, Jul 30, 2013 at 10:34 PM, Bennie Kloosteman <[email protected]>wrote:
> Howver with a GC pin , there can be nasty issues eg you have a > pointer in a nursery that is now fixed ... what happens if there is a long > timeout etc and now the nursery is full . ..this plays havock with most > collectors... > Perhaps, but it has a very easy fix, which is to copy the object out of the nursery at the time of pin. > Yes you can use a block heap .. but this creates more complexity in the > GC... > Actually, it extends use of a mechanism that tends to be there already. Most collectors use a separate space for large objects that does *not* get compacted, or that gets compacted separately. It is also common for the runtime to implement a separate pool for strings, because those cannot contain pointers and segregating them lowers copying delays. A block heap simply extends this to block data. The in-GC-heap object header still exists as usual; the object payload (the bytes of the block) are stored out of line. There is essentially no impact on the GC implementation other than knowledge of a new primordial leaf-object type - and one that is very similar to existing object types. As to range checks, your point is well taken, but the effects are pernicious when the consequences for inlining are concerned. For CPU-intensive algorithms, it can easily make a 4x to 8x difference in algorithm performance. In particular, it means that loop unrolling isn't very helpful. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
