RFR: 8269476: Skip nmethod entry barrier if there is no oops in the jit code [v2]
王超
github.com+25214855+casparcwang at openjdk.java.net
Tue Jun 29 01:16:05 UTC 2021
On Mon, 28 Jun 2021 16:18:08 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
> nmethod entry barrier is inserted in SharedRuntime::generate_native_wrapper().
>
> At that point, the method is already compiled and its metadata information should be available. It should be possible to determine if there are any embedded oops there and elide barrier completely if there is none.
Thanks for providing the patch. But we cannot aways figure out there are any oops on the generation of entry barrier:
1, C1 patching mechanism will dynamically introduce java mirror oop to the nmethod, if the patching code is executed. If the oops is added again to the method, the entry barrier should be activated again.
2, In C2 compilation, `MachPrologNode::emit` will call `MacroAssembler::verified_entry` to generate the nmethod entry barrier, that's the very first node to emit machine instructions, so at this time how many oops embedded is unknown.
3, In `nmethod::new_nmethod`, it will call `CodeBuffer::finalize_oop_references` to add class loader of embedded Klass meta to the oop recorder. Only visit relocation will miss these classloaders.
So the entry barrier can not be easily eliminated on current code base, and if the barrier needs to be eliminated, there are lots of things to do.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4610
More information about the hotspot-dev
mailing list