Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2034213 | 1.4.0 | Daniel Daugherty | P3 | Resolved | Fixed | beta |
Intuitive Systems, Inc. (Claire Normand) reports:
Problem with Hotspot 1.3, 2.0 / JVMPI
PlatformL: Windows NT service pack 6 VM:1.3
Runtime: both hotspot 1.3 and 2.0
Problem: When using the hotspot runtime, the vm loads some classes
before loading the JVMPI agenbt. This bug prevents the JVMPI agent
from receiving CLASS_LOAD_HOOK and CLASS_LOAD events for classes that
are loaded before its initialization. With JVMPI, CLASS_LOAD is the
only opportunity for the profiler to learn about classes, including
ID, methods, .... Since other parts of JVMPI assume that the agent
knows all about classes (HEAP_DUMP, stack traces), this makes
Hotspot's JVMPI implementation unusable.
karen.kinnear@East 2000-05-31
Update from email exchange with Intuitive: See attachment "claire.2" for
email describing the need for
1) CLASS_LOAD events to obtain information such as jmethodIDs and
2) CLASS_LOAD_HOOK for bytecode instrumentation
The email also claims that both the classic runtime and IBM's runtime
manage to load the JVMPI agent before loading the first class.
karen.kinnear@East 2000-06-26
Classic does report the earlier classes that load. This bugfix is
targetted for Ladybird as the next Wintel release, given the fix
is too risky to add during beta2 for Kestrel Solaris. The concern
is the bootstrapping issue of ensuring we do not use any
classes (e.g. exception handling) in starting up the agent, that
are not yet loaded. Mail was sent to Intuitive 6/16/00.
Problem with Hotspot 1.3, 2.0 / JVMPI
PlatformL: Windows NT service pack 6 VM:1.3
Runtime: both hotspot 1.3 and 2.0
Problem: When using the hotspot runtime, the vm loads some classes
before loading the JVMPI agenbt. This bug prevents the JVMPI agent
from receiving CLASS_LOAD_HOOK and CLASS_LOAD events for classes that
are loaded before its initialization. With JVMPI, CLASS_LOAD is the
only opportunity for the profiler to learn about classes, including
ID, methods, .... Since other parts of JVMPI assume that the agent
knows all about classes (HEAP_DUMP, stack traces), this makes
Hotspot's JVMPI implementation unusable.
karen.kinnear@East 2000-05-31
Update from email exchange with Intuitive: See attachment "claire.2" for
email describing the need for
1) CLASS_LOAD events to obtain information such as jmethodIDs and
2) CLASS_LOAD_HOOK for bytecode instrumentation
The email also claims that both the classic runtime and IBM's runtime
manage to load the JVMPI agent before loading the first class.
karen.kinnear@East 2000-06-26
Classic does report the earlier classes that load. This bugfix is
targetted for Ladybird as the next Wintel release, given the fix
is too risky to add during beta2 for Kestrel Solaris. The concern
is the bootstrapping issue of ensuring we do not use any
classes (e.g. exception handling) in starting up the agent, that
are not yet loaded. Mail was sent to Intuitive 6/16/00.
- backported by
-
JDK-2034213 CLASS_LOAD events missing for early classes
- Resolved
- relates to
-
JDK-4449231 Many JVMPI IDs lack defining event. JVM on startup should send them to Clients.
- Closed
-
JDK-4384403 CLASS_LOAD_HOOK events missing for early classes
- Closed