Just read the paper. Comments - Getting the tracer to do the first ref count is a great idea. - 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 , - Does value types and value types on stacks change the memory profile significantly from Java ? - 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 . - Incrementing an aligned 32 bit field is much faster than some unaligned bits especially thread safe. - Its complex and expensive ( though less so than a concurreny GC) - Very tied to the platform eg block and line size and heap structure
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 . I still think if you want ref counting you can go far with - Detect possible cycles in code and warn users they should use weak references if they want a cycle. Dont count weak references.. User deals with the reference becoming null. The warning should remove a lot of cycles which are just poor design. And if you really need a cycle that doesnt last for the whole progam you can use the weak reference and then hold a manual reference to control when the cycle gets removed yourself. - Use Concurent blocks/ classes , most code is single threaded so its anoying paying for all that concurrency on non concurrent code ( and when you do , that big fat lock will dwarf this anyway eg SYNCROOT wrapper on C# collections ) . Ref count becomes inc and dec in most cases. Use bits in the header as per "Down for the Count? Getting Reference Counting Back in the Ring" if its better but im not convinced its better for non Java / Jikes . Anyway with a simple system its easy to test and optomize for Bitc ( not Java/Jikes) - Later on you can consider a background tracer that goes through and sets the counts ,,,and dont set the count for new objects. This can eventually evolve into the full system but if its not needed you have saved a lot of time. Ben On Sat, Oct 12, 2013 at 2:12 PM, Bennie Kloosteman <[email protected]>wrote: > > Interop with other stacks and runtimes is a massive advantage with > reference counting ( or non relocating GCs) ...and i dont just mean > calling c but far more importantly c / C++ /Java calling bitc. > > Also if you still target the CLR i asume you will just ignore / stop the > GC and build your own minimal GC for the cycles ( LLVM and static compile > becomes more attractive) > > re last post not LOCK CMPXCHG but obviously LOCK INCL / LOCK DECL wrote > some locks last year and CMPXCHG has burned too deep... the pain... .. > > Ben > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
