AW: AW: How to pin/avoid gc for an oop?

[Thomas Schatzl]

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