RFR: JDK-8306441: Two phase segmented heap dump [v18]

Mon Jul 17 16:49:25 UTC 2023

On Mon, 17 Jul 2023 08:54:46 GMT, Yi Yang <yyang at 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:
>> 
>> ![image](https://github.com/openjdk/jdk/assets/5010047/77e4764a-62b5-4336-8b45-fc880ba14c4a)
>> <p align="center">Fig1. Before</p>
>> 
>> ![image](https://github.com/openjdk/jdk/assets/5010047/931ab874-64d1-4337-ae32-3066eed809fc)
>> <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 two additional commits since the last revision:
> 
>  - fix SA thread name
>  - sa AttachListenerThread counterpart

Changes requested by cjplummer (Reviewer).

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 169:

> 167:     /** NOTE: this returns objects of type JavaThread, CompilerThread,
> 168:       JvmtiAgentThread, NotificationThread, AttachListenerThread,
> 169:       MonitorDeflationThread and ServiceThread. Most operations

StringDedupThread was previously missed from this comment. Can you fix this also?

I think the "The latter four are subclasses of the former" comment should stay since all the text the follows relates to this. I just needs to be correct to say "seven" instead of "four".

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 175:

> 173:       changed from the definition in the VM (which returns true for
> 174:       all of these thread types) to return true for JavaThreads and
> 175:       false for the five subclasses. FIXME: should reconsider the

"five" -> "seven"

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 199:

> 197:         } catch (Exception e) {
> 198:             throw new RuntimeException("Unable to deduce type of thread from address " + threadAddr +
> 199:             " (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, ServiceThread or JvmtiAgentThread)", e);

Add StringDedupThread thread.

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

PR Review: https://git.openjdk.org/jdk/pull/13667#pullrequestreview-1533209867
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1265627589
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1265629434
PR Review Comment: https://git.openjdk.org/jdk/pull/13667#discussion_r1265638775