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