Bug ID: JDK-8156498 more places in the invoke.c that need protection with the invokerLock

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdResolved

This is a fragment from my review of the fix:
  8153711: [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command

It seems, there are more places where an invokerLock critical section is missed.
The following functions:
  - invokeConstructor
  - invokeStatic
  - invokeNonvirtual
  - invokeVirtual
  - saveGlobalRef

These functions are called from the invoker_doInvoke() that we already had a problem with.

invoker_doInvoke() enters invokerLock, does a few things with the thread request struct, and then releases invokerLock. It then makes calls to the above 5 mentioned functions, all of which also touch the thread's request struct. However, I believe it is safe because while holding invokerLock, it does the following: request->available = JNI_FALSE; startNow = request->pending && !request->started; if (startNow) { request->started = JNI_TRUE; } And then after releasing invokerLock, but before calling any of the above 5 functions, it does the following: if (!startNow) { return JNI_FALSE; } So this should prevent entry into the code below that touches the thread request struct if there is another thread already in that code acting on the same thread request struct.
04-08-2021
[ @Severin ] Agreed. Removed the invoker_enableInvokeRequest from the description list. Also, corrected the rest of description that depended on this.
16-06-2018
Moving it to tbd_major. It does not look that important for 11.
17-04-2018
Retargeting this to 11 as we have never observed this issue with our tests/nightly yet.
12-04-2017
I believe invoker_enableInvokeRequest has been fixed with JDK-8154529.
09-09-2016

Relates :	JDK-8154529 - some places in the invoke.c that use InvokeRequest* not protected with invokerLock
Relates :	JDK-8193879 - Java debugger hangs on method invocation
Relates :	JDK-8153711 - [REDO] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command