RFR: 8286580: serviceability/jvmti/vthread/GetSetLocalTest failed with assert: Not supported for heap frames [v2]

Chris Plummer cjplummer at openjdk.org
Wed Jun 22 23:50:39 UTC 2022


On Wed, 22 Jun 2022 21:23:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiImpl.cpp line 647:
>> 
>>> 645:   }
>>> 646:   if (_set) {
>>> 647:     if (fr.is_heap_frame()) { // we want this check after the check for JVMTI_ERROR_INVALID_SLOT
>> 
>> It would be good to elaborate a bit more on this check. Say something about it being a "safepoint poll on return in the oldest thawed frame", and why that is a problem.
>
> Okay. I'd suggest this:
> 
>   if (_set) {
>     if (fr.is_heap_frame()) { // we want this check after the check for JVMTI_ERROR_INVALID_SLOT
>       assert(Continuation::is_frame_in_continuation(_jvf->thread(), fr), "sanity check");
>       // The topmost frame of a mounted continuation can still be in the heap. This code is executed at safepoint.
>       // The safepoint could be as we return to the return barrier but before we execute it (poll return).
>       _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals currently unsupported in continuations
>       return;
>     }
> 
> Is it more clear?

I guess what I'm not understanding here is how/why "fr.is_heap_frame())" translates into "we are not single stepping or at a breakpoint". I know we already did the check earlier to make sure we are "depth == 0", and I understand that in this code we are handling the special case of "depth == 0" possibly not indicating we are truly in the topmost frame. From Ron's explanation, the frame has been popped, but the callee frame has not been thawed yet. Is the "fr.is_heap_frame())" check telling us the frame hasn't been thawed. If so, I would call this out in the comment. Basically say something like:

"If the topmost frame is a heap frame, then it hasn't been thawed. This can happen if we are executing at a return barrier safepoint. The callee frame has been popped, but the caller frame has not been thawed. We can't support a setlocal in the callee frame at this point, because we aren't truly in the callee yet."

Also, I think the following comment is misleading:

`deferred locals currently unsupported in continuations`

That's not true. They are supported when single stepping and at breakpoints, or more accurately, in the topmost frame. Looks like this is copy-n-paste from the following code with the same issue:


 613   if (_set && _depth != 0 && Continuation::is_frame_in_continuation(_jvf->thread(), fr)) {
 614     _result = JVMTI_ERROR_OPAQUE_FRAME; // deferred locals currently unsupported in continuations
 615     return;
 616   }

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

PR: https://git.openjdk.org/jdk19/pull/42


More information about the serviceability-dev mailing list