> 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 when > working on this patch: removing this optimization yields 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. > > Additional testing: > - [x] Linux x86_64 Zero fastdebug build with `-jvmti` > - [x] Linux x86_64 Zero fastdebug/release build times are not regressing
Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Simplify a few JVMTI_ENABLED blocks - Merge branch 'master' into JDK-8255822-zero-jvmti-rework - Fix build error - Merge branch 'master' into JDK-8255822-zero-jvmti-rework - Revert one dubious change - 8255822: Zero: improve build-time JVMTI handling Summary: use C++ templates instead of XSLT transforms ------------- Changes: https://git.openjdk.java.net/jdk/pull/1061/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1061&range=02 Stats: 188 lines in 6 files changed: 5 ins; 128 del; 55 mod Patch: https://git.openjdk.java.net/jdk/pull/1061.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1061/head:pull/1061 PR: https://git.openjdk.java.net/jdk/pull/1061
