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