There are oops used by JVMCI on nmethods that are treated specially, like the speculation log. The speculation log carries speculation data across compilations of the same method. These raw oop fields have peculiar interactions with GC where they use special APIs to register the oop with the GC so that e.g. G1 can insert it into the right remembered set, and when unloading an nmethod, to go and remove the nmethod from that remembered set, as well as to add it to oops_do so that its oop is appropriately remapped if relocated etc.
I asked Doug Simon and Gilles Duboscq if perhaps we could just stick these oops in the oop section of the nmethod and expose an offset for JVMCI instead, and then treat them as normal oops instead. The reply was that that should be possible. So that would be pretty neat with one less notorious special case for handling oops.
I asked Doug Simon and Gilles Duboscq if perhaps we could just stick these oops in the oop section of the nmethod and expose an offset for JVMCI instead, and then treat them as normal oops instead. The reply was that that should be possible. So that would be pretty neat with one less notorious special case for handling oops.