On Wed, 19 Jul 2023 12:42:27 GMT, Yi Yang <yy...@openjdk.org> wrote:
>> ### Motivation and proposal
>> Hi, heap dump brings about pauses for application's execution(STW), this is
>> a well-known pain. JDK-8252842 have added parallel support to heapdump in an
>> attempt to alleviate this issue. However, all concurrent threads
>> competitively write heap data to the same file, and more memory is required
>> to maintain the concurrent buffer queue. In experiments, we did not feel a
>> significant performance improvement from that.
>>
>> The minor-pause solution, which is presented in this PR, is a two-phase
>> segmented heap dump:
>>
>> - Phase 1(STW): Concurrent threads directly write data to multiple heap
>> files.
>> - Phase 2(Non-STW): Merge multiple heap files into one complete heap dump
>> file. This process can happen outside safepoint.
>>
>> Now concurrent worker threads are not required to maintain a buffer queue,
>> which would result in more memory overhead, nor do they need to compete for
>> locks. The changes in the overall design are as follows:
>>
>> 
>> <p align="center">Fig1. Before</p>
>>
>> 
>> <p align="center">Fig2. After this patch</p>
>>
>> ### Performance evaluation
>> | memory | numOfThread | CompressionMode | STW | Total |
>> | -------| ----------- | --------------- | --- | ---- |
>> | 8g | 1 T | N | 15.612 | 15.612 |
>> | 8g | 32 T | N | 2.561725 | 14.498 |
>> | 8g | 32 T | C1 | 2.3084878 | 14.198 |
>> | 8g | 32 T | C2 | 10.9355128 | 21.882 |
>> | 8g | 96 T | N | 2.6790452 | 14.012 |
>> | 8g | 96 T | C1 | 2.3044796 | 3.589 |
>> | 8g | 96 T | C2 | 9.7585151 | 20.219 |
>> | 16g | 1 T | N | 26.278 | 26.278 |
>> | 16g | 32 T | N | 5.231374 | 26.417 |
>> | 16g | 32 T | C1 | 5.6946983 | 6.538 |
>> | 16g | 32 T | C2 | 21.8211105 | 41.133 |
>> | 16g | 96 T | N | 6.2445556 | 27.141 |
>> | 16g | 96 T | C1 | 4.6007096 | 6.259 |
>> | 16g | 96 T | C2 | 19.2965783 | 39.007 |
>> | 32g | 1 T | N | 48.149 | 48.149 |
>> | 32g | 32 T | N | 10.7734677 | 61.643 |
>> | 32g | 32 T | C1 | 10.1642097 | 10.903 |
>> | 32g | 32 T | C2 | 43.8407607 | 88.152 |
>> | 32g | 96 T | N | 13.1522042 | 61.432 |
>> | 32g | 96 T | C1 | 9.0954641 | 9.885 |
>> | 32g | 96 T | C2 | 38.9900931 | 80.574 |
>> | 64g | 1 T | N | 100.583 | 100.583 |
>> | 64g | 32 T | N | 20.9233744 | 134.701 |
>> | 64g | 32 T | C1 | 18.5023784 | 19.358 |
>> | 64g | 32 T | C2 | 86.4748377 | 172.707 |
>> | 64g | 96 T | N | 26.7374116 | 126.08 |
>> | 64g | ...
>
> Yi Yang has updated the pull request incrementally with one additional commit
> since the last revision:
>
> test failure on Windows
AttachListener thread:
I was concerned we might occupy this thread for hundreds of seconds == a few
minutes for a large dump.
e.g. if you ping the JVM with a jcmd frequently, this will cause a
delay/failure.
The parallel dump has twice as much file io happening (not that it will take
twice as long).
But I realise that currently heap dumps happen in the Attach Listener, however
slow they are. It may be that slow operations like heap dump and histogram
should generally be worked on in another thread, but that is not a new problem.
So we should not do that as part of this change.
I was looking at ServiceThread, which gets woken up with Service_lock and has a
serial list of tasks it does. Thinking about using ServiceThread here for the
joining of the dump, the tool could be detached even while the dump was put
together ("parallel"!).
But that might have other impact, delaying another ServiceThread task if one is
needed. It would need testing...
I think we might be best off leaving the long dump as you have it in the
AttachListener for now. 8-)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13667#issuecomment-1656038465
