Bug ID: JDK-8306591 SA and hotspot generate different hprof records for GC roots

Versions (Unresolved/Resolved/Fixed)

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
tbdUnresolved

If you look at the set of hprof records generated by SA and hotspot for GC roots, they differ in a few areas. I'm uncertain why, or if this can lead to incorrect heap representation:

The following records are generated by both hotspot and SA:

HPROF_GC_ROOT_THREAD_OBJ   thread object
HPROF_GC_ROOT_JNI_GLOBAL     JNI global ref root
HPROF_GC_ROOT_JNI_LOCAL       JNI local ref

The following records are generated only by hotspot:

HPROF_GC_ROOT_STICKY_CLASS    System class (HOTSPOT)
HPROF_GC_ROOT_JAVA_FRAME       Java stack frame (HOTSPOT)
HPROF_GC_ROOT_NATIVE_STACK    Native stack (HOTSPOT)

The following records are not generated by either SA or hotspot:

HPROF_GC_ROOT_UNKNOWN              unknown root
HPROF_GC_ROOT_MONITOR_USED    Busy monitor
HPROF_GC_ROOT_THREAD_BLOCK    Reference from thread block

Note there is also an HPROF_FRAME record that is generated by both and also an HPROF_TRACE record, which appears to be a stack trace referencing HPROF_FRAME records. These don't appear to be related to HPROF_GC_ROOT_JAVA_FRAME. 

There are also HPROF_GC_CLASS_DUMP records generated by both. I'm not sure how these relate to HPROF_GC_ROOT_STICKY_CLASS, which is only generated by hotspot.