-
Enhancement
-
Resolution: Fixed
-
P4
-
8, 11, 15, 16
-
b24
Current Zero interpreter has the optimization for JVMTI support. It recognizes that JVMTI is disabled most of the time, and that JVMTI checks in the interpreter code slows it down considerably. (I measured it myself for this patch, it gives about 20% hit in build times).
Current optimization works as follows. At build time, an XSLT transform is performed on `bytecodeInterpreter.cpp`, yielding `bytecodeInterpreterWithChecks.cpp`. In that new compilation unit, `VM_JVMTI` macro is defined, and a new entry point -- `BytecodeInterpreter::withChecks` -- is defined. Then, both compilation units are compiled. In one of them, `JVMTI` hooks are stripped out. In another, they persist. Then, callers have to choose which entry point to use.
I believe this can be rewritten to use C++ templates instead of XLST and defines dance. This also allows to clean up JVMTI checks a bit.
Current optimization works as follows. At build time, an XSLT transform is performed on `bytecodeInterpreter.cpp`, yielding `bytecodeInterpreterWithChecks.cpp`. In that new compilation unit, `VM_JVMTI` macro is defined, and a new entry point -- `BytecodeInterpreter::withChecks` -- is defined. Then, both compilation units are compiled. In one of them, `JVMTI` hooks are stripped out. In another, they persist. Then, callers have to choose which entry point to use.
I believe this can be rewritten to use C++ templates instead of XLST and defines dance. This also allows to clean up JVMTI checks a bit.
- is blocked by
-
JDK-8255810 Zero: build fails without JVMTI
-
- Resolved
-