On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov wrote:
> The fix updates HeapMerger to use writer buffer (no need to copy memory, also
> writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of
> `size_t` is a typo, the argument should
On Fri, 19 Apr 2024 00:10:12 GMT, Alex Menkov wrote:
> The fix updates HeapMerger to use writer buffer (no need to copy memory, also
> writer buffer is 1MB instead of 4KB).
> Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of
> `size_t` is a typo, the argument should
On Tue, 14 May 2024 01:53:20 GMT, Alex Menkov wrote:
>> The fix updates descriptions of `HeapDumpPath`/`HeapDumpGzipLevel` and
>> `HeapDumpBeforeFullGC`/`HeapDumpAfterFullGC`/`HeapDumpOnOutOfMemoryError` VM
>> options
>
> Alex Menkov has updated the pull request incrementally with one
On Mon, 15 Apr 2024 23:18:54 GMT, Alex Menkov wrote:
>> The fix makes VM heap dumping parallel by default.
>> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the
>> fix affects `HotSpotDiagnosticMXBean.dumpHeap()`,
>> `-XX:+HeapDumpBeforeFullGC`,
On Tue, 2 Apr 2024 00:40:37 GMT, Alex Menkov wrote:
> The fix updated HeapDumper to always perform merge on the current thread.
>
> Testing: tier1-5, all HeapDump-related tests
> Covered heap dumping scenarios:
> - `jcmd GC.heap_dump` command;
> - `HotSpotDiagnosticMXBean.dumpHeap()`;
On Tue, 12 Mar 2024 07:59:12 GMT, Yi Yang wrote:
> We've received feedback from users of cloud APM platform wanting the new
> version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap
> underpinnings to reduce STW time using sgemented heapdump. Supporting
> segmen
On Thu, 14 Mar 2024 08:49:45 GMT, Matthias Baesken wrote:
> > Looks reasonable, this is a harmless change, but the name
> > `dump_to_heapdump_path` looks too details(and somewhat strange) to me
>
> Do you maybe have a good suggestion for a new name ?
Maybe `dump` and `dump_to`
-
On Tue, 12 Mar 2024 12:22:41 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Wed, 13 Mar 2024 20:01:22 GMT, Kevin Walls wrote:
>> We've received feedback from users of cloud APM platform wanting the new
>> version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap
>> underpinnings to reduce STW time using sgemented heapdump. Supporting
>> segmented heapdump
We've received feedback from users of cloud APM platform wanting the new
version of the JDK to allow the HotSpotDiagnosticMXBean.dumpHeap underpinnings
to reduce STW time using sgemented heapdump. Supporting segmented heapdump for
mxbean is a reasonable requirement and adds little additional
On Wed, 31 Jan 2024 14:22:44 GMT, Kevin Walls wrote:
> Introduce the jcmd "VM.debug" to implement access to a useful set of the
> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>
> Not recommended for live production use. Calling these "debug" utilities,
> and not
On Fri, 8 Dec 2023 22:29:12 GMT, Alex Menkov wrote:
> Original fix for JDK-8299426 (Heap dump does not contain virtual Thread stack
> references, #16665) caused failures of new test (added while #16665 was under
> review):
> test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndHeapDump.java
On Tue, 14 Nov 2023 21:54:06 GMT, Alex Menkov wrote:
> The change impelements dumping of unmounted virtual threads data (stack
> traces and stack references).
> Unmounted vthreads can be detected only by iterating over the heap, but hprof
> stack trace records (HPROF_FRAME/HPROF_TRACE) should
On Thu, 2 Nov 2023 20:44:14 GMT, Alex Menkov wrote:
>> Segment file is closed from DumpWriter dtor.
>> On Unix systems `remove` can delete an opened file, on Windows it fails with
>> "access denied".
>> The fix destroys DumpWriter objects for segment files after all data are
>> dumped
>
> Alex
On Thu, 21 Sep 2023 02:12:06 GMT, Yi Yang wrote:
> I had not noticed this PR sorry. I do not like the fact we have Linux-only
> functionality being added with no intent to supply similar functionality on
> other platforms. I also do not like the fact we had to ifdef the L
On Thu, 21 Sep 2023 01:18:19 GMT, David Holmes wrote:
> I had not noticed this PR sorry. I do not like the fact we have Linux-only
> functionality being added with no intent to supply similar functionality on
> other platforms. I also do not like the fact we had to ifdef the Linux code
> into
On Fri, 11 Aug 2023 09:31:56 GMT, Yi Yang wrote:
> This patch reduce ~16%(24s->20s) pahse 2 merge time during dumping 32g heap
> with 96threads and fixes a memory leak of compressor
>
> You might argue why this is Linux-only optimization, because sendfile
> requires
On Mon, 18 Sep 2023 11:09:36 GMT, Kevin Walls wrote:
> Apologies for delay, had looked at this previously but not come back for
> final review.
Never mind:) Thanks @alexmenkov and @kevinjwalls for the reviews.
-
PR Comment:
On Thu, 7 Sep 2023 02:19:10 GMT, Yi Yang wrote:
>> This patch reduce ~16%(24s->20s) pahse 2 merge time during dumping 32g heap
>> with 96threads and fixes a memory leak of compressor
>>
>> You might argue why this is Linux-only optimization, because sendfile
>
On Thu, 7 Sep 2023 00:56:40 GMT, Alex Menkov wrote:
>> This patch reduce ~16%(24s->20s) pahse 2 merge time during dumping 32g heap
>> with 96threads and fixes a memory leak of compressor
>>
>> You might argue why this is Linux-only optimization, because sendfile
>> requires at least socket fd
On Thu, 7 Sep 2023 00:56:40 GMT, Alex Menkov wrote:
> The fix looks good to me in general, but I'm not sure about code
> organization. src/hotspot/share/runtime/os.hpp describes rules for os* files.
> It states: // Platform-independent source files should not include these
> header files //
i/mswsock/nf-mswsock-transmitfile)),
> while [only Linux](https://man7.org/linux/man-pages/man2/sendfile.2.html)
> supports both two file descriptors.
Yi Yang has updated the pull request incrementally with one additional commit
since the last revision:
one merge_file for all
On Fri, 11 Aug 2023 09:31:56 GMT, Yi Yang wrote:
> This patch reduce ~16%(24s->20s) pahse 2 merge time during dumping 32g heap
> with 96threads and fixes a memory leak of compressor
>
> You might argue why this is Linux-only optimization, because sendfile
> requires
On Wed, 9 Aug 2023 07:02:34 GMT, Yi Yang wrote:
> This is a follow-up patch of #13667. verifyHeapDump is duplicated in several
> tests, this patch tries to consolidate them into one method.
This pull request has now been integrated.
Changeset: 75d4ac26
Author: Yi Yang
URL:
> This is a follow-up patch of #13667. verifyHeapDump is duplicated in several
> tests, this patch tries to consolidate them into one method.
Yi Yang has updated the pull request incrementally with one additional commit
since the last revision:
Update HeapDumpTes
On Fri, 11 Aug 2023 09:31:56 GMT, Yi Yang wrote:
> This patch reduce ~16%(24s->20s) pahse 2 merge time during dumping 32g heap
> with 96threads and fixes a memory leak of compressor
>
> You might argue why this is Linux-only optimization, because sendfile
> requires
On Thu, 10 Aug 2023 19:29:27 GMT, Alex Menkov wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix TestHeapDumpForInvokDynamic
>
> test/hotspot/jtreg/serviceability/sa/TestHeapDumpFo
> This is a follow-up patch of #13667. verifyHeapDump is duplicated in several
> tests, this patch tries to consolidate them into one method.
Yi Yang has updated the pull request incrementally with one additional commit
since the last revision:
review from Alex
-
C
On Thu, 10 Aug 2023 09:41:29 GMT, Yi Yang wrote:
>> This is a follow-up patch of #13667. verifyHeapDump is duplicated in several
>> tests, this patch tries to consolidate them into one method.
>
> Yi Yang has updated the pull request incrementally with one additional commit
> This is a follow-up patch of #13667. verifyHeapDump is duplicated in several
> tests, this patch tries to consolidate them into one method.
Yi Yang has updated the pull request incrementally with one additional commit
since the last revision:
fix TestHeapDumpForInvokD
This is a follow-up patch of #13667. verifyHeapDump is duplicated in several
tests, this patch tries to consolidate them into one method.
-
Commit messages:
- 8311775: [TEST] duplicate verifyHeapDump in several tests
Changes: https://git.openjdk.org/jdk/pull/15202/files
Webrev:
On Wed, 26 Apr 2023 09:37:46 GMT, Yi Yang 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, al
On Tue, 8 Aug 2023 13:09:58 GMT, Kevin Walls wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> aware of serialgc and epsilongc
>
> Great, thanks for your patience with all of this!
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g | 9
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g |
On Tue, 8 Aug 2023 07:41:23 GMT, Kevin Walls wrote:
> It's not too bad to change the test to launch a LingeredApp and test the
> output, I made an attempt at that. I'll share a testcase suggestion here, see
> what you think.
Thank you for the share! It makes sense to me. This test will start
On Fri, 4 Aug 2023 16:31:28 GMT, Kevin Walls wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> new can_parallel_dump
>
> test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpParal
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g |
On Thu, 3 Aug 2023 13:24:19 GMT, Kevin Walls wrote:
> Also the variable num_requested_dump_thread is not needed? It's just a copy
> of _num_dumper_threads which we don't change.
This is needed because _num_dumper_threads will change later, the requested
dump thread may not equal to actual
On Wed, 2 Aug 2023 13:11:51 GMT, Kevin Walls wrote:
> >
>
> Yes, dividing testing by feature so we have HeapDumpTest,
> HeapDumpCompressedTest, HeapDumpParallelTest... that sounds good.
>
> Currently the HeapDumpTest does more parallel testing than
> IntegrityHeapDumpTest, so I didn't
On Wed, 2 Aug 2023 18:02:22 GMT, Chris Plummer wrote:
> so I'm still wondering how this use of SATestUtils.createProcessBuilder()
> got in this new test in the first place
I simply grep existing tests and found this snippet to create java process.
There is no special intention, it is an
.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 | 96 T | C1 | 16.8101551 | 17.938 |
>
.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 | 96 T | C1 | 16.8101551 | 17.938 |
>
On Wed, 2 Aug 2023 11:33:17 GMT, Yi Yang 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
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g |
On Tue, 1 Aug 2023 17:48:30 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/serviceability/HeapDump/IntegrityHeapDumpTest.java line
>> 84:
>>
>>> 82: .addToolArg(heapDumpFile.getAbsolutePath());
>>> 83:
>>> 84: ProcessBuilder processBuilder = new
>>>
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g | 96
On Tue, 1 Aug 2023 14:41:53 GMT, Kevin Walls wrote:
> I just saw a run with no -parallel option which got num_active_workers = 2,
> so it did a parallel dump, so the default is being set as intended, but the
> availability of worker threads is not always predictable!
Yes, now I've added new
On Wed, 19 Jul 2023 12:42:27 GMT, Yi Yang 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
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g |
On Fri, 28 Jul 2023 17:18:05 GMT, Kevin Walls wrote:
> I think we might be best off leaving the long dump as you have it in the
> AttachListener for now. 8-)
Consideing a very large heap size, the VM used to pause all threads and spend 1
hour to execute a heap dump, during which time
On Tue, 11 Jul 2023 20:49:35 GMT, Chris Plummer wrote:
>> Yi Yang has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - whitespace
>> - add test
>
> BTW, `serviceability/dcmd/gc/HeapDumpAllTest.java`
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g |
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g | 96
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g | 9
On Mon, 17 Jul 2023 04:11:54 GMT, David Holmes wrote:
> > Because I need the overloaded check is_AttachListener_thread(), which can
> > avoid using the VM thread to execute the dump file merge as much as
> > possible.
>
> I'm unclear what the set of candidate threads is for executing the code
On Wed, 12 Jul 2023 07:58:47 GMT, Yi Yang 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
.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 | 96 T | C1 | 16.8101551 | 17.938 |
> | 64g |
.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 | 96 T | C1 | 16.8101551 | 17.938 |
>
On Wed, 5 Jul 2023 21:10:56 GMT, Alex Menkov wrote:
>> I think commit "use HandshakeClosure instead of VMOperation" is a wrong way
>> to go.
>> It restricts use of parallel dumping only to attach case.
>> I have pending changes in heap dumper to support virtual threads and I'm
>> going switch
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs |
On Fri, 30 Jun 2023 22:23:19 GMT, Alex Menkov wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> memory leak
>
> I think commit "use HandshakeClosure instead of VMOperation" is
On Tue, 16 May 2023 18:41:26 GMT, Chris Plummer wrote:
>> Hi, can I have a review for this patch?
>
> @y1yang0 Sorry no one has been able to review this so far. The serviceability
> team is very busy for the next few weeks finishing up JDK 21 changes before
> RDP1. It's unlikely we'll find
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.09546
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs |
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 secs | 9
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 s
On Sat, 17 Jun 2023 01:20:21 GMT, Alex Menkov wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> whitespace
>
> Could you please add info about what testing have been done
Hi @alexmenkov
On Sat, 17 Jun 2023 01:22:54 GMT, Alex Menkov wrote:
> This change adds new option. most likely this requires CSR
Hi @alexmenkov, it seems that adding new parameters to jcmd does not require a
CSR, only changes like those to jmap do.
-
PR Review Comment:
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954
> | 32g | 32 thread | 10.7734677 secs | 61.643 secs | N |
> | 32g | 32 thread | 10.1642097 secs | 10.903 secs | Compress1 |
> | 32g | 32 thread | 43.8407607 secs | 88.152 secs | Compress2 |
> | 32g | 96 thread | 13.1522042 secs | 61.432 secs | N |
> | 32g | 96 thread | 9.0954641 se
On Tue, 16 May 2023 18:41:26 GMT, Chris Plummer wrote:
>> Hi, can I have a review for this patch?
>
> @y1yang0 Sorry no one has been able to review this so far. The serviceability
> team is very busy for the next few weeks finishing up JDK 21 changes before
> RDP1. It's unlikely we'll find
s | 9.885 secs | Compress1 |
> | 32g | 96 thread | 38.9900931 secs | 80.574 secs | Compress2 |
> | 64g | 1 thread | 100.583 secs | 100.583 secs | N |
> | 64g | 32 thread | 20.9233744 secs | 134.701 secs | N |
> | 64g | 32 thread | 18.5023784 secs | 19.358 secs | Compress1 |
> | 64g | 32 t
s | 9.885 secs | Compress1 |
> | 32g | 96 thread | 38.9900931 secs | 80.574 secs | Compress2 |
> | 64g | 1 thread | 100.583 secs | 100.583 secs | N |
> | 64g | 32 thread | 20.9233744 secs | 134.701 secs | N |
> | 64g | 32 thread | 18.5023784 secs | 19.358 secs | Compress1 |
> | 64g | 32 t
On Mon, 5 Jun 2023 23:44:04 GMT, Alex Menkov wrote:
> A lot of code movement is caused by moving AbstractDumpWriter class from
> heapDumper.cpp to heapDumpCompression.hpp/cpp
> I'm not happy with huge heapDumper.cpp file, but this refactoring does not
> look good to me.
> Currently all logic
On Thu, 18 May 2023 11:02:21 GMT, Yi Yang wrote:
> I'm interested in if it is faster in STW time with the parallel write to use
> compression or not? (Does not compressing take time, or does compressing mean
> we write fewer bytes, so ends up being faster.)
I updated the benchmark
On Thu, 18 May 2023 09:35:36 GMT, Kevin Walls wrote:
> I'm interested in if it is faster in STW time with the parallel write to use
> compression or not? (Does not compressing take time, or does compressing mean
> we write fewer bytes, so ends up being faster.)
Hi @kevinjwalls, so far all
verall
> time for heapdump(See table above). However, considering the reduction of STW
> time, I think it is an acceptable trade-off. Furthermore, there is still room
> for optimization in the second merge stage(e.g.
> sendfile/splice/copy_file_range instead of read+write combination)
On Mon, 15 May 2023 02:16:43 GMT, Yi Yang wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> execute VM_HeapDumper directly
>
> Hi, can I have a review for this patch?
> @y1yang0 Sor
On Wed, 10 May 2023 08:29:43 GMT, Yi Yang wrote:
>> 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
to
> hearing comments and discussions about this solution.
>
> - Client parser support for segmented heap dump
> This patch provides a possibility that whether heap dump needs to be complete
> or not, can the VM directly generate segmented heapdump, and let the client
> parser com
On Thu, 4 May 2023 08:40:10 GMT, Yi Yang wrote:
>> 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
to
> hearing comments and discussions about this solution.
>
> - Client parser support for segmented heap dump
> This patch provides a possibility that whether heap dump needs to be complete
> or not, can the VM directly generate segmented heapdump, and let the client
> parser co
to
> hearing comments and discussions about this solution.
>
> - Client parser support for segmented heap dump
> This patch provides a possibility that whether heap dump needs to be complete
> or not, can the VM directly generate segmented heapdump, and let the client
> parser comp
to
> hearing comments and discussions about this solution.
>
> - Client parser support for segmented heap dump
> This patch provides a possibility that whether heap dump needs to be complete
> or not, can the VM directly generate segmented heapdump, and let the client
>
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
The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.
--
On Sun, 5 Mar 2023 05:46:37 GMT, David Holmes
On Tue, 3 Jan 2023 09:34:55 GMT, Yi Yang wrote:
> harmless refactor to share code across different platforms of
> VirtualMachineImpl:
> 1. Shared code to process command response after requesting a command
> execution
> 2. Read functionality in SocketInputStream can be re
On Fri, 3 Mar 2023 04:59:44 GMT, David Holmes wrote:
> Whilst working on the DCmd code I noticed two items that could be cleaned up:
>
> 1. The `NMTDCmd` is registered after the call to `register_dcmds()` instead
> of inside it.
>
> 2. The "extension" mechanism to define external DCmds (as
> harmless refactor to share code across different platforms of
> VirtualMachineImpl:
> 1. Shared code to process command response after requesting a command
> execution
> 2. Read functionality in SocketInputStream can be reused
Yi Yang has updated the pull request increme
On Thu, 5 Jan 2023 03:01:22 GMT, Serguei Spitsyn wrote:
>> Yi Yang has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request co
> harmless refactor to share code across different platforms of
> VirtualMachineImpl:
> 1. Shared code to process command response after requesting a command
> execution
> 2. Read functionality in SocketInputStream can be reused
Yi Yang has updated the pull request increme
On Tue, 10 Jan 2023 10:49:52 GMT, Yi Yang wrote:
>> harmless refactor to share code across different platforms of
>> VirtualMachineImpl:
>> 1. Shared code to process command response after requesting a command
>> execution
>> 2. Read functionality in SocketInputSt
On Wed, 11 Jan 2023 19:13:20 GMT, Chris Plummer wrote:
>> Yi Yang has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - format
>> - Merge branch 'jdk_virtualmachienimpl' of github.com:y1yang0/jdk into
>
ility Agent can also be used to analyze the contents of the class
metadata.
Dd you look at the existing tools and see how they match up with your
requirements?
I'd be interested in seeing your implementation and compare it with the
existing tools.
On 1/11/2023 4:56 AM, Yi Yang wrote:
Hi,
Internally, w
> harmless refactor to share code across different platforms of
> VirtualMachineImpl:
> 1. Shared code to process command response after requesting a command
> execution
> 2. Read functionality in SocketInputStream can be reused
Yi Yang has updated the pull request increment
> harmless refactor to share code across different platforms of
> VirtualMachineImpl:
> 1. Shared code to process command response after requesting a command
> execution
> 2. Read functionality in SocketInputStream can be reused
Yi Yang has updated the pull request increme
On Thu, 5 Jan 2023 04:28:46 GMT, David Holmes wrote:
> I was thinking more about describing what the parameters are - in particular
> it is unclear why the actual IOE can be replaced by a passed in one. If we
> wanted a custom message then I would at least expect to chain the actual IOE
> to
> harmless refactor to share code across different platforms of
> VirtualMachineImpl:
> 1. Shared code to process command response after requesting a command
> execution
> 2. Read functionality in SocketInputStream can be reused
Yi Yang has updated the pull request increme
On Fri, 6 Jan 2023 22:01:45 GMT, Chris Plummer wrote:
> I would also like to request that the variable renames be omitted from this
> PR. They create too much noise and would best left to a PR that focuses on
> just the renames and possibly other style changes.
Okay, reverted.
-
1 - 100 of 118 matches
Mail list logo
