JDK-5023599 : delayed attach JVMPI clients hang after setup of JVMPI interface
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2004-03-30
  • Updated: 2004-04-12
  • Resolved: 2004-04-12
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
1.4.2_14Fixed
Related Reports
Relates :  
Description
Simple JVMPI clients hang after setup of JVMPI interface  and enablement of a few interfaces on 1.4.2 JVMs

We have some simple JVMPI clients that get the JVMPI interface via a native method call, without having specified -Xrun on the command line at start. I know this may not be strictly supported (JVMPI spec is not clear on the point), but it has worked up until now.

In particular, with current 1.4.2 JVMs, our client hangs shortly after having gotten the JVMPI interface and having enabled a few events, including JVMPI_EVENT_OBJECT_ALLOC. The threads appear to hang up in VM_JVMPIPostObjAlloc::wait_if_restricted().

Based on a quick skimming of the source, and I am by no means overly familiar with the HotSpot source, I think this is because event posting is restricted by default (_restrict_event_posting is set true), and cleared only in post_vm_initialization_events(). Since JVMPI is not enabled at startup, this routine is not called, and event posting stays restricted. I think that calling post_vm_initialization_events() regardless if jvmpi::enabled() is true or not would work; the other work in that routine wouldn't happen because it checks for specific events and the only effect would be the call to clear_restriction().

Or if when they set up the JVMPI interface they notice that the JVM is already initialized and and call VM_JVMPIPostObjAlloc::clear_restriction() that might work too.

As I say, I may be way off base with this, but if it is easy for them to re-enable this functionality (something that JVMTI explicitly allows, by the way, though possibly with reduced functionality) it would be great.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b47 tiger-beta2
2004-06-14

EVALUATION ###@###.### 2004-03-31 Section "1.1. Start-up" of the JVM/PI spec describes how an agent can be specified on the command line using the -XrunXXX syntax. Section "1.2. Function Call Interface" of the JVM/PI spec describes how to obtain the function call interface via a JNI GetEnv() call. While the example code shows this being done in the JVM_OnLoad() entry point, it does not have to be done that way. It certainly appears to me that obtaining the function call interface at a later time via a call to JNI GetEnv() is legal.
2004-06-11

PUBLIC COMMENTS .
2004-06-10

SUGGESTED FIX ###@###.### 2004-04-05 See the attached 5023599-webrev.tar.Z file for the proposed fix.
2004-04-05