RFR: Fix Minimal VM build failures [v2]
Aleksey Shipilev
shade at openjdk.java.net
Tue Sep 28 15:27:42 UTC 2021
On Tue, 28 Sep 2021 07:17:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> As stated in PR: "jvmtiExport and jvmtiThreadState headers are usually included even with JVMTI turned off, but .cpp would not be compiled without JVMTI. Therefore, non-trivial implementations should go into .cpp." You cannot put the accessor bodies here, because the `_VTMT_count` and `_VTMT_disable_count` symbols would be inaccessible without `.cpp` compiled, and you'll get linker errors.
>
> There are a couple of other choices here. One is like the following example:
>
> inline static bool should_post_class_file_load_hook() {
> JVMTI_ONLY(return _should_post_class_file_load_hook);
> NOT_JVMTI(return false;)
> }
>
> However I don't think anyone should actually be calling any VTMT code when JVMTI is disabled. So you could instead put the entire thing (including declaration) in a `#ifdef INCLUDE_JVMTI`. You would then need to also #ifdef around the callers, or use JVMTI_ONLY. If there are many, then go with my first suggestion.
I don't see why we should bother. These methods are only used in asserts, AFAICS, so the performance here is irrelevant. Moving these definitions out of `.hpp` matches the rest of the `JvmtiVTMTDisabler`. There are no other uses of `INCLUDE_JVMTI` in `jvmtiThreadState.hpp`, as it is assumed, I think, that you could include it without JVMTI enabled. If JVMTI is disabled in build time, using these methods would produce linker errors. Sorry, but I disagree with these suggestions.
-------------
PR: https://git.openjdk.java.net/loom/pull/67
More information about the loom-dev
mailing list