On Fri, 11 Sep 2026 16:25:17 GMT, Vladimir Kozlov <[email protected]> wrote:
>> src/hotspot/share/code/aotCodeCache.hpp line 360: >> >>> 358: do_var(uint, GCCardSizeInBytes) \ >>> 359: do_var(bool, PreserveFramePointer) \ >>> 360: do_var(bool, UseTLAB) \ >> >> Consider `ZeroTLAB` which may also affect compilation. >> >> Also look at `StackReservedPages`, `StackOverflow::stack_shadow_zone_size()` >> which affect the stack banging code on method entry. Even >> `os::vm_page_size()` affects stack banging; it should be in the config if it >> was hard-coded in the AOT code. Or, if those values are too volatile >> (cannot be assumed stable), load them from a global variable. >> >> Also, a quick look at Shenandoah code suggests that, at some point, >> variables like `ShenandoahSATBBarrier` and `ShenandoahLoadRefBarrier` and >> `ShenandoahCardBarrier` and `ShenandoahCloneBarrier` may need checking; that >> would need its own gating on the GC as well. >> >> More vars to consider: `UseAdler32Intrinsics`, `InlineTypePassFieldsAsArgs` >> (when Valhalla is supported), `ReduceInitialCardMarks`, >> `VM_Version::use_rop_protection()`, `VM_Version::zva_length()`, >> `VM_Version::dcache_line_size()`. In case it’s not obvious, these random >> names came from a mechanical scan of JIT-related code! >> >> JVMTI affects codegen, so maybe a `do_fun` for things like >> `JvmtiExport::can_hotswap_or_post_breakpoint()`, >> `JvmtiExport::can_walk_any_space()`, etc. > > Working on this. I fixed most of this in coming patch. Except UseAdler32Intrinsics, InlineTypePassFieldsAsArgs and dcache_line_size(). I will cover them in next update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30778#discussion_r3993668533
