JDK-8173053 : SA heapdumper discrepancies
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2017-01-19
  • Updated: 2024-07-11
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
Related Reports
Relates :  
Relates :  
Relates :  
Description
A cursory glance at the SA source seems to reveal some discrepancies with the heap dumper (esp compared to hotspot's heap dumper).

1. We seem to periodically check the segment lengths (and starting new segments if needed) after dumping various individual sub record types with check_segment_length() in heapDumper.cpp, but we don't seem to be doing this in SA. I feel this could cause issues when the cumulative sub-records would exceed the size of a segment.
2. With SA's heap dumper, we don't seem to be writing in sub-records of certain types -- say, HPROF_GC_ROOT_MONITOR_USED, HPROF_GC_ROOT_STICKY_CLASS, etc.
3. I find it a bit confusing that though the segment sizes are pegged at 1 GB through the sub records typically have a size limited by the size of an unsigned integer (which is 4 GB). And I believe that the sub-records should not exceed the size of the segment. 
Comments
(2) is covered by: JDK-8306591 - SA and hotspot generate different hprof records for GC roots Which provides more details on the GC root record discrepancies.
11-07-2024