AW: AW: How to pin/avoid gc for an oop? (original) (raw)

Thomas Schatzl thomas.schatzl at oracle.com
Mon Mar 13 11:34:21 UTC 2017

Hi,

On Mon, 2017-03-13 at 01:59 +0100, Christian Hagedorn wrote:

So handles are not really an option. What else could I do to make my undo log a GC root to ensure reachability of the oops in it?

  roughly these steps:

  1. register (add) the oop you want to keep live during gc to some internal data structure. Depending on requirements like available operations on it, the amount of oops you store there, scalability and other factors, this may be different for you.

  2. make sure the GC algorithm of your choice iterates over them during GC and evacuates/fixes up these oops.

One example you may look at is how the GC's handle the "Universe's" direct oops. E.g. search for calls to Universe::oops_do() how this works.

Since Universe::oops_do() is already called in the right places, you could start experimenting by adding your undo log to the Universe and make sure that the closure passed to Universe::oops_do() is called for every oop in that data structure.

That should properly keep the required oops alive across GCs for all but G1. For that, when you modify objects in your undo log you will need to apply its pre-barrier on the original value (All other gcs do not require a pre-barrier, so nothing to do).

This boils down to calling G1SDATBCardTableModRefBS::enqueue(old_obj_value) for all modifications (unless you can guarantee that old_obj_value has been NULL).

Thanks,   Thomas

More information about the hotspot-dev mailing list