Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2134645 | 1.4.2_14 | Mike Belopuhov | P3 | Resolved | Fixed | b01 |
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.
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.
- backported by
-
JDK-2134645 delayed attach JVMPI clients hang after setup of JVMPI interface
- Resolved
- relates to
-
JDK-4852569 OBJ_ALLOC event deadlock between VMThread and Finalizer thread
- Resolved