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.
Justification:
 Customer finds JVMPI unusable without this fixed.

Justification by: karen.kinnear@east Date: 2000-06-26 Priority from 1 to 3:
Targetted for Ladybird, i.e. next Wintel release