On Tue, 27 Jun 2023 21:29:53 GMT, Doug Simon <[email protected]> wrote:
>> The VMSupport class is required for translating an exception between the
>> HotSpot and libgraal heaps.
>> Loading it lazily can result in a loading exception, obscuring the exception
>> being translated.
>> To avoid this, VMSupport is loaded eagerly along with the other vmClasses.
>
> Doug Simon has updated the pull request incrementally with one additional
> commit since the last revision:
>
> revert to lazy loading of VMSupport
I don't think pushing it down that far improves things. encode always precedes
decode so why not resolve it before the encode call.
// Resolve VMSupport class explicitly as HotSpotJVMCI::compute_offsets
// may not have been called.
Klass* vmSupport =
SystemDictionary::resolve_or_fail(vmSymbols::jdk_internal_vm_VMSupport(), true,
THREAD);
int res = 0;
if (!HAS_PENDING_EXCEPTION) {
res = encode(THREAD, vmSupport, buffer, buffer_size);
}
src/hotspot/share/jvmci/jvmciEnv.cpp line 402:
> 400: }
> 401: int res = encode(THREAD, buffer, buffer_size);
> 402: if (_from_env != nullptr && !_from_env->is_hotspot() &&
> _from_env->has_pending_exception()) {
Why is this check before the `HAS_PENDING_EXCEPTION` check? Couldn't you end
up returning with a pending exception in this path?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14641#issuecomment-1610335668
PR Review Comment: https://git.openjdk.org/jdk/pull/14641#discussion_r1244461845