Hi,
as described in https://bugs.openjdk.java.net/browse/JDK-8200579 it could be
useful to be able to specify an already existing 'file' to be able to stream
the heap dump directly to a named pipe on Windows or a tty or domain socket on
Unix, especially on systems with low disk space. Since we
On Wed, 24 Feb 2021 03:46:42 GMT, Lin Zang wrote:
> > But they are far more convenient and easier to understand than jcmd, so
> > will probably stay around. But you are right in that they could still all
> > be converted to use jcmd internally.
>
> Maybe we could consider using `jcmd` internal
On Wed, 24 Feb 2021 02:48:06 GMT, Chris Plummer wrote:
> It's too bad that the `dumpheap` command in previous JDKs has a slot for a
> 3rd argument, but doesn't look at it. Maybe that was intentional to allow for
> a new argument without causing a failure. What it means is if we want a
> failur
On Wed, 24 Feb 2021 03:24:46 GMT, Lin Zang wrote:
> > JDK-8251347 does not appear to be the correct bug. Can you find the one you
> > are referring too?
>
> oops, It should be https://bugs.openjdk.java.net/browse/JDK-8251374, sorry.
Ok, but that fix is on the client side, not the target VM sid
On Wed, 24 Feb 2021 02:48:06 GMT, Chris Plummer wrote:
> JDK-8251347 does not appear to be the correct bug. Can you find the one you
> are referring too?
oops, It should be https://bugs.openjdk.java.net/browse/JDK-8251374, sorry.
-
PR: https://git.openjdk.java.net/jdk/pull/2261
On Wed, 24 Feb 2021 01:08:58 GMT, Lin Zang wrote:
>>> I just realized that my understand is a little different with the
>>> "retrying" - if we already know what is newly added argument, we can assume
>>> old jvm can not accept it. So it seems print error message is enough. This
>>> is consist
On Tue, 23 Feb 2021 23:03:00 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/share/runtime/thread.cpp line 2568:
>>
>>> 2566: // this->is_handshake_safe_for() may crash, but we have debug bits
>>> so...
>>> 2567: assert(SafepointSynchronize::is_at_safepoint() ||
>>> 2568: this->is_
On Tue, 23 Feb 2021 23:52:15 GMT, Daniel D. Daugherty
wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() t
On Wed, 24 Feb 2021 00:40:03 GMT, Chris Plummer wrote:
>>> So in general, I think any solution we come up with will fail with older
>>> JDKs, and need to fallback to retrying with a command we know will work.
>>
>> Dear Chris,
>> I just realized that my understand is a little different with th
On Wed, 24 Feb 2021 00:22:16 GMT, Lin Zang wrote:
> I just realized that my understand is a little different with the "retrying"
> - if we already know what is newly added argument, we can assume old jvm can
> not accept it. So it seems print error message is enough. This is consistent
> with
On Mon, 22 Feb 2021 22:26:50 GMT, Yumin Qi wrote:
> Hi, Please review
>
> When debugging for other test case which uses jcmd to attach LingeredApp
> process, found there is no error information logged when the app started with
> function 'startAppExactJvmOpts' exits due to some reason. This i
On Wed, 24 Feb 2021 00:02:33 GMT, Lin Zang wrote:
> So in general, I think any solution we come up with will fail with older
> JDKs, and need to fallback to retrying with a command we know will work.
Dear Chris,
I just realized that my understand is a little different with the "retrying" -
i
On Wed, 24 Feb 2021 00:02:33 GMT, Lin Zang wrote:
>>> I have reconsidered the solution of “dumpheapext”, IMHO maybe the name is
>>> too specific, for example, if in future there is more arguments for
>>> `-histo`, we have to made another command called "inspectheapext".
>>>
>>> How about creat
On Tue, 23 Feb 2021 23:00:30 GMT, Chris Plummer wrote:
>> Dear @plummercj,
>>
>> I have reconsidered the solution of “dumpheapext”, IMHO maybe the name is
>> too specific, for example, if in future there is more arguments for
>> `-histo`, we have to made another command called "inspectheapext
> A minor fix to add a new function:
>
> bool Thread::is_JavaThread_protected(const JavaThread* p)
>
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected
On Mon, 22 Feb 2021 01:37:25 GMT, David Holmes wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address dholmes-ora CR1 comments.
>
> src/hotspot/share/compiler/compileBroker.cpp line 1115:
>
>> 1113:
On Sat, 20 Feb 2021 17:50:01 GMT, Daniel D. Daugherty
wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() t
On Tue, 23 Feb 2021 08:37:34 GMT, Lin Zang wrote:
> I have reconsidered the solution of “dumpheapext”, IMHO maybe the name is too
> specific, for example, if in future there is more arguments for `-histo`, we
> have to made another command called "inspectheapext".
>
> How about create a new co
On Tue, 23 Feb 2021 21:19:56 GMT, Yumin Qi wrote:
>> Hi, Please review
>>
>> When debugging for other test case which uses jcmd to attach LingeredApp
>> process, found there is no error information logged when the app started
>> with function 'startAppExactJvmOpts' exits due to some reason. T
On Tue, 23 Feb 2021 19:37:47 GMT, Ioi Lam wrote:
>> Yumin Qi has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a flag to remember finishApp already called
>
> LGTM
Looks good. Thanks!
-
PR: https://git.openjdk.java.net/j
> Hi, Please review
>
> When debugging for other test case which uses jcmd to attach LingeredApp
> process, found there is no error information logged when the app started with
> function 'startAppExactJvmOpts' exits due to some reason. This is not
> convenient for trace what is the app failur
On Tue, 23 Feb 2021 04:09:21 GMT, Yumin Qi wrote:
>> Although you have a point, you've also pointed out another problem with this
>> fix. I think users of `startApp()` are already going to see the output
>> twice because of the `finishApp()` call present there. By adding yet another
>> `finis
On Tue, 23 Feb 2021 05:02:58 GMT, Yumin Qi wrote:
>> Hi, Please review
>>
>> When debugging for other test case which uses jcmd to attach LingeredApp
>> process, found there is no error information logged when the app started
>> with function 'startAppExactJvmOpts' exits due to some reason. T
On Mon, 22 Feb 2021 21:36:52 GMT, Alex Menkov wrote:
>> The fix also partially fixes JdwpAttachTest failures (JDK-8253940).
>> The failures are caused by network configuration changes during test
>> execution ("global" IPv6 addresses disappears from interface).
>> To minimize chances of intermit
On Tue, 23 Feb 2021 08:37:34 GMT, Lin Zang wrote:
>> Dear @ralf,
>> Really Thanks for benchmarking it!
>> It is a little surprise to me that "parallel=1" is 10~20 percent slower than
>> before. I believe this can be avoid with some revise in code. And I also
>> found a potential memory leak in
On Tue, 23 Feb 2021 08:23:49 GMT, Lin Zang wrote:
>> Hi @linzang,
>>
>> I've done more benchmarking using different numbers of threads for parallel
>> heap iteration and have found values which give at least a factor of 2
>> speedup (for gzipped dumps) or 1.6 (for unzipped dumps). For my scena
On Tue, 23 Feb 2021 08:06:14 GMT, Ralf Schmelter wrote:
>> Hi @schmelter-sap,
>> Thanks a lot for reviewing and benchmarking.
>>
>>> I've benchmarked the code on my machine (128GB memory, 56 logical CPUs)
>>> with an example creating a 32 GB heap dump. I only saw a 10 percent
>>> reduction in
On Mon, 22 Feb 2021 07:36:55 GMT, Lin Zang wrote:
>> Hi,
>>
>> I've benchmarked the code on my machine (128GB memory, 56 logical CPUs) with
>> an example creating a 32 GB heap dump. I only saw a 10 percent reduction in
>> time, both using uncompressed and compressed dumps. Have you seen better
28 matches
Mail list logo
