Re: RFR: 8283147: Include NonJavaThread stacktrace during thread dump [v3]
On Wed, 16 Mar 2022 07:48:42 GMT, Yi Yang 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 contains one >> new commit since the last revision: >> >> 8283147: Include NonJavaThread stacktrace during thread dump > > Clarification on why there are some one-line frame: > > VMError::print_native_stack output > > "G1 Conc#7" os_prio=0 cpu=2.33ms elapsed=11.39s tid=0x7f635c004d70 > nid=71098 runnable > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [libpthread.so.0+0xdb39] do_futex_wait.constprop.1+0x29 > > > pstack outpout > > Thread 40 (Thread 0x7f62b3bf7700 (LWP 71098)): > #0 0x7f63d32a6b3b in do_futex_wait.constprop () from > /lib64/libpthread.so.0 > #1 0x7f63d32a6bcf in __new_sem_wait_slow.constprop.0 () from > /lib64/libpthread.so.0 > #2 0x7f63d32a6c6b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 > #3 0x7f63d23f7c32 in PosixSemaphore::wait > (this=this@entry=0x7f63cc077e78) at > /home/qingfeng.yy/jdktip/src/hotspot/os/posix/semaphore_posix.cpp:65 > #4 0x7f63d265b81b in Semaphore::wait (this=0x7f63cc077e78) at > /home/qingfeng.yy/jdktip/src/hotspot/share/runtime/semaphore.hpp:55 > #5 WorkerTaskDispatcher::worker_run_task (this=0x7f63cc077e68) at > /home/qingfeng.yy/jdktip/src/hotspot/share/gc/shared/workerThread.cpp:60 > #6 WorkerThread::run (this=0x7f635c004d70) at > /home/qingfeng.yy/jdktip/src/hotspot/share/gc/shared/workerThread.cpp:163 > #7 0x7f63d25aa790 in Thread::call_run (this=this@entry=0x7f635c004d70) > at /home/qingfeng.yy/jdktip/src/hotspot/share/runtime/thread.cpp:357 > #8 0x7f63d2348a28 in thread_native_entry (thread=0x7f635c004d70) at > /home/qingfeng.yy/jdktip/src/hotspot/os/linux/os_linux.cpp:706 > #9 0x7f63d32a0ea5 in start_thread () from /lib64/libpthread.so.0 > #10 0x7f63d2dc58dd in clone () from /lib64/libc.so.6 > > > The top frame is as follows: > > C frame (sp=0x7f6338ca0d90 unextended sp=0x7f6338ca0d90, > fp=0x7f63cc0667c8, real_fp=0x7f63cc0667c8, pc=0x7f63d32a6b39 > link=0x0009) > > do_futex_wait.constprop don't have a valid link/last_frame_pointer, because > libpthread has some novel assembly code: > > > db10 : > db10: 55 push %rbp > db11: 48 89 fdmov%rdi,%rbp > db14: 53 push %rbx > db15: 48 83 ec 08 sub$0x8,%rsp > db19: 8b 5f 08mov0x8(%rdi),%ebx > db1c: e8 1f 09 00 00 callq e440 > <__pthread_enable_asynccancel> > db21: 45 31 d2xor%r10d,%r10d > db24: 41 89 c0mov%eax,%r8d > db27: 31 d2 xor%edx,%edx > db29: 89 de mov%ebx,%esi > db2b: bb ca 00 00 00 mov$0xca,%ebx > db30: 48 89 efmov%rbp,%rdi > db33: 40 80 f6 80 xor$0x80,%sil > db37: 89 d8 mov%ebx,%eax > db39: 0f 05 syscall > db3b: 89 c3 mov%eax,%ebx > > db80 <__new_sem_wait_slow.constprop.0>: > db80: 41 54 push %r12 > db82: 48 b8 00 00 00 00 01movabs $0x1,%rax > db89: 00 00 00 > db8c: 55 push %rbp > db8d: 53 push %rbx > db8e: 48 89 fbmov%rdi,%rbx > db91: 48 83 ec 30 sub$0x30,%rsp > db95: f0 48 0f c1 07 lock xadd %rax,(%rdi) > db9a: 48 8d 35 5f ff ff fflea-0xa1(%rip),%rsi# db00 > <__sem_wait_cleanup> > dba1: 49 bc ff ff ff ff femovabs $0xfffe,%r12 > dba8: ff ff ff > dbab: 48 8d 6c 24 10 lea0x10(%rsp),%rbp > dbb0: 48 89 famov%rdi,%rdx > dbb3: 48 89 04 24 mov%rax,(%rsp) > dbb7: 48 89 efmov%rbp,%rdi > dbba: e8 b1 04 00 00 callq e070 <_pthread_cleanup_push> > dbbf: 48 8b 04 24 mov(%rsp),%rax > dbc3: 85 c0 test %eax,%eax > > > So os::is_first_C_frame returns earlier. To support walking pthread library, > I don't think it requires huge efforts, though. @kelthuzadx I do not agree with this enhancement request. I don't think it is the job of jcmd/jstack to do this. Those tools are concerned with application introspection not VM debugging. - PR: https://git.openjdk.java.net/jdk/pull/7833
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4]
On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional > commit since the last revision: > > removed incorrect translation of compiler configuration file LGTM. Thanks for the change. - Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation
On Wed, 16 Mar 2022 15:14:53 GMT, Daniel Fuchs wrote: >> Removing permission checks which, in the presence of a Security Manager, >> would check for a RuntimePermission "className.subclass". This was to >> prevent subclassing these classes, but is no longer necessary with strong >> encapsulation from modules. > > src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java > line 233: > >> 231: } >> 232: return null; >> 233: } > > I have verified in module-info.java that sun.management.spi is only > conditionally exported so I agree that the explicit permission check can now > be removed. thanks > src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java > line 35: > >> 33: >> 34: /** >> 35: * Instantiates a new AgentProvider. > > This class should probably be removed altogether. I see that you logged > [JDK-8283254](https://bugs.openjdk.java.net/browse/JDK-8283254) so this is > fine. Thanks Daniel - yes will get rid of this class soon, I'll keep these two actions in separate changes. 8-) - PR: https://git.openjdk.java.net/jdk/pull/7827
Re: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4]
> msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed incorrect translation of compiler configuration file - Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new: https://git.openjdk.java.net/jdk/pull/7765/files/d5c9b884..715a6ad7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7765=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7765=02-03 Stats: 2310 lines in 3 files changed: 0 ins; 2310 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765
Re: RFR: 8282241: Invalid generic signature for redefined classes [v2]
On Fri, 4 Mar 2022 17:12:51 GMT, Alex Menkov wrote: >> JDK-8238048 (fixed in jdk15) moved major_version, minor_version, >> generic_signature_index and source_file_name_index from InstanceKlass to >> ConstantPool. >> We still have some incorrect code in CP merge during class redefinition. >> >> rewrite_cp_refs(scratch_class) updates generic_signature_index and >> source_file_name_index in the scratch_cp, so we need to copy the attributes >> (merge_cp->copy_fields(scratch_cp())) after rewrite_cp_refs. >> >> In redefine_single_class we don't need to copy source_file_name_index >> because it's a CP property and we swap CPs. So this copying actually sets >> the value from old class. >> >> tested: >> - test/jdk/java/lang/instrument >> - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses >> - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses >> - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses > > Alex Menkov has updated the pull request incrementally with one additional > commit since the last revision: > > Reworked the test Alex, The fix looks good. Thank you for taking care about it! Thanks, Serguei - Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7676
Re: RFR: 8283092: JMX subclass permission check redundant with strong encapsulation
On Tue, 15 Mar 2022 20:22:16 GMT, Kevin Walls wrote: > Removing permission checks which, in the presence of a Security Manager, > would check for a RuntimePermission "className.subclass". This was to > prevent subclassing these classes, but is no longer necessary with strong > encapsulation from modules. Marked as reviewed by dfuchs (Reviewer). src/java.management/share/classes/sun/management/spi/PlatformMBeanProvider.java line 233: > 231: } > 232: return null; > 233: } I have verified in module-info.java that sun.management.spi is only conditionally exported so I agree that the explicit permission check can now be removed. src/jdk.management.agent/share/classes/jdk/internal/agent/spi/AgentProvider.java line 35: > 33: > 34: /** > 35: * Instantiates a new AgentProvider. This class should probably be removed altogether. I see that you logged [JDK-8283254](https://bugs.openjdk.java.net/browse/JDK-8283254) so this is fine. - PR: https://git.openjdk.java.net/jdk/pull/7827
Re: RFR: 8283147: Include NonJavaThread stacktrace during thread dump [v3]
On Wed, 16 Mar 2022 02:57:20 GMT, Yi Yang wrote:
>> When we use jcmd Thread.dump/jstack , we could dump all Java
>> thread stack trace, but unfortunately we are not able to print NonJavaThread
>> stack trace such as VMThread/GCWorker, etc. For these threads, we know
>> nothing about what are they doing/are they blocked in pthread condition from
>> jstack output. An alternative is to use pstack, it internally attaches
>> destination process and uses `thread apply all bt`, which introduces more
>> overhead and much more dangerous.
>>
>> == JStack Ouput(Currrent)
>>
>> ...
>> "ApplicationImpl pooled thread 441" #1478 prio=4 os_prio=31 cpu=11.71ms
>> elapsed=60.30s tid=0x7f8d32171000 nid=0x22f23 waiting on condition
>> [0x700010d5d000]
>>java.lang.Thread.State: TIMED_WAITING (parking)
>> at jdk.internal.misc.Unsafe.park(java.base@11.0.11/Native Method)
>> - parking to wait for <0x0007af851760> (a
>> java.util.concurrent.SynchronousQueue$TransferStack)
>> at
>> java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.11/LockSupport.java:234)
>> at
>> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(java.base@11.0.11/SynchronousQueue.java:462)
>> at
>> java.util.concurrent.SynchronousQueue$TransferStack.transfer(java.base@11.0.11/SynchronousQueue.java:361)
>> at
>> java.util.concurrent.SynchronousQueue.poll(java.base@11.0.11/SynchronousQueue.java:937)
>> at
>> java.util.concurrent.ThreadPoolExecutor.getTask(java.base@11.0.11/ThreadPoolExecutor.java:1053)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.11/ThreadPoolExecutor.java:1114)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.11/ThreadPoolExecutor.java:628)
>> at
>> java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(java.base@11.0.11/Executors.java:668)
>> at
>> java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(java.base@11.0.11/Executors.java:665)
>> at java.security.AccessController.doPrivileged(java.base@11.0.11/Native
>> Method)
>> at
>> java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(java.base@11.0.11/Executors.java:665)
>> at java.lang.Thread.run(java.base@11.0.11/Thread.java:829)
>>
>> "VM Thread" os_prio=31 cpu=31205.83ms elapsed=154131.15s
>> tid=0x7f8d49046000 nid=0x4703 runnable
>>
>> "GC Thread#0" os_prio=31 cpu=3811.96ms elapsed=154131.18s
>> tid=0x7f8d49809800 nid=0x3603 runnable
>>
>> "GC Thread#1" os_prio=31 cpu=3749.09ms elapsed=154130.24s
>> tid=0x7f8d4a9b3000 nid=0x6103 runnable
>>
>> "GC Thread#2" os_prio=31 cpu=3745.73ms elapsed=154129.74s
>> tid=0x7f8d48249000 nid=0x12f27 runnable
>>
>> "GC Thread#3" os_prio=31 cpu=3692.77ms elapsed=154129.74s
>> tid=0x7f8d48b93000 nid=0xe50b runnable
>>
>> "GC Thread#4" os_prio=31 cpu=3728.57ms elapsed=154129.74s
>> tid=0x7f8d47b0b000 nid=0xe603 runnable
>>
>> "GC Thread#5" os_prio=31 cpu=3726.08ms elapsed=154129.74s
>> tid=0x7f8d47afc800 nid=0xe803 runnable
>>
>> "GC Thread#6" os_prio=31 cpu=3660.35ms elapsed=154129.02s
>> tid=0x7f8d48de5800 nid=0x15d2f runnable
>>
>> "GC Thread#7" os_prio=31 cpu=3676.68ms elapsed=154129.02s
>> tid=0x7f8d48dc4800 nid=0x16103 runnable
>>
>> "GC Thread#8" os_prio=31 cpu=3676.15ms elapsed=154128.31s
>> tid=0x7f8d4849d800 nid=0x1f503 runnable
>>
>> "GC Thread#9" os_prio=31 cpu=3570.95ms elapsed=154128.31s
>> tid=0x7f8d494ab000 nid=0x1f303 runnable
>>
>> "CMS Main Thread" os_prio=31 cpu=6715.33ms elapsed=154131.18s
>> tid=0x7f8d4780f800 nid=0x4b03 runnable
>>
>> "CMS Thread#0" os_prio=31 cpu=2429.86ms elapsed=154131.18s
>> tid=0x7f8d4900e000 nid=0x3703 runnable
>>
>> "CMS Thread#1" os_prio=31 cpu=2422.35ms elapsed=154129.72s
>> tid=0x7f8d4d044000 nid=0x11a03 runnable
>>
>> "CMS Thread#2" os_prio=31 cpu=2418.81ms elapsed=154129.72s
>> tid=0x7f8d48b93800 nid=0xea03 runnable
>>
>> "VM Periodic Task Thread" os_prio=31 cpu=10658.80ms elapsed=154130.41s
>> tid=0x7f8d49035000 nid=0xa003 waiting on condition
>>
>> JNI global refs: 660, weak refs: 1217
>>
>>
>> Most of above information makes no sense for further debugging. I think we
>> can extend this functionality, e.g. add a new flag such as
>> DumpAllThreadStackTrace, to print non java thread stack trace:
>>
>> == JStack Ouput(Modified)
>>
>> 2022-03-16 10:46:55
>> Full thread dump OpenJDK 64-Bit Server VM
>> (19-internal-adhoc.qingfengyy.jdktip mixed mode, sharing):
>>
>> Threads class SMR info:
>> _java_thread_list=0x7f15040015f0, length=22, elements={
>> 0x7f159c0255b0, 0x7f159c1babc0, 0x7f159c1bc180,
>> 0x7f159c1c21d0,
>> 0x7f159c1c36a0, 0x7f159c1c4bb0, 0x7f159c1c6730,
>> 0x7f159c1c7db0,
>> 0x7f159c1c9330, 0x7f159c1fc300, 0x7f159c211a60,
>> 0x7f159c213b60,
>> 0x7f159c302960, 0x7f14cc0319d0, 0x7f14cc0375c0,
>>
