Precise GC

[Robert Jacques]

On Sat, 14 Apr 2012 05:21:08 -0500, Manu <turkeyman at gmail.com> wrote:

> On 13 April 2012 17:25, Kagamin <spam at here.lot> wrote:
>>
>> once you prefetched the function, it will remain in the icache and be
>> reused from there the next time.
>>
>
> All depends how much you love object orientation. If you follow the C++
> book and make loads of classes for everything, you'll thrash the hell out
> of it. If you only have a couple of different object, maybe they'll coexist
> in the icache.
> The GC is a bit of a special case though because it runs in a tight loop.
> That said, the pipeline hazards still exist regardless of the state of
> icache.
> Conventional virtuals are worse, since during the process of executing
> regular code, there's not usually such a tight loop pattern.
> (note: I was answering the prior question about virtual functions in
> general, not as applied to the specific use case of a GC scan)
>
> The latest 'turbo' ARM chips (Cortex, etc) and such may store a branch
> target table, they are alleged to have improved prediction, but I haven't
> checked.
> Prior chips (standard Arm9 and down, note: most non-top-end androids fall
> in this category, and all games consoles with arms in them) don't
> technically have branch prediction at all. ARM has conditional execution
> bits on instructions, so it can filter opcodes based on the state of the
> flags register. This is a cool design for binary branching, or performing
> 'select' operations, but it can't do anything to help an indirect jump.
>
> Point is, the GC is the most fundamental performance hazard to D, and I
> just think it's important to make sure the design is such that it is
> possible to write a GC loop which can do its job with generated data tables
> if possible, instead of requiring generated marker functions.
> It would seem to me that carefully crafted tables of data could technically
> perform the same function as marker functions, but without any function
> calls... and the performance characteristics may be better/worse for
> different architectures.
>

Is there any reason to assume that the GC is actually using the mark function for marking? The mark function is only there to provide the GC with the information it needs in order to mark. What it actually is is defined by the runtime. So it may just return a bitmask. Or it might _be_ a bitmask (for objects <= 512 bytes) Or an 64-bit index into some internal table. Etc. If fact, real functions only start making sense with very large arrays and compound structs/objects.

My actual concern with this approach is that a DLL compiled with GC A will have problems interacting with a program with GC B.