<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Richard,
<div class=""><br class="">
</div>
<div class="">I have *always* thought that having nmethod oops be required to be reachable some other way from the object graph or risk breaking SATB is very fragile. That’s part of the reason why ZGC required nmethod entry barriers from the first release that
supported class unloading at all (JDK-12). Meanwhile I have kind of been waiting for a situation in G1 where we would add an oop that ends up not being reachable some other way. I felt pretty certain it would pop up eventually, I just did not know in which
shape or form it would appear in. Indeed, it did materialize with @Stable. It can also materialize with final fields that you modify them with reflection, Unsafe or JNI. Are there other holes? I don’t know. And I’d rather not wait to find out.</div>
<div class=""><br class="">
</div>
<div class="">I think that nmethod oops should stand on their own feet. If the compiler decides to put them in, we shouldn’t rely on other fragile and hard to reason about properties to not break SATB. So whether this bug would have presented itself or not,
I have always thought the previous mechanism is too fragile.</div>
<div class=""><br class="">
</div>
<div class="">Besides, the idea of fixing up the last remaining nmethods that are on-stack when you get to remark, doesn’t really work for loom. Because some of the stacks won’t be mounted on carrier threads. Instead, they could reside only in heap continuations
that have been allocated concurrent marking started, and hence will never be visited by a GC. This was indeed the original motivation for adding nmethod entry barriers to G1, before the @Stable stuff appeared.</div>
<div class=""><br class="">
</div>
<div class="">In other words, I think you should REDO JDK-8297487, and not consider this as a problem only for @Stable.</div>
<div class=""><br class="">
</div>
<div class="">Thanks,</div>
<div class="">/Erik<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 30 Jan 2023, at 17:52, Reingruber, Richard <<a href="mailto:richard.reingruber@sap.com" class="">richard.reingruber@sap.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
Hi,<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<o:p class=""> </o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
the nmethod entry barrier used by G1 keeps oop constants of nmethods alive [1].<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
As I see it this is only needed if actually constant fields (final or @Stable) are changed after initialization (see JDK-8288970).<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
Is this correct or are there other cases? [2]<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<o:p class=""> </o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
If correct then I'd think it isn't the best solution to the issue. (a) the<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
keep-alive is almost always redundant (b) it is imprecise and can hinder<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
unloading of unreachable code because class loaders of inlined or devirtualized<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
calls are added to the nmethods constants. (c) nmethods with a stale constant<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
value are kept as long as they are called (d) the stale constant value might be<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
persisted somewhere which could cause inconsistency.<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<o:p class=""> </o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
I'd like to get some feedback on this because I wonder if I should REDO<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
JDK-8297487 at all (<span lang="DE" class="">after<span class="Apple-converted-space"> </span></span>BACKOUT JDK-8299956).<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<o:p class=""> </o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
Thanks, Richard.<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<o:p class=""> </o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
[1] Keepalive of nmethod entry barrier used by G1:<o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<span class="Apple-converted-space"> </span><a href="https://github.com/openjdk/jdk/blob/08b24ac7aacaff32577dc07e77ed0961dd804904/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L100-L103" style="color: rgb(5, 99, 193); text-decoration: underline;" class="">https://github.com/openjdk/jdk/blob/08b24ac7aacaff32577dc07e77ed0961dd804904/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L100-L103</a><o:p class=""></o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
<o:p class=""> </o:p></div>
<div style="margin: 0cm; font-size: 11pt; font-family: Calibri, sans-serif;" class="">
[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.</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>