>
>
> - 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.
>
Possibly are you saying this because the stuck counts is a bit test or
because they are ignored ? i think this is 50/50 they were forced into
the cap by reusing the field but it doesnt match with there asertion that
nearly all counts are < 5.
Normal Jikes header is 16 bytes ( 32 bit) so adding a field would go to
17or 20 .. and im not sure what happens to the object alignment ,
paragraph alignment for header and body are nice . Obviously if the cost
went from 11 bytes to 12 it would have a lower impact .
>
>> - 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. :-)
>
I know ,still need to mask it though or check for overflow . and you need
to make sure its 100% concurrent...
if ( abc.header & 0x8 != 5)
LOCK INCL abc.header;
Ok use overflow bit , so you have bit set and tst . Tricky..
Interesting how the behaviour is as per nursery , then for longer lived
objects it becomes either ref count ( small counts ) or tracer(Mark)
cleaned ( high counts ) though a small amount will return to ref count .
I dont know if the <5 is common is because most objects are short lived
though... or whether long lived objects also have ref counts < 5.
>
>> - Very tied to the platform eg block and line size and heap structure
>>
>
> All fast GC/RC systems are.
>
- 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.
>
I dont know about advice more something you live with ...Its a common
solution many developers use eg Cacoa / Obh C C++ smart ptr. , Windows8
Winrt , etc. Agree both parent and child can be significant and i dislike
schemes where child are weak references but the key is not to rely on the
weak reference but to manage the lifetime explicitly yourself for cycles
.. eg compiler tells you this has a cycle you use weak references
obj c = new Weakref<obj>(myObj); // I know its a cyc object so
( c.parrent != null c.child != null)
CycleManager.AddCheck(myObj) ;
...
CycleManager.RemoveCycles(myObj) ; // or with a hit c.
Worse performance for cycles but they are rare enough to be a special case
and if it is an issue you can improve later . Bugs where cycles become null
only happen when remove cycles at the worng time. I suspect auto cycle
clean up due to pretty wide spread use its a nice to have rather than a
must have.. Obviously syntax can be sugered up but thats the idea.
Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
