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.
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.
- relates to
-
JDK-8306591 SA and hotspot generate different hprof records for GC roots
-
- Open
-
-
JDK-6760477 SA: Update SA to include stack traces in the heap dump
-
- Resolved
-
-
JDK-8171084 heapdump/JMapHeapCore fails with java.lang.RuntimeException: Heap segment size overflow.
-
- Closed
-