RFR: 8262386: resourcehogs/serviceability/sa/TestHeapDumpForLargeArray.java timed out [v14]

[Lin Zang]

On Wed, 25 Aug 2021 09:23:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into sadump-fix
>>  - Merge branch 'master' into sadump-fix
>>  - Merge branch 'master' into s-fix
>>  - add comment for the timestamp value
>>  - Merge branch 'master' into s-fix
>>  - Fix typo and add comment
>>  - Merge branch 'master' into s-fix
>>  - fix typo in comments
>>  - Merge branch 'master' into s-fix
>>  - Merge branch 'master'
>>  - ... and 8 more: https://git.openjdk.java.net/jdk/compare/8fe9638f...a87793c3
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 592:
> 
>> 590:         // only process when segmented heap dump is not used, since SegmentedOutputStream
>> 591:         // could create segment automatically.
>> 592:         long currentRecordLength = (dumpEnd - currentSegmentStart - 4L);
> 
> As you moved this initialization inside the `if (!useSegmentedHeapDump)` condition then the `currentRecordLength` will be now equal to 0 for segmented heap dump as well.
> Could you, please, confirm it was your intention?

Yes, it is intended. 
The logic here is that when **not** using segmented dump, it needs to get the current data written size from the underlying file position, and then cut the array to satisfy that the U4 `size` slot does not overflow, as comments stats. 
But when it is in segmented dump, the previously written data has already written in the previous segment, it only need to consider that the current array size + the segment header size could satisfy the `size` slot.  so the `currentRecordLength` is zero.

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

PR: https://git.openjdk.java.net/jdk/pull/2803