Leopold Toetsch wrote:No, flags are mutable and per PMC *not* per class.
Of course there are flags which must remain per-PMC. I wasn't referring to them. Sorry if that wasn't clear.
If a flag is only saying "my VTABLE methods use the UnionVal as {a
void*/a PObj*/a PMC*/data}, so GC should trace accordingly," it may be
a waste of a per-object flag bit to store those flags with the PMC
instance rather than with the PMC class.
All DOD related flags in the fast paths (i.e. for marking scalars) are located in the PMCs arena (with ARENA_DOD_FLAGS is on). This reduces cache misses during DOD to nearly nothing. More DOD related information is in the flags part of the Pobj - but accessing that also means cache pollution. Putting flags elsewhere too, needs one more indirection and allways an access to the PMC memory itself. This doesn't give us any advantage.
But again, flags don't matter during setting or getting a PMCs data. Flags aren't used in classes for these purposes.
There are very few places in classes, where flags are even changed. This is morphing scalars, and Key PMCs come to my mind.
If we're looking at lock-free concurrency, flag updates probably have
to be performed with atomic &'s and |'s.
Almost all mutating vtable methods will lock the pmc.
Er, int_val and pmc_val at the same time?
I know :) This isn't the safest thing we have. After your union accessor patches, we can clean that up, and use a notation so that for this case, the two union members really can't overlap.
leo
