RFR: Fix Minimal VM build failures [v4]

[Chris Plummer]

On Tue, 28 Sep 2021 15:24:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 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.

If they are only used in asserts, then shouldn't they have a `#ifdef ASSERTS` around them? And there are implicit `#ifdef INCLUDE_JVMTI` uses in `jvmtiThreadState.hpp`:

  void oops_do(OopClosure* f, CodeBlobClosure* cf) NOT_JVMTI_RETURN; // GC support
  void nmethods_do(CodeBlobClosure* cf) NOT_JVMTI_RETURN;

-------------

PR: https://git.openjdk.java.net/loom/pull/67