Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8045218 | 8u25 | Serguei Spitsyn | P3 | Resolved | Fixed | b01 |
JDK-8035043 | 8u20 | Serguei Spitsyn | P3 | Resolved | Fixed | b03 |
JDK-8053223 | emb-8u26 | Serguei Spitsyn | P3 | Resolved | Fixed | b17 |
JVMTI_EVENT_DYNAMIC_CODE_GENERATED for "vtable stub" gets scheduled when a new chunk of memory for subsequent vtable and itable stubs is allocated. That chunk is uninitialized (contains zeros or garbage) although due to the fact that the actual event delivery is deferred, at least one vtable comes out right. This event should describe an individual vtable/itable stub (base address and size) and only after it's been created (memory is actually populated with code). Where VM diagnostic messages about vtable/itable stubs are issued upon -XX:+PrintAdapterHandlers appears exactly the right place for JVMTI events as well.
Getting vtables/itables right is important in the context of performance analysis as that dynamically generated code may accumulate quite noticeable CPU time (especially itabes), sometimes larger than the actual Java methods called.
Getting vtables/itables right is important in the context of performance analysis as that dynamically generated code may accumulate quite noticeable CPU time (especially itabes), sometimes larger than the actual Java methods called.
- backported by
-
JDK-8035043 JVMTI: "vtable stub" dynamic code notification is misplaced
-
- Resolved
-
-
JDK-8045218 JVMTI: "vtable stub" dynamic code notification is misplaced
-
- Resolved
-
-
JDK-8053223 JVMTI: "vtable stub" dynamic code notification is misplaced
-
- Resolved
-
- duplicates
-
JDK-6533620 vtable stubs notification for JVMTI should happen after they are filled in
-
- Closed
-