RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2]
Johan Sjölen
jsjolen at openjdk.org
Thu Feb 5 11:18:13 UTC 2026
On Fri, 30 Jan 2026 09:07:24 GMT, Jean-Philippe Bempel <jpbempel at openjdk.org> wrote:
>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1477:
>>
>>> 1475: if (res != JVMTI_ERROR_NONE) {
>>> 1476: return res;
>>> 1477: }
>>
>> Pending exception need to be processed and cleared below (see lines: 1478-1487).
>
> @sspitsyn I am not sure to follow your comment.
> In the case of invalid structure, no exception was pending and therefore the method `load_new_class_versions` returns no error.
> if `merge_cp_and_rewrite` returns anything else than `JVMTI_ERROR_NONE` it should be propagated.
> Now, if you want to process pending exception first I can move the check result after, but for example the call above to `compare_and_normalize_class_versions` is done like this also
Hi @jpbempel, I couldn't see the equivalent form in `c_a_n_c_v` (returning early when there may be a pending exception).
> if merge_cp_and_rewrite returns anything else than JVMTI_ERROR_NONE it should be propagated.
Yeah, but you've got a `THREAD` call into a method taking `TRAPS` as an argument. A method taking `TRAPS` can be seen as one being able to throw, but we're doing the stack unwinding manually in the JVM.
As an example, in the code for `merge_cp_and_rewrite` the call to `ConstantPool::allocate` can set a pending exception. You can see this if you dig down into `MetadataFactory` and so on, look at `metaspace.cpp:33` and see the pending exception there.
So, by returning early, you're not handling the pending exception, which breaks the JVM.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2768496944
More information about the serviceability-dev
mailing list