This is set to 0 for young objects and 1 for old objects, and is used as a performance optimisation for the write barrier. Fetching the age_bits from the heap page and doing the required math to calculate if the object was old or not would slow down the write barrier. So we keep this bit synced in the flags for fast access.

Given that accessing these bits from the heap adds extra performance overhead, can you provide more background as to why these bits are being maintained in a separate location in addition to the flag bits?

This is set to 0 for young objects and 1 for old objects, and is used as a performance optimisation for the write barrier. Fetching the age_bits from the heap page and doing the required math to calculate if the object was old or not would slow down the write barrier. So we keep this bit synced in the flags for fast access.

Given that accessing these bits from the heap adds extra performance overhead, can you provide more background as to why these bits are being maintained in a separate location in addition to the flag bits?

@maximecb @byroot @peterzhu2118 and I discussed this outside of Github, but for context I'll summarise here:

We're not maintaining these bits in two separate places. The age of the object is now only being stored in the bitmap attached to a heap page, and the only part of the code that should have to access or modify this bitmap is the age related GC code. This data should be ignored by the rest of the VM.

The FL_PROMOTED bit is being used by the write barrier to decide whether or not it needs to take action for the object.

Currently FL_PROMOTED is being used as a proxy for whether the old object is in the Young or the Old gen, because that's what the write barrier cares about (because of the Old object, Young reference issue); and so superficially, this can be seen as data duplication. We could use the age bits directly from within the write barrier to determine what generation the object is in, but we chose not to do this for a couple of reasons.

1. Performance - the object is passed into the write barrier function - we don't need to do any extra lookups to check the flags. If we were to look at the age bits, we'd have to find them by calculating where the objects heap page is, and then load them in. This would be much slower.
2. It would break encapsulation of the GC. The main motivation behind this PR is to get some GC related concerns out of other parts of the VM and back into the GC. Requiring the write barrier to know about age bits, and which ages correspond to which generation would break this encapsulation.

Conceptually, FL_PROMOTED is now just a write barrier trigger, which we could use for any reason if we wanted to trigger a write barrier in the future.

This approach also does not negatively impact performance, as can be seen by the benchmark results on the bug tracker ticket

Assuming we go ahead with this, can I humbly request one of the available flag bits for immutability?

Only one of the two bits is being freed, and we plan to use it to embed T_DATA objects.

Okay. Fortunately we are going to be able to free up FL_TAINT. In any case, I've waited for a flag for 2 years for the Immutability PR, which predates Data. I'm interested to know what "embed T_DATA" is, is there a link to the proposal or discussion?

which predates Data

This has nothing to do with Data.define. And either way I don't think that's what should define what free flags can be used for.

I'm interested to know what "embed T_DATA" is

#7440

This has nothing to do with Data.define. And either way I don't think that's what should define what free flags can be used for.

Of course, but if it comes to it, it should at least be a discussion.