Clean up CompiledMethod::oops_reloc_begin()
Erik Österlund
erik.osterlund at oracle.com
Wed Oct 17 15:36:14 UTC 2018
Hi,
In CompiledMethod::oops_reloc_begin() there is code to prevent looking
for oops at the verified entry of an nmethod that is not entrant, as a
native jump instruction has been overwritten there. Except there would
*never* be any immediate oops there for any compiler, even before
becoming not entrant, with or without OSR compilation, so this special
handling of not entrant vs entrant nmethods is seemingly completely
unnecessary.
This gets increasingly awkward when oops_do is called concurrently with
concurrent class unloading, where an nmethod is racing to become not
entrant.
To clean this up, I propose to change the boundary for immediate oop
scanning and start looking for oops only after the frame building is
completed, as there is absolutely no point in looking for oops before
that in the first place. This removes unnecessary workarounds that exist
today, and removes unnecessary races going forward.
It seems like Graal as JIT also inlines oops into the code stream, but
never sets the CodeOffsets::Frame_Complete in the nmethod. So I
recognize such nmethods and unconditionally start scanning at the
verified entry + native jump instruction size. I spoke to the Graal
folks, and they said they do not put oops in there either. So I think
everyone involved should be happy with this solution.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8212585
Webrev:
http://cr.openjdk.java.net/~eosterlund/8212585/webrev.00/
Thanks,
/Erik
More information about the hotspot-dev
mailing list