RFR: 8374828: Save load_barrier_on_oop_field_preloaded in aot CodeCache
Stefan Karlsson
stefank at openjdk.org
Mon Jan 12 14:35:48 UTC 2026
On Mon, 12 Jan 2026 14:10:39 GMT, Andrew Dinn <adinn at openjdk.org> wrote:
> Also: The ability to use a different GC in assembly and production runs is not something we necessarily need to support. Switching in and out alternative JVM configurations is arguably a bad idea in that it is likely to increase the divergence between what gets run in training and what gets executed in production. However, we do need to clearly document what will not work and, in cases where it might cause a potential error, reject use of an AOT cache. So, it would be good to confirm what the precise limitations are in the case of ZGC.
There are still something that lingers unresolved here. For weak handles we have two operations:
1) "resolve" ZGC, Shenandoah, G1 has GC-specific code that handles this
2) "peek" Maybe only ZGC has GC-specific code for this
resolve_weak_handle is a "resolve" operation and the three mentioned GCs have GC-specific code for that. At the same time Aleksey mentioned that we were mostly "peeking" in OopHandles. So, I'm just wondering if we have started "resolving" OopHandles, where we previously only "peeked"? (I have not tried to look at the code or follow the history for this)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29129#issuecomment-3738834130
More information about the hotspot-compiler-dev
mailing list