> From users' perspective, we can find corresponding os thread via top
> directly, otherwise, we must convert hex format based nid to an integer, and
> find that thread via `top -pid `. This slightly facilitates our
> debugging process, but would obviously break some existing jstack analysis
>
On Wed, 30 Jun 2021 02:43:29 GMT, Yi Yang wrote:
>> From users' perspective, we can find corresponding os thread via top
>> directly, otherwise, we must convert hex format based nid to an integer, and
>> find that thread via `top -pid `. This slightly facilitates our
>> debugging process, but
On Wed, 30 Jun 2021 04:42:19 GMT, Thomas Stuefe wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update copyright
>
> test/hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java line 64:
>
>> 62:
>> 63: o
On Wed, 30 Jun 2021 02:43:29 GMT, Yi Yang wrote:
>> From users' perspective, we can find corresponding os thread via top
>> directly, otherwise, we must convert hex format based nid to an integer, and
>> find that thread via `top -pid `. This slightly facilitates our
>> debugging process, but
> From users' perspective, we can find corresponding os thread via top
> directly, otherwise, we must convert hex format based nid to an integer, and
> find that thread via `top -pid `. This slightly facilitates our
> debugging process, but would obviously break some existing jstack analysis
>
On Tue, 29 Jun 2021 11:54:55 GMT, Kevin Walls wrote:
>> Yi Yang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> restore cleanup code
>
> src/hotspot/share/runtime/osThread.cpp line 41:
>
>> 39: // Printing
>> 40: void OSThread::print_on
On Sat, 26 Jun 2021 17:48:15 GMT, Leonid Mesnik wrote:
> The crash happens because nmethod might become a zombie before it is enqueued
> in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is
> reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However,
> it t
On Tue, 29 Jun 2021 21:55:04 GMT, David Holmes wrote:
> Please see the JBS issue for more details, but basically we have 8 different
> kinds of internal VM JavaThreads (grouping the three types of CompilerThread
> together) that all basically duplicated the logic for initializing (preparing
>
> Please see the JBS issue for more details, but basically we have 8 different
> kinds of internal VM JavaThreads (grouping the three types of CompilerThread
> together) that all basically duplicated the logic for initializing (preparing
> is the term we use for user-defined JavaThreads) and sta
> Forwardport JDK 17 -> JDK 18
Jesper Wilhelmsson has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 113 commits:
- Merge
- 8269615: Fix for 8263640 broke Windows build
Reviewed-by: iklam, dcubed
- 8269268: JDWP: Properly fix t
On Wed, 30 Jun 2021 00:31:34 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 17 -> JDK 18
This pull request has now been integrated.
Changeset: ee526a2e
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.java.net/jdk/commit/ee526a2ea840aedb97b23538f9d624acbccebc97
Stats: 127 l
On Thu, 24 Jun 2021 16:51:59 GMT, Chris Plummer wrote:
>> Re-enable the assert that was disabled (with some overhead) by
>> [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation
>> is in the CR and also in comments included with the changes.
>>
>> I tested by running `vm
On Tue, 29 Jun 2021 21:55:04 GMT, David Holmes wrote:
> Please see the JBS issue for more details, but basically we have 8 different
> kinds of internal VM JavaThreads (grouping the three types of CompilerThread
> together) that all basically duplicated the logic for initializing (preparing
>
Forwardport JDK 17 -> JDK 18
-
Commit messages:
- Merge
- 8269034: AccessControlException for SunPKCS11 daemon threads
- 8269529: javax/swing/reliability/HangDuringStaticInitialization.java fails
in Windows debug build
- 8269232: assert(!is_jweak(handle)) failed: wrong method for
On Tue, 29 Jun 2021 16:38:28 GMT, Leonid Mesnik wrote:
>> The crash happens because nmethod might become a zombie before it is
>> enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The
>> crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java.
>> However,
On Tue, 29 Jun 2021 16:38:28 GMT, Leonid Mesnik wrote:
>> The crash happens because nmethod might become a zombie before it is
>> enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The
>> crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java.
>> However,
And apologies for the old commits - I forgot to clear them out before
creating the PR.
David
On 30/06/2021 8:33 am, David Holmes wrote:
Please see the JBS issue for more details, but basically we have 8 different
kinds of internal VM JavaThreads (grouping the three types of CompilerThread
to
Please see the JBS issue for more details, but basically we have 8 different
kinds of internal VM JavaThreads (grouping the three types of CompilerThread
together) that all basically duplicated the logic for initializing (preparing
is the term we use for user-defined JavaThreads) and starting th
On Thu, 24 Jun 2021 05:17:02 GMT, Chris Plummer wrote:
> Re-enable the assert that was disabled (with some overhead) by
> [JDK-8265683](https://bugs.openjdk.java.net/browse/JDK-8265683). Explanation
> is in the CR and also in comments included with the changes.
>
> I tested by running `vmTestb
On Mon, 28 Jun 2021 20:41:35 GMT, Chris Plummer wrote:
> Don't let node->strongRef go below 0, or we end up thinking we still have a
> strongref when it is a weakref. Note the fact that we are doing nesting
> counts is still a bug (and the main cause of this issue). However, the fix
> for that
On Tue, 22 Jun 2021 21:01:46 GMT, Alex Menkov wrote:
> Updated AllModulesCommandTest to use dynamic port launching debuggee.
> Parsing debuggee listening address functionality is required in several tests
> (and we have other tests which need to be fixed the same way), so moved the
> code to ne
On Tue, 29 Jun 2021 07:46:39 GMT, Leonid Mesnik wrote:
>> src/hotspot/share/code/nmethod.cpp line 1611:
>>
>>> 1609: return;
>>> 1610: }
>>> 1611: mark_as_seen_on_stack();
>>
>> Not obvious what this actually does in relation to the dequeuing problem.
>
> updated comments
I'm not
On Tue, 29 Jun 2021 16:38:28 GMT, Leonid Mesnik wrote:
>> The crash happens because nmethod might become a zombie before it is
>> enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The
>> crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java.
>> However,
On Tue, 29 Jun 2021 09:05:59 GMT, Kevin Walls wrote:
> I'm not sure in Debugee.java why we use an array for: JDWP.ListenAddress[]
> listenAddress
We set the value of the local variable in lambda, so the variable must be final
or (as in this case) effectively final
-
PR: https://g
> The crash happens because nmethod might become a zombie before it is enqueued
> in JvmtiDeferredEventQueue or after it is dequeued from it. The crash is
> reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java. However,
> it takes ~3K runs to hit it. I verified the fix by running t
On Tue, 29 Jun 2021 07:42:17 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment.
>
> I see the comment update in the PR and email, but no response to my comment
> about dequeuing with
On Tue, 29 Jun 2021 03:42:32 GMT, Yi Yang wrote:
>> From users' perspective, we can find corresponding os thread via top
>> directly, otherwise, we must convert hex format based nid to an integer, and
>> find that thread via `top -pid `. This slightly facilitates our
>> debugging process, but
On Mon, 28 Jun 2021 07:46:29 GMT, Yi Yang wrote:
>> From users' perspective, we can find corresponding os thread via top
>> directly, otherwise, we must convert hex format based nid to an integer, and
>> find that thread via `top -pid `. This slightly facilitates our
>> debugging process, but
On Tue, 29 Jun 2021 03:42:32 GMT, Yi Yang wrote:
>> From users' perspective, we can find corresponding os thread via top
>> directly, otherwise, we must convert hex format based nid to an integer, and
>> find that thread via `top -pid `. This slightly facilitates our
>> debugging process, but
On Tue, 29 Jun 2021 07:51:52 GMT, Leonid Mesnik wrote:
>> src/hotspot/share/prims/jvmtiImpl.cpp line 968:
>>
>>> 966: for (QueueNode* node = _queue_head; node != NULL; node =
>>> node->next()) {
>>> 967: node->event().post_compiled_method_load_event(env);
>>> 968: }
>>
>> Can't you deq
On Mon, 28 Jun 2021 20:41:35 GMT, Chris Plummer wrote:
> Don't let node->strongRef go below 0, or we end up thinking we still have a
> strongref when it is a weakref. Note the fact that we are doing nesting
> counts is still a bug (and the main cause of this issue). However, the fix
> for that
On Tue, 22 Jun 2021 21:01:46 GMT, Alex Menkov wrote:
> Updated AllModulesCommandTest to use dynamic port launching debuggee.
> Parsing debuggee listening address functionality is required in several tests
> (and we have other tests which need to be fixed the same way), so moved the
> code to ne
On Wed, 9 Jun 2021 19:04:54 GMT, Serguei Spitsyn wrote:
>> When the signal sent for AsyncGetCallTrace or JFR would land on a runtime
>> stub (like arraycopy), a vtable stub, or the prolog of a compiled method,
>> it wouldn't be able to detect the sender (caller) frame for multiple
>> reasons.
On Tue, 29 Jun 2021 02:23:25 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment.
>
> src/hotspot/share/prims/jvmtiImpl.cpp line 968:
>
>> 966: for (QueueNode* node = _queue_head; no
On Tue, 29 Jun 2021 02:23:58 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment.
>
> src/hotspot/share/code/nmethod.cpp line 1611:
>
>> 1609: return;
>> 1610: }
>> 1611:
On Tue, 29 Jun 2021 05:52:38 GMT, Leonid Mesnik wrote:
>> The crash happens because nmethod might become a zombie before it is
>> enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The
>> crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java.
>> However,
On Tue, 29 Jun 2021 05:52:38 GMT, Leonid Mesnik wrote:
>> The crash happens because nmethod might become a zombie before it is
>> enqueued in JvmtiDeferredEventQueue or after it is dequeued from it. The
>> crash is reproduced by serviceability/jvmti/CompiledMethodLoad/Zombie.java.
>> However,
37 matches
Mail list logo
