On Mon, 15 Mar 2021 11:48:38 GMT, Robbin Ehn <r...@openjdk.org> wrote:
> When returning from the last Java frame back to vm and hitting a safepoint
> poll on that last return we sometimes have a last java frame but no vframe.
> This seem to be a bug in itself, handled in: 8263576
>
> Other places which uses vframe NULL checks it before, so let's do that in
> GetCurrentLocationClosure also.
>
> Testing: nsk jdi/jvmti, jdk jdi, jck vm and t1-3.
Thumbs up!
I agree that the code should have checked for "if (vf != NULL) {"
instead of asserting that "(vf != NULL)".
src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 263:
> 261: // There can be a race condition between a handshake
> 262: // and the target thread exiting from Java execution.
> 263: // We must recheck the last Java frame still exists.
Typo: s/recheck the last/recheck that the last/
(not your typo, but since you're in there...)
src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 266:
> 264: if (!jt->is_exiting() && jt->has_last_Java_frame()) {
> 265: javaVFrame* vf = jt->last_java_vframe(&rm);
> 266: assert(vf != NULL, "must have last java frame");
The code before we converted to handshakes also had this assert.
The pre-handshake code did the work in the doit() function for the
VM_GetCurrentLocation VM-op. This makes me wonder if we always
had frames here when this was previously done via VM-op? And that
makes me wonder whether handshakes is doing something different
so we don't always have a frame here?
-------------
Marked as reviewed by dcubed (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3010
