RFR: Fix Minimal VM build failures [v4]
Aleksey Shipilev
shade at openjdk.java.net
Thu Sep 30 16:26:06 UTC 2021
On Wed, 29 Sep 2021 11:13:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
>> Minimal VM configs have no C2 and no JVMTI. New Loom code fails the Minimal VM builds because of this. See for example GHA runs: https://github.com/shipilev/loom/runs/3717293969?check_suite_focus=true
>>
>> C2 needs just a little bit of protection when reaching to `DerivedPointersTable`.
>>
>> JVMTI needs a bit more work. `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`. Plus, some of the paths that call the actual methods declared but not implemented without JVMTI should be protected with `INCLUDE_JVMTI`.
>>
>> Additional testing:
>> - [x] Linux x86_64 server, `tier1_loom` still passes (includes JVMTI tests)
>> - [x] Linux x86_64 minimal now builds, runs `tier1_loom` (cannot pass JVMTI tests without JVMTI)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>
> Remove excessive guard
GitHub would not let me to reply to the conversation here: https://github.com/openjdk/loom/pull/67#discussion_r718781592 -- so I reply in new comment:
> 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:
I believe their use in asserts is mostly due to external code accessing the `JvmtiVTMTDisabler` fields. `JvmtiVTMTDisabler` itself accesses the fields directly, because it can, and it does it on non-debug paths. So, while current accesses are from asserts, they do not look like debug-specific accessors. If they are, it would be awkward not to make the fields themselves `DEBUG_ONLY`, but that goes against the `JvmtiVTMTDisabler` internal use.
In other words, I don't see problems with the proposed form. But I see a productivity problem with spending more time polishing this PR. Please accept this form, and let us move on.
-------------
PR: https://git.openjdk.java.net/loom/pull/67
More information about the loom-dev
mailing list