On Mon, 28 Jun 2021 06:16:14 GMT, Thomas Stuefe 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
> 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 Mon, 28 Jun 2021 07:37:10 GMT, Yi Yang wrote:
>> src/hotspot/share/runtime/osThread.cpp line 41:
>>
>>> 39: // Printing
>>> 40: void OSThread::print_on(outputStream *st) const {
>>> 41: st->print("nid=%d ", thread_id());
>>
>> thread_id is of an opaque type (eg pthread_t). I think we can r
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 Mon, 28 Jun 2021 08:58:09 GMT, Kevin Walls wrote:
> Hi,
> If you attach WinDbg on Windows to a JVM, you might be glad of the nid=0x...
> format as that is its choice of base for the thread ids.
> So this depends on your tools. Maybe frustrated top users outnumber happy
> WinDbg users for the
On Mon, 28 Jun 2021 09:16:33 GMT, Thomas Stuefe wrote:
> Why not do it platform dependent then? ...
Checked Visual Studio, and that goes with decimal for thread IDs. 8-)
It's the tools rather than the platform. But yes, hex for thread IDs seems to
be in the minority. (I have occasionally fou
On Sat, 26 Jun 2021 23:55:46 GMT, Weijun Wang wrote:
>> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java
>> line 53:
>>
>>> 51: private static final long CURRENT_PID =
>>> AccessController.doPrivileged(
>>> 52: (PrivilegedAction)
>>> ProcessHandle::curr
On 28/06/2021 6:49 pm, Thomas Stuefe wrote:
On Mon, 28 Jun 2021 07:37:10 GMT, Yi Yang wrote:
src/hotspot/share/runtime/osThread.cpp line 41:
39: // Printing
40: void OSThread::print_on(outputStream *st) const {
41: st->print("nid=%d ", thread_id());
thread_id is of an opaque type (eg pth
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
one more ref
On Fri, 25 Jun 2021 23:40:27 GMT, Weijun Wang wrote:
>> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>>
>> Sometimes I introduce new methods. Please feel free to suggest method names
>> you like to use.
>
> Weijun Wang has updated the pull request incrementally with o
On Mon, 28 Jun 2021 12:20:38 GMT, Daniel Fuchs wrote:
>> This cast is only to tell the compiler which overloaded method to call, and
>> I don't think there will be a real cast at runtime. It might look a little
>> ugly but extracting it into a variable declaration/definition plus a new
>> `ini
On Fri, 18 Jun 2021 06:14:49 GMT, Yi Yang wrote:
> Do you think this would facilitate debugging process? And is it acceptable?
> Any feedback is appreciated!
My first comments were to say that this makes things better for some people,
but a little worse for others.
Maybe overall this looks lik
On Mon, 28 Jun 2021 12:41:35 GMT, David Holmes wrote:
> > You'd do:
> > print("nid: " UINT64_FORMAT, (uint64_t) id):;
> > thread_t is, among other things, pthread_t, which is opaque. Any current
> > code treating that as signed int is incorrect too.
>
> If it is opaque then I don't see how sign
On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang wrote:
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
This pull request has been closed without being integrated.
---
More refactoring to limit the scope of `@SuppressWarnings` annotations.
Sometimes I introduce new methods. Please feel free to suggest method names you
like to use.
Note: this is copied from https://github.com/openjdk/jdk17/pull/152.
-
Commit messages:
- copy all code change from
On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang wrote:
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
>
> Note: this is copied from https://github.com/openjdk/jdk17/pull/
On Mon, 28 Jun 2021 18:03:56 GMT, Weijun Wang wrote:
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
>
> Note: this is copied from https://github.com/openjdk/jdk17/pull/
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 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
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 is
more complex, and for 17 I would prefer to just apply this si
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 this test
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 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 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 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 Fri, 18 Jun 2021 06:51:53 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Could I have a review of this change that merges three vm
>> operations(VM_PrintThreads, VM_PrintJNI, VM_FindDeadlocks) in thread_dump
>> and signal_thread_entry.
>>
>> `jstack` is a very common command, even in the production
On Mon, 28 Jun 2021 21:36:08 GMT, Serguei Spitsyn 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 co
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 Mon, 28 Jun 2021 13:07:21 GMT, Kevin Walls wrote:
> If so (and if we don't discover more tools that prefer hex for thread IDs!),
> then we want to be consistent, so in addition to the native/built in
> implementation, we should also update:
> src/jdk.hotspot.agent/share/classes/sun/jvm/hots
> 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
>
> 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 02:24:37 GMT, David Holmes wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added comment.
>
> Hi Leonid,
>
> I'm not clear on the details here - please see comments below.
>
> Thanks,
> David
33 matches
Mail list logo
