G1: Should nmethod entry barriers keep oop constants alive?

[Reingruber, Richard]

Hi,

the nmethod entry barrier used by G1 keeps oop constants of nmethods alive [1].
As I see it this is only needed if actually constant fields (final or @Stable) are changed after initialization (see JDK-8288970).
Is this correct or are there other cases? [2]

If correct then I'd think it isn't the best solution to the issue. (a) the
keep-alive is almost always redundant (b) it is imprecise and can hinder
unloading of unreachable code because class loaders of inlined or devirtualized
calls are added to the nmethods constants. (c) nmethods with a stale constant
value are kept as long as they are called (d) the stale constant value might be
persisted somewhere which could cause inconsistency.

I'd like to get some feedback on this because I wonder if I should REDO
JDK-8297487 at all (after BACKOUT JDK-8299956).

Thanks, Richard.

[1] Keepalive of nmethod entry barrier used by G1:
    https://github.com/openjdk/jdk/blob/08b24ac7aacaff32577dc07e77ed0961dd804904/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L100-L103

[2] Could be Loom but I wouldn't see why the keep-alive would be needed there. Otherwise it should be unlikely. After all G1 was working well w/o it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20230130/3b86c8c9/attachment.htm>