I would like to finish the activity started by Man Cao [1] as we received 
several requests to support the dump over a network socket.   The original 
review stopped at the point where we needed to decide how to resolve the issue 
with the unmounted VT. Since none of the proposed solutions are 100% compatible 
with third-party HPROF tools, I opted for the simplest solution [2], which 
allows HPROF_HEAP_DUMP_SEGMENT to be mixed with HPROF_FRAME or HPROF_TRACE, 
breaking the linear sequence of top-level records. The related change is on 
line 
[2845](https://github.com/openjdk/jdk/pull/32733/changes#diff-bafe67cb93d9f50eb036e2aef63577ae58e78443343d6316251a6a283f398bcfR2845).

I’m still considering adding a guard option, such as `StrictSingleFileDump`, to 
explicitly enable the new behavior. Otherwise, the changes will automatically 
take effect on single-core instances. 

I have also refactored the original fix by moving all the segment writer code 
into a separate function. It should now look cleaner. 

Testing:
1. tier1 on release build
2. jtreg:test/hotspot/jtreg/serviceability on fast debug build

---------
- [x] I confirm that I make this contribution in accordance with the [OpenJDK 
Interim AI Policy](https://openjdk.org/legal/ai).

[1] https://github.com/openjdk/jdk/pull/18160
[2] https://github.com/openjdk/jdk/pull/18160#issuecomment-1985383273

-------------

Commit messages:
 - 8327645: Serial heap dump should not consume double amount of disk space

Changes: https://git.openjdk.org/jdk/pull/32733/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=32733&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327645
  Stats: 134 lines in 2 files changed: 71 ins; 35 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/32733.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/32733/head:pull/32733

PR: https://git.openjdk.org/jdk/pull/32733

Reply via email to