When returning from the last Java frame back to vm and hitting a safepoint poll on that return:
We call the SafepointBlob, which handles return polls, it setup last java frame.
Here we have some inconsistencies on exactly how that looks, sometimes we have a last java frame but no vframe and sometimes no last Java frame at all, result depending on C1 or C2 code on x64. (other platforms may have similar inconsistencies)
Since we have no nmethod on stack anymore, I believe in this case we should not have a last java frame at all.
Last java sp seems to be setup from rsp.

Here is an example:
Stack: [0x00000268ef610000,0x00000268ef710000], sp=0x00000268ef70afc0, free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x507969] GetCurrentLocationClosure::do_thread+0xb9 (jvmtiEnvThreadState.cpp:267)
V [jvm.dll+0x33c019] HandshakeOperation::do_handshake+0x49 (handshake.cpp:312)
V [jvm.dll+0x33cd59] HandshakeState::process_self_inner+0x109 (handshake.cpp:456)
V [jvm.dll+0x33cc31] HandshakeState::process_by_self+0x51 (handshake.cpp:441)
V [jvm.dll+0x6c24a4] SafepointMechanism::process_if_requested_slow+0x54 (safepointMechanism.cpp:138)
V [jvm.dll+0x6bfa83] ThreadSafepointState::handle_polling_page_exception+0x1e3 (safepoint.cpp:944)
C 0x000002681430e387

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v ~SafepointBlob
v ~StubRoutines::call_stub

GetCurrentLocationClosure::do_thread used to expect that a vframe would exists if a has last java frame returned true.

I think has_last_Java_frame() should always be false in this case.