On Sat, Oct 12, 2013 at 9:58 AM, Bennie Kloosteman <[email protected]>wrote:
- none of those papers mentions concurrency and appying LOCK on setting > the ref count , Doing this and adding bits fast is tricky. ,, Will it > work on 2 CPU boards ? I did see them test muti thread apps with 4 core HT > with shared l3 cache , > Per my last note, when you defer reference counts it's more complicated than that. > - Does value types and value types on stacks change the memory profile > significantly from Java ? > Probably, but we have no quantification. > - Regarding allocation not sure if adding 32 bits to the header adds that > much like they claim unless it goes over a 4/16 byte boundary . C# even > uses the 32/64 SynBlock ( which you could use on the clr) and the header is > pretty fat . Maybe because of value types header size is less of an issue . > That may be, but the possibility of stuck counts is likely a *good* thing from a concurrency scaling perspective. > - Incrementing an aligned 32 bit field is much faster than some unaligned > bits especially thread safe. > Yes. Which is why you put the count bits in the least significant position of some aligned header word. :-) > - Very tied to the platform eg block and line size and heap structure > All fast GC/RC systems are. > I can only conclude that unless they made a concurrency mistake that the > atomic increment / decrement becomes irrelevant because the trace setting > it for new objects or when the count exceeds the bit count. So its more > of a GC allocator and ref counting collector . > Or at least the relevance is reduced in a lot of cases. That plus the deferred updates goes a long way. > - Detect possible cycles in code and warn users they should use weak > references if they want a cycle. > Nothing personal, but I always hate it when people give me this advice. I have yet to implement a cyclic data structure in which this was a viable alternative. Both the "up" pointers and the "down" pointers are significant for lifetime purposes in ever case I have personally encountered. > shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
