From serguei.spitsyn at oracle.com Fri Apr 1 00:15:56 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Mar 2016 17:15:56 -0700 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances In-Reply-To: <56FC5BE7.2080009@oracle.com> References: <56FBC2BE.3060806@oracle.com> <56FC5BE7.2080009@oracle.com> Message-ID: <56FDBDBC.40103@oracle.com> Andreas, I agree with Coleen, it is a good find and a good and safe fix. Thanks! Serguei On 3/30/16 16:06, Coleen Phillimore wrote: > > Andreas, > > Good find! This seems like a safe fix. It's unfortunate to have to > walk the deallocate list, but I think it's short enough and less work > in comparison to having to call free_C_heap_structures on all the > other classes in the dead class loader data. And deallocate_contents > removes the scratch_class from the CLD _klasses list so won't walk it > twice. > > This is really good. > > Coleen > > On 3/30/16 8:12 AM, Andreas Eriksson wrote: >> Hi, >> >> Please review this fix for 8135322: >> ConstantPool::release_C_heap_structures not run in some circumstances. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 >> Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 >> >> The way this occurs is: >> >> 1. A ConstantPool, /merge_cp/, without a corresponding InstanceKlass is >> created during class redefinition. >> 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is not >> cleaned up by ClassLoaderDataGraph::do_unloading because the holding >> ClassLoaderData is already dead. >> 3. ClassLoaderData::~ClassLoaderData is called, which usually runs >> InstanceKlass::release_C_heap_structures, which in turn will call >> ConstantPool::release_C_heap_structures. But since there is no >> corresponding InstanceKlass for /merge_cp/ it will never release its >> C heap structures. >> 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For >> JDK 9 the Monitor has been removed, but we will miss doing a call to >> ConstantPool::unreference_symbols, which is probably not good either. >> >> >> This change adds a call to free everything in the _deallocate_list >> first thing in ClassLoaderData::~ClassLoaderData. >> >> Note: >> Running deallocate_contents() on everything in the list might be >> doing unnecessary work: >> What we really would like to do is run release_C_heap_structures() on >> constant pools in the list that do not have a corresponding >> InstanceKlass. Not sure it's worth the effort to do the filtering, >> since I believe the _deallocate_list is usually not that long. >> >> Note 2: >> After fixing in JDK 9 I'll backport this to JDK 8, where it has a >> more immediately visible effect. >> >> Regards, >> Andreas >> > From calvin.cheung at oracle.com Fri Apr 1 04:41:52 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 31 Mar 2016 21:41:52 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> Message-ID: <56FDFC10.2000202@oracle.com> Hi Jiangli, I've updated the fix which should address all your comments. webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.02/ changes between v.02 and v.01: http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/ The trampoline code buffer is now put into the 'md' region which is made executable. I've file the following RFE to have a separate region for the code buffer: JDK-8153241: Add a read-write-executable shared region for runtime generated code thanks, Calvin On 3/17/16, 9:37 PM, Jiangli Zhou wrote: > Hi Calvin, > > The changes look good overall. Following are my comments and questions. > > - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp > - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp > - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp > - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp > - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp > - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp > - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp > Please place the new CDS-only code under #if INCLUDE_CDS. > > It would be a good idea to assert the address (current pc) is within > the generated trampoline entry buffer. > > - src/share/vm/interpreter/abstractInterpreter.cpp > It?s not necessary to put '#include for memory/metaspaceShared.hpp' > under #if INCLUDE_CDS. > > - src/share/vm/memory/metaspaceShared.cpp > I see you changed ?read_only? to false for ?mc? region. Is it > possible to place the trampoline code buffer in the ?md? region, so > the ?mc? region does not need to be writable? It?s good to keep > the ?mc? as read only so it would be easier to detect any ?accidental? > writes to the region due to future changes. The ?md? can be made > executable. > > - src/share/vm/oops/method.cpp > Method::unlink_method() is only called > from Method::remove_unshareable_info(), which happens at dump time > only. Why is ?if (!DumpSharedSpaces)? check needed in > Method::unlink_method()? > > - src/share/vm/oops/method.hpp > In set_interpreter_entry(), when _i2i_entry and > _from_interpreted_entry are not the same as ?entry? for shared method? > > - src/share/vm/runtime/sharedRuntime.cpp > Please add a comment for the change at line 2537 > 2537 if (!DumpSharedSpaces&& CodeCacheExtensions::skip_compiler_support()) { > - src/share/vm/oops/constMethod.hpp > > ConstMethod does not seem to be the right place for > ?_adapter_trampoline? since it?s set at runtime. > > Do you have estimate about the size increase with the generated > trampolines for the shared methods? > > Thanks, > Jiangli > >> On Mar 16, 2016, at 10:36 PM, Calvin Cheung > > wrote: >> >> Dean, Ioi, >> >> Thanks for the review and discussions. >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >> >> >> Changes in this webrev: >> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). >> Return if it is in the middle of a trampoline call. >> - moved the guarantee from metaspaceShared_sparc.cpp to the common >> metaspaceShared.cpp; >> - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE >> and related comment in metaspaceShared.hpp >> >> The last 2 changes are required due to the test failure with the >> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >> test. >> >> Testing: >> JPRT with testset hotspot >> jtreg tests under hotspot/runtime on all platforms >> >> thanks, >> Calvin >> >> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >> >> >> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>> >>> >>> On 2/22/16 12:50 PM, Dean Long wrote: >>>> Hi Ioi, comments inlined below. >>>> >>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>> Hi Dean, >>>>> >>>>> Thanks for raising this issue. >>>>> >>>>> My first impression is this probably shouldn't matter (or somehow >>>>> we can get away with this). >>>>> >>>>> Today, the CDS archive already contains executable code in the >>>>> "misc code" section. On Linux/x64, this is typically in the >>>>> address range 0x802400000-0x802409000. The code is used to >>>>> dynamically patch the C++ vtables of Metadata types that are >>>>> stored in the CDS archive. So even today, there's a chance that >>>>> the suspended PC lands in this section. >>>>> >>>> >>>> OK, so you're saying that the trampolines don't make things any >>>> worse :-) >>> >>> Well, theoretically the i2i and c2i entries would be executed more >>> frequently than the vtable patching code, so if there was a problem, >>> it could be aggravated. >>>> >>>>> The code is generated inside >>>>> MetaspaceShared::generate_vtable_methods and looks like this when >>>>> you run with -Xshare:on: >>>>> >>>>> (gdb) x/5i 0x802400000 >>>>> 0x802400000: mov $0x0,%eax >>>>> 0x802400005: jmpq 0x8024084d0 >>>>> 0x80240000a: mov $0x1,%eax >>>>> 0x80240000f: jmpq 0x8024084d0 >>>>> 0x802400014: mov $0x2,%eax >>>>> .... >>>>> (gdb) x/16i 0x8024084d0 >>>>> 0x8024084d0: push %rsi >>>>> 0x8024084d1: push %rdi >>>>> 0x8024084d2: mov %rax,%rdi >>>>> 0x8024084d5: shr $0x8,%rdi >>>>> 0x8024084d9: shl $0x3,%rdi >>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>> 0x8024084e7: add %rdi,%rsi >>>>> 0x8024084ea: mov (%rsi),%rsi >>>>> 0x8024084ed: pop %rdi >>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>> 0x8024084f1: and $0xff,%rax >>>>> 0x8024084f8: shl $0x3,%rax >>>>> 0x8024084fc: add %rsi,%rax >>>>> 0x8024084ff: pop %rsi >>>>> 0x802408500: mov (%rax),%rax >>>>> 0x802408503: jmpq *%rax >>>>> >>>>> In JDK9, the profiler takes a sample by first calling into >>>>> JavaThread::pd_get_top_frame_for_profiling: >>>>> >>>>> (gdb) where >>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, >>>>> thread=0x7ffff08ce000) >>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>>> ucontext=0x7ffec6287d00, isInJava=true) >>>>> #2 0x00007ffff69d70be in >>>>> JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, >>>>> fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>> isInJava=true) >>>>> >>>>> I tried manually setting frame::_pc to 0x802400000, and it would >>>>> cause frame::safe_for_sender() to return false, and thus would >>>>> prevent the profiler from doing any stack walking. >>>>> >>>> >>>> Was the reason safe_for_sender() failed something that we can rely >>>> on 100%? I looked at safe_for_sender, and it's not obvious why it >>>> would fail, unless the frame pointer was invalid, and I think that >>>> depends on the platform and flags like PreserveFramePointer. How >>>> about filing a separate bug to track this issue? >>>> >>> >>> OK, I fill a new bug >>> https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>> >>> Thanks >>> - Ioi >>> >>>> dl >>>> >>>>> Also, both the CDS vtable patching code and the i2i trampolines >>>>> are tail calls, so you will never find a PC in them except for the >>>>> top-most frame. This means the check in >>>>> JavaThread::pd_get_top_frame is enough. There's no need to do >>>>> additional checks after we have started stack walking. >>>>> >>>>> I think the chance of landing in the CDS vtable patching methods, >>>>> or in the trampolines, is pretty small, so that shouldn't bother >>>>> the sampling profiler too much. >>>>> >>>>> Anyway, as part of this bug, we should add a regression test with >>>>> the profiler enabled, and keep calling a method in the CDS archive >>>>> in a tight loop (and manually disable compilation of that method >>>>> using command-line options). The test should never crash, and if >>>>> possible, it should also check that we don't have too many >>>>> "unknown" samples. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>> >>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>> We have profiling code that will suspend a thread at random >>>>>> points and try to walk the stack. >>>>>> I think frame::sender() will get confused if you happen to catch >>>>>> a thread in the trampoline, >>>>>> and frame::_pc is in metadata and not the code cache. >>>>>> >>>>>> dl >>>>>> >>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>> >>>>>>> This optimization reduces the size of the RW region of the CDS >>>>>>> archive. It also reduces the amount of pages in the RW region >>>>>>> that are actually written into during runtime. >>>>>>> >>>>>>> The original prototype on the x86_64 platform was done by Ioi >>>>>>> (ioi.lam at oracle.com). >>>>>>> I helped porting it to other platforms. >>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who provided >>>>>>> the changes to the ppc platform. >>>>>>> >>>>>>> Testing: >>>>>>> JPRT with testset hotspot >>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>> built on the Zero platform >>>>>>> tested on the openjdk aarch64 platform >>>>>>> refworkload on various platform (please refer to bug report >>>>>>> for data) >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>>> >>>>> >>>> >>> > From ioi.lam at oracle.com Fri Apr 1 05:09:05 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 31 Mar 2016 22:09:05 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56FDFC10.2000202@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56FDFC10.2000202@oracle.com> Message-ID: <56FE0271.6060603@oracle.com> Hi Calvin, The new changes look good. I just have one comment: 36 #if INCLUDE_CDS 37 #include "memory/metaspaceShared.hpp" 38 #endif I think this is unnecessary and adds to the clutter. All other files that include this file do not have such an #if macro. E.g., universe.cpp and allocation.cpp. Thanks - Ioi On 3/31/16 9:41 PM, Calvin Cheung wrote: > Hi Jiangli, > > I've updated the fix which should address all your comments. > webrev: > http://cr.openjdk.java.net/~ccheung/8145221/webrev.02/ > changes between v.02 and v.01: > http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/ > > The trampoline code buffer is now put into the 'md' region which is > made executable. > I've file the following RFE to have a separate region for the code > buffer: > JDK-8153241: Add a read-write-executable shared region for runtime > generated code > > thanks, > Calvin > > On 3/17/16, 9:37 PM, Jiangli Zhou wrote: >> Hi Calvin, >> >> The changes look good overall. Following are my comments and questions. >> >> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >> Please place the new CDS-only code under #if INCLUDE_CDS. >> >> It would be a good idea to assert the address (current pc) is within >> the generated trampoline entry buffer. >> >> - src/share/vm/interpreter/abstractInterpreter.cpp >> It?s not necessary to put '#include for memory/metaspaceShared.hpp' >> under #if INCLUDE_CDS. >> >> - src/share/vm/memory/metaspaceShared.cpp >> I see you changed ?read_only? to false for ?mc? region. Is it >> possible to place the trampoline code buffer in the ?md? region, so >> the ?mc? region does not need to be writable? It?s good to keep the >> ?mc? as read only so it would be easier to detect any ?accidental? >> writes to the region due to future changes. The ?md? can be made >> executable. >> >> - src/share/vm/oops/method.cpp >> Method::unlink_method() is only called from >> Method::remove_unshareable_info(), which happens at dump time only. >> Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? >> >> - src/share/vm/oops/method.hpp >> In set_interpreter_entry(), when _i2i_entry and >> _from_interpreted_entry are not the same as ?entry? for shared method? >> >> - src/share/vm/runtime/sharedRuntime.cpp >> Please add a comment for the change at line 2537 >> 2537 if (!DumpSharedSpaces&& >> CodeCacheExtensions::skip_compiler_support()) { >> - src/share/vm/oops/constMethod.hpp >> >> ConstMethod does not seem to be the right place for >> ?_adapter_trampoline? since it?s set at runtime. >> >> Do you have estimate about the size increase with the generated >> trampolines for the shared methods? >> >> Thanks, >> Jiangli >> >>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung >>> > wrote: >>> >>> Dean, Ioi, >>> >>> Thanks for the review and discussions. >>> >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>> >>> >>> Changes in this webrev: >>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). >>> Return if it is in the middle of a trampoline call. >>> - moved the guarantee from metaspaceShared_sparc.cpp to the common >>> metaspaceShared.cpp; >>> - changed the MIN_SHARED_MISC_DATA_SIZE and >>> MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>> >>> The last 2 changes are required due to the test failure with the >>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>> test. >>> >>> Testing: >>> JPRT with testset hotspot >>> jtreg tests under hotspot/runtime on all platforms >>> >>> thanks, >>> Calvin >>> >>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>> >>> >>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>> >>>> >>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>> Hi Ioi, comments inlined below. >>>>> >>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>> Hi Dean, >>>>>> >>>>>> Thanks for raising this issue. >>>>>> >>>>>> My first impression is this probably shouldn't matter (or somehow >>>>>> we can get away with this). >>>>>> >>>>>> Today, the CDS archive already contains executable code in the >>>>>> "misc code" section. On Linux/x64, this is typically in the >>>>>> address range 0x802400000-0x802409000. The code is used to >>>>>> dynamically patch the C++ vtables of Metadata types that are >>>>>> stored in the CDS archive. So even today, there's a chance that >>>>>> the suspended PC lands in this section. >>>>>> >>>>> >>>>> OK, so you're saying that the trampolines don't make things any >>>>> worse :-) >>>> >>>> Well, theoretically the i2i and c2i entries would be executed more >>>> frequently than the vtable patching code, so if there was a >>>> problem, it could be aggravated. >>>>> >>>>>> The code is generated inside >>>>>> MetaspaceShared::generate_vtable_methods and looks like this when >>>>>> you run with -Xshare:on: >>>>>> >>>>>> (gdb) x/5i 0x802400000 >>>>>> 0x802400000: mov $0x0,%eax >>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>> 0x80240000a: mov $0x1,%eax >>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>> 0x802400014: mov $0x2,%eax >>>>>> .... >>>>>> (gdb) x/16i 0x8024084d0 >>>>>> 0x8024084d0: push %rsi >>>>>> 0x8024084d1: push %rdi >>>>>> 0x8024084d2: mov %rax,%rdi >>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>> 0x8024084e7: add %rdi,%rsi >>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>> 0x8024084ed: pop %rdi >>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>> 0x8024084f1: and $0xff,%rax >>>>>> 0x8024084f8: shl $0x3,%rax >>>>>> 0x8024084fc: add %rsi,%rax >>>>>> 0x8024084ff: pop %rsi >>>>>> 0x802408500: mov (%rax),%rax >>>>>> 0x802408503: jmpq *%rax >>>>>> >>>>>> In JDK9, the profiler takes a sample by first calling into >>>>>> JavaThread::pd_get_top_frame_for_profiling: >>>>>> >>>>>> (gdb) where >>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, >>>>>> thread=0x7ffff08ce000) >>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>>>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>>>> ucontext=0x7ffec6287d00, isInJava=true) >>>>>> #2 0x00007ffff69d70be in >>>>>> JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, >>>>>> fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>> isInJava=true) >>>>>> >>>>>> I tried manually setting frame::_pc to 0x802400000, and it would >>>>>> cause frame::safe_for_sender() to return false, and thus would >>>>>> prevent the profiler from doing any stack walking. >>>>>> >>>>> >>>>> Was the reason safe_for_sender() failed something that we can rely >>>>> on 100%? I looked at safe_for_sender, and it's not obvious why it >>>>> would fail, unless the frame pointer was invalid, and I think that >>>>> depends on the platform and flags like PreserveFramePointer. How >>>>> about filing a separate bug to track this issue? >>>>> >>>> >>>> OK, I fill a new bug >>>> https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> dl >>>>> >>>>>> Also, both the CDS vtable patching code and the i2i trampolines >>>>>> are tail calls, so you will never find a PC in them except for >>>>>> the top-most frame. This means the check in >>>>>> JavaThread::pd_get_top_frame is enough. There's no need to do >>>>>> additional checks after we have started stack walking. >>>>>> >>>>>> I think the chance of landing in the CDS vtable patching methods, >>>>>> or in the trampolines, is pretty small, so that shouldn't bother >>>>>> the sampling profiler too much. >>>>>> >>>>>> Anyway, as part of this bug, we should add a regression test with >>>>>> the profiler enabled, and keep calling a method in the CDS >>>>>> archive in a tight loop (and manually disable compilation of that >>>>>> method using command-line options). The test should never crash, >>>>>> and if possible, it should also check that we don't have too many >>>>>> "unknown" samples. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>> >>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>> We have profiling code that will suspend a thread at random >>>>>>> points and try to walk the stack. >>>>>>> I think frame::sender() will get confused if you happen to catch >>>>>>> a thread in the trampoline, >>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>> >>>>>>>> This optimization reduces the size of the RW region of the CDS >>>>>>>> archive. It also reduces the amount of pages in the RW region >>>>>>>> that are actually written into during runtime. >>>>>>>> >>>>>>>> The original prototype on the x86_64 platform was done by Ioi >>>>>>>> (ioi.lam at oracle.com). >>>>>>>> I helped porting it to other platforms. >>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who >>>>>>>> provided the changes to the ppc platform. >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT with testset hotspot >>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>> built on the Zero platform >>>>>>>> tested on the openjdk aarch64 platform >>>>>>>> refworkload on various platform (please refer to bug report >>>>>>>> for data) >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin >>>>>>> >>>>>> >>>>> >>>> >> From ioi.lam at oracle.com Fri Apr 1 05:43:19 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 31 Mar 2016 22:43:19 -0700 Subject: RFR 8150607 - Clean up CompactHashtable Message-ID: <56FE0A77.6010604@oracle.com> Please review http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ Bug: Clean up CompactHashtable https://bugs.openjdk.java.net/browse/JDK-8150607 Summary of fix: [1] Instead of reading/writing the table bit-by-bit, which is tedious and error prone, use SimpleCompactHashtable::serialize(), which is more structural. [2] Split up the _buckets and _entries into two separate arrays, so the dumping and walking code is easier to understand (see comments above SimpleCompactHashtable declaration) These 2 arrays are now allocated from the RO region (used to be in RW) [3] Renamed a few things COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE (having something called "compact" in CompactHashtable is confusing) The old names "dump_table" (actually dumping the buckets) and "dump_buckets" (actually dumping the entries) were conflicting with terminology used elsewhere. Now the terminology is unified: "buckets" = the main index, "entries" = the second level. lookup_entry -> decode_entry (it wasn't doing any lookup) [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be checked with assert. [5] Replaced all juint to u4 (suggested by Coleen) [6] templatize the iterator (see CompactHashtable::symbols_do -> SimpleCompactHashtable::iterate) [7] I also added a test case using Serviceability Agent -- due to the lack of a regression test, the walking of the compact hashtable in SA had been broken for a while before it was fixed in JDK-8151368, so having a test case would make the code more maintainable. Tests: Hotspot JTREG tests Thanks - Ioi From calvin.cheung at oracle.com Fri Apr 1 05:43:30 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 31 Mar 2016 22:43:30 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56FE0271.6060603@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56FDFC10.2000202@oracle.com> <56FE0271.6060603@oracle.com> Message-ID: <56FE0A82.2040907@oracle.com> Hi Ioi, On 3/31/16, 10:09 PM, Ioi Lam wrote: > Hi Calvin, > > The new changes look good. I just have one comment: > > 36 #if INCLUDE_CDS > 37 #include "memory/metaspaceShared.hpp" > 38 #endif Did you mean the above code in abstractInterpreter.cpp? I removed it in webrev.02: http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/src/share/vm/interpreter/abstractInterpreter.cpp.sdiff.html thanks, Calvin > > I think this is unnecessary and adds to the clutter. All other files > that include this file do not have such an #if macro. E.g., > universe.cpp and allocation.cpp. > > Thanks > - Ioi > > > On 3/31/16 9:41 PM, Calvin Cheung wrote: >> Hi Jiangli, >> >> I've updated the fix which should address all your comments. >> webrev: >> http://cr.openjdk.java.net/~ccheung/8145221/webrev.02/ >> changes between v.02 and v.01: >> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/ >> >> The trampoline code buffer is now put into the 'md' region which is >> made executable. >> I've file the following RFE to have a separate region for the code >> buffer: >> JDK-8153241: Add a read-write-executable shared region for runtime >> generated code >> >> thanks, >> Calvin >> >> On 3/17/16, 9:37 PM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>> The changes look good overall. Following are my comments and questions. >>> >>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>> Please place the new CDS-only code under #if INCLUDE_CDS. >>> >>> It would be a good idea to assert the address (current pc) is >>> within the generated trampoline entry buffer. >>> >>> - src/share/vm/interpreter/abstractInterpreter.cpp >>> It?s not necessary to put '#include for >>> memory/metaspaceShared.hpp' under #if INCLUDE_CDS. >>> >>> - src/share/vm/memory/metaspaceShared.cpp >>> I see you changed ?read_only? to false for ?mc? region. Is it >>> possible to place the trampoline code buffer in the ?md? region, so >>> the ?mc? region does not need to be writable? It?s good to keep the >>> ?mc? as read only so it would be easier to detect any ?accidental? >>> writes to the region due to future changes. The ?md? can be made >>> executable. >>> >>> - src/share/vm/oops/method.cpp >>> Method::unlink_method() is only called from >>> Method::remove_unshareable_info(), which happens at dump time only. >>> Why is ?if (!DumpSharedSpaces)? check needed in >>> Method::unlink_method()? >>> >>> - src/share/vm/oops/method.hpp >>> In set_interpreter_entry(), when _i2i_entry and >>> _from_interpreted_entry are not the same as ?entry? for shared method? >>> >>> - src/share/vm/runtime/sharedRuntime.cpp >>> Please add a comment for the change at line 2537 >>> 2537 if (!DumpSharedSpaces&& >>> CodeCacheExtensions::skip_compiler_support()) { >>> - src/share/vm/oops/constMethod.hpp >>> >>> ConstMethod does not seem to be the right place for >>> ?_adapter_trampoline? since it?s set at runtime. >>> >>> Do you have estimate about the size increase with the generated >>> trampolines for the shared methods? >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung >>>> > wrote: >>>> >>>> Dean, Ioi, >>>> >>>> Thanks for the review and discussions. >>>> >>>> Here's an updated webrev: >>>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>>> >>>> >>>> Changes in this webrev: >>>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). >>>> Return if it is in the middle of a trampoline call. >>>> - moved the guarantee from metaspaceShared_sparc.cpp to the common >>>> metaspaceShared.cpp; >>>> - changed the MIN_SHARED_MISC_DATA_SIZE and >>>> MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>>> >>>> The last 2 changes are required due to the test failure with the >>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>> test. >>>> >>>> Testing: >>>> JPRT with testset hotspot >>>> jtreg tests under hotspot/runtime on all platforms >>>> >>>> thanks, >>>> Calvin >>>> >>>> p.s. I corrected the bug id in the subject line from 8145521 to >>>> 8145221 >>>> >>>> >>>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>>> >>>>> >>>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>>> Hi Ioi, comments inlined below. >>>>>> >>>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>>> Hi Dean, >>>>>>> >>>>>>> Thanks for raising this issue. >>>>>>> >>>>>>> My first impression is this probably shouldn't matter (or >>>>>>> somehow we can get away with this). >>>>>>> >>>>>>> Today, the CDS archive already contains executable code in the >>>>>>> "misc code" section. On Linux/x64, this is typically in the >>>>>>> address range 0x802400000-0x802409000. The code is used to >>>>>>> dynamically patch the C++ vtables of Metadata types that are >>>>>>> stored in the CDS archive. So even today, there's a chance that >>>>>>> the suspended PC lands in this section. >>>>>>> >>>>>> >>>>>> OK, so you're saying that the trampolines don't make things any >>>>>> worse :-) >>>>> >>>>> Well, theoretically the i2i and c2i entries would be executed more >>>>> frequently than the vtable patching code, so if there was a >>>>> problem, it could be aggravated. >>>>>> >>>>>>> The code is generated inside >>>>>>> MetaspaceShared::generate_vtable_methods and looks like this >>>>>>> when you run with -Xshare:on: >>>>>>> >>>>>>> (gdb) x/5i 0x802400000 >>>>>>> 0x802400000: mov $0x0,%eax >>>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>>> 0x80240000a: mov $0x1,%eax >>>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>>> 0x802400014: mov $0x2,%eax >>>>>>> .... >>>>>>> (gdb) x/16i 0x8024084d0 >>>>>>> 0x8024084d0: push %rsi >>>>>>> 0x8024084d1: push %rdi >>>>>>> 0x8024084d2: mov %rax,%rdi >>>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>>> 0x8024084e7: add %rdi,%rsi >>>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>>> 0x8024084ed: pop %rdi >>>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>>> 0x8024084f1: and $0xff,%rax >>>>>>> 0x8024084f8: shl $0x3,%rax >>>>>>> 0x8024084fc: add %rsi,%rax >>>>>>> 0x8024084ff: pop %rsi >>>>>>> 0x802408500: mov (%rax),%rax >>>>>>> 0x802408503: jmpq *%rax >>>>>>> >>>>>>> In JDK9, the profiler takes a sample by first calling into >>>>>>> JavaThread::pd_get_top_frame_for_profiling: >>>>>>> >>>>>>> (gdb) where >>>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, >>>>>>> thread=0x7ffff08ce000) >>>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>>>>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>>>>> ucontext=0x7ffec6287d00, isInJava=true) >>>>>>> #2 0x00007ffff69d70be in >>>>>>> JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, >>>>>>> fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>>> isInJava=true) >>>>>>> >>>>>>> I tried manually setting frame::_pc to 0x802400000, and it would >>>>>>> cause frame::safe_for_sender() to return false, and thus would >>>>>>> prevent the profiler from doing any stack walking. >>>>>>> >>>>>> >>>>>> Was the reason safe_for_sender() failed something that we can >>>>>> rely on 100%? I looked at safe_for_sender, and it's not obvious >>>>>> why it would fail, unless the frame pointer was invalid, and I >>>>>> think that depends on the platform and flags like >>>>>> PreserveFramePointer. How about filing a separate bug to track >>>>>> this issue? >>>>>> >>>>> >>>>> OK, I fill a new bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>>> dl >>>>>> >>>>>>> Also, both the CDS vtable patching code and the i2i trampolines >>>>>>> are tail calls, so you will never find a PC in them except for >>>>>>> the top-most frame. This means the check in >>>>>>> JavaThread::pd_get_top_frame is enough. There's no need to do >>>>>>> additional checks after we have started stack walking. >>>>>>> >>>>>>> I think the chance of landing in the CDS vtable patching >>>>>>> methods, or in the trampolines, is pretty small, so that >>>>>>> shouldn't bother the sampling profiler too much. >>>>>>> >>>>>>> Anyway, as part of this bug, we should add a regression test >>>>>>> with the profiler enabled, and keep calling a method in the CDS >>>>>>> archive in a tight loop (and manually disable compilation of >>>>>>> that method using command-line options). The test should never >>>>>>> crash, and if possible, it should also check that we don't have >>>>>>> too many "unknown" samples. >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>> >>>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>>> We have profiling code that will suspend a thread at random >>>>>>>> points and try to walk the stack. >>>>>>>> I think frame::sender() will get confused if you happen to >>>>>>>> catch a thread in the trampoline, >>>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>>> >>>>>>>>> This optimization reduces the size of the RW region of the CDS >>>>>>>>> archive. It also reduces the amount of pages in the RW region >>>>>>>>> that are actually written into during runtime. >>>>>>>>> >>>>>>>>> The original prototype on the x86_64 platform was done by Ioi >>>>>>>>> (ioi.lam at oracle.com). >>>>>>>>> I helped porting it to other platforms. >>>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who >>>>>>>>> provided the changes to the ppc platform. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> JPRT with testset hotspot >>>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>>>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>>> built on the Zero platform >>>>>>>>> tested on the openjdk aarch64 platform >>>>>>>>> refworkload on various platform (please refer to bug report >>>>>>>>> for data) >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Calvin >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From ioi.lam at oracle.com Fri Apr 1 05:45:41 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 31 Mar 2016 22:45:41 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56FE0A82.2040907@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56FDFC10.2000202@oracle.com> <56FE0271.6060603@oracle.com> <56FE0A82.2040907@oracle.com> Message-ID: <56FE0B05.7020202@oracle.com> Oops, sorry, I missed that. Thanks for clarifying. - Ioi On 3/31/16 10:43 PM, Calvin Cheung wrote: > Hi Ioi, > > On 3/31/16, 10:09 PM, Ioi Lam wrote: >> Hi Calvin, >> >> The new changes look good. I just have one comment: >> >> 36 #if INCLUDE_CDS >> 37 #include "memory/metaspaceShared.hpp" >> 38 #endif > Did you mean the above code in abstractInterpreter.cpp? > I removed it in webrev.02: > http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/src/share/vm/interpreter/abstractInterpreter.cpp.sdiff.html > > > thanks, > Calvin > >> >> I think this is unnecessary and adds to the clutter. All other files >> that include this file do not have such an #if macro. E.g., >> universe.cpp and allocation.cpp. >> >> Thanks >> - Ioi >> >> >> On 3/31/16 9:41 PM, Calvin Cheung wrote: >>> Hi Jiangli, >>> >>> I've updated the fix which should address all your comments. >>> webrev: >>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.02/ >>> changes between v.02 and v.01: >>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/ >>> >>> The trampoline code buffer is now put into the 'md' region which is >>> made executable. >>> I've file the following RFE to have a separate region for the code >>> buffer: >>> JDK-8153241: Add a read-write-executable shared region for runtime >>> generated code >>> >>> thanks, >>> Calvin >>> >>> On 3/17/16, 9:37 PM, Jiangli Zhou wrote: >>>> Hi Calvin, >>>> >>>> The changes look good overall. Following are my comments and >>>> questions. >>>> >>>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>>> Please place the new CDS-only code under #if INCLUDE_CDS. >>>> >>>> It would be a good idea to assert the address (current pc) is >>>> within the generated trampoline entry buffer. >>>> >>>> - src/share/vm/interpreter/abstractInterpreter.cpp >>>> It?s not necessary to put '#include for >>>> memory/metaspaceShared.hpp' under #if INCLUDE_CDS. >>>> >>>> - src/share/vm/memory/metaspaceShared.cpp >>>> I see you changed ?read_only? to false for ?mc? region. Is it >>>> possible to place the trampoline code buffer in the ?md? region, so >>>> the ?mc? region does not need to be writable? It?s good to keep the >>>> ?mc? as read only so it would be easier to detect any ?accidental? >>>> writes to the region due to future changes. The ?md? can be made >>>> executable. >>>> >>>> - src/share/vm/oops/method.cpp >>>> Method::unlink_method() is only called from >>>> Method::remove_unshareable_info(), which happens at dump time only. >>>> Why is ?if (!DumpSharedSpaces)? check needed in >>>> Method::unlink_method()? >>>> >>>> - src/share/vm/oops/method.hpp >>>> In set_interpreter_entry(), when _i2i_entry and >>>> _from_interpreted_entry are not the same as ?entry? for shared method? >>>> >>>> - src/share/vm/runtime/sharedRuntime.cpp >>>> Please add a comment for the change at line 2537 >>>> 2537 if (!DumpSharedSpaces&& >>>> CodeCacheExtensions::skip_compiler_support()) { >>>> - src/share/vm/oops/constMethod.hpp >>>> >>>> ConstMethod does not seem to be the right place for >>>> ?_adapter_trampoline? since it?s set at runtime. >>>> >>>> Do you have estimate about the size increase with the generated >>>> trampolines for the shared methods? >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung >>>>> > wrote: >>>>> >>>>> Dean, Ioi, >>>>> >>>>> Thanks for the review and discussions. >>>>> >>>>> Here's an updated webrev: >>>>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>>>> >>>>> >>>>> Changes in this webrev: >>>>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). >>>>> Return if it is in the middle of a trampoline call. >>>>> - moved the guarantee from metaspaceShared_sparc.cpp to the common >>>>> metaspaceShared.cpp; >>>>> - changed the MIN_SHARED_MISC_DATA_SIZE and >>>>> MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>>>> >>>>> The last 2 changes are required due to the test failure with the >>>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>> test. >>>>> >>>>> Testing: >>>>> JPRT with testset hotspot >>>>> jtreg tests under hotspot/runtime on all platforms >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>> p.s. I corrected the bug id in the subject line from 8145521 to >>>>> 8145221 >>>>> >>>>> >>>>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>>>> >>>>>> >>>>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>>>> Hi Ioi, comments inlined below. >>>>>>> >>>>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>>>> Hi Dean, >>>>>>>> >>>>>>>> Thanks for raising this issue. >>>>>>>> >>>>>>>> My first impression is this probably shouldn't matter (or >>>>>>>> somehow we can get away with this). >>>>>>>> >>>>>>>> Today, the CDS archive already contains executable code in the >>>>>>>> "misc code" section. On Linux/x64, this is typically in the >>>>>>>> address range 0x802400000-0x802409000. The code is used to >>>>>>>> dynamically patch the C++ vtables of Metadata types that are >>>>>>>> stored in the CDS archive. So even today, there's a chance that >>>>>>>> the suspended PC lands in this section. >>>>>>>> >>>>>>> >>>>>>> OK, so you're saying that the trampolines don't make things any >>>>>>> worse :-) >>>>>> >>>>>> Well, theoretically the i2i and c2i entries would be executed >>>>>> more frequently than the vtable patching code, so if there was a >>>>>> problem, it could be aggravated. >>>>>>> >>>>>>>> The code is generated inside >>>>>>>> MetaspaceShared::generate_vtable_methods and looks like this >>>>>>>> when you run with -Xshare:on: >>>>>>>> >>>>>>>> (gdb) x/5i 0x802400000 >>>>>>>> 0x802400000: mov $0x0,%eax >>>>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>>>> 0x80240000a: mov $0x1,%eax >>>>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>>>> 0x802400014: mov $0x2,%eax >>>>>>>> .... >>>>>>>> (gdb) x/16i 0x8024084d0 >>>>>>>> 0x8024084d0: push %rsi >>>>>>>> 0x8024084d1: push %rdi >>>>>>>> 0x8024084d2: mov %rax,%rdi >>>>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>>>> 0x8024084e7: add %rdi,%rsi >>>>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>>>> 0x8024084ed: pop %rdi >>>>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>>>> 0x8024084f1: and $0xff,%rax >>>>>>>> 0x8024084f8: shl $0x3,%rax >>>>>>>> 0x8024084fc: add %rsi,%rax >>>>>>>> 0x8024084ff: pop %rsi >>>>>>>> 0x802408500: mov (%rax),%rax >>>>>>>> 0x802408503: jmpq *%rax >>>>>>>> >>>>>>>> In JDK9, the profiler takes a sample by first calling into >>>>>>>> JavaThread::pd_get_top_frame_for_profiling: >>>>>>>> >>>>>>>> (gdb) where >>>>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, >>>>>>>> thread=0x7ffff08ce000) >>>>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>>>>>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>>>>>> ucontext=0x7ffec6287d00, isInJava=true) >>>>>>>> #2 0x00007ffff69d70be in >>>>>>>> JavaThread::pd_get_top_frame_for_profiling >>>>>>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>>>>>> ucontext=0x7ffec6287d00, >>>>>>>> isInJava=true) >>>>>>>> >>>>>>>> I tried manually setting frame::_pc to 0x802400000, and it >>>>>>>> would cause frame::safe_for_sender() to return false, and thus >>>>>>>> would prevent the profiler from doing any stack walking. >>>>>>>> >>>>>>> >>>>>>> Was the reason safe_for_sender() failed something that we can >>>>>>> rely on 100%? I looked at safe_for_sender, and it's not obvious >>>>>>> why it would fail, unless the frame pointer was invalid, and I >>>>>>> think that depends on the platform and flags like >>>>>>> PreserveFramePointer. How about filing a separate bug to track >>>>>>> this issue? >>>>>>> >>>>>> >>>>>> OK, I fill a new bug >>>>>> https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>>> dl >>>>>>> >>>>>>>> Also, both the CDS vtable patching code and the i2i trampolines >>>>>>>> are tail calls, so you will never find a PC in them except for >>>>>>>> the top-most frame. This means the check in >>>>>>>> JavaThread::pd_get_top_frame is enough. There's no need to do >>>>>>>> additional checks after we have started stack walking. >>>>>>>> >>>>>>>> I think the chance of landing in the CDS vtable patching >>>>>>>> methods, or in the trampolines, is pretty small, so that >>>>>>>> shouldn't bother the sampling profiler too much. >>>>>>>> >>>>>>>> Anyway, as part of this bug, we should add a regression test >>>>>>>> with the profiler enabled, and keep calling a method in the CDS >>>>>>>> archive in a tight loop (and manually disable compilation of >>>>>>>> that method using command-line options). The test should never >>>>>>>> crash, and if possible, it should also check that we don't have >>>>>>>> too many "unknown" samples. >>>>>>>> >>>>>>>> Thanks >>>>>>>> - Ioi >>>>>>>> >>>>>>>> >>>>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>>>> We have profiling code that will suspend a thread at random >>>>>>>>> points and try to walk the stack. >>>>>>>>> I think frame::sender() will get confused if you happen to >>>>>>>>> catch a thread in the trampoline, >>>>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>>>> >>>>>>>>> dl >>>>>>>>> >>>>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>>>> >>>>>>>>>> This optimization reduces the size of the RW region of the >>>>>>>>>> CDS archive. It also reduces the amount of pages in the RW >>>>>>>>>> region that are actually written into during runtime. >>>>>>>>>> >>>>>>>>>> The original prototype on the x86_64 platform was done by Ioi >>>>>>>>>> (ioi.lam at oracle.com). >>>>>>>>>> I helped porting it to other platforms. >>>>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who >>>>>>>>>> provided the changes to the ppc platform. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> JPRT with testset hotspot >>>>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>>>>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>>>> built on the Zero platform >>>>>>>>>> tested on the openjdk aarch64 platform >>>>>>>>>> refworkload on various platform (please refer to bug >>>>>>>>>> report for data) >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Calvin >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From cheleswer.sahu at oracle.com Fri Apr 1 06:10:17 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 31 Mar 2016 23:10:17 -0700 (PDT) Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters In-Reply-To: <56FD7B30.8020105@oracle.com> References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default> <56EBC647.6020704@oracle.com> <0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default> <56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com> <56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com> <56F021EC.4010105@oracle.com> <56F06670.5030802@oracle.com> <56F4489D.10107@oracle.com> <56FD727B.1000209@oracle.com> <56FD7B30.8020105@oracle.com> Message-ID: Thanks Dmitry, Kevin for review. Regards, Cheleswer -----Original Message----- From: Kevin Walls Sent: Friday, April 01, 2016 1:02 AM To: Dmitry Samersoff; Cheleswer Sahu; Mattis Castegren; David Holmes; Daniel Daugherty; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters Yes, looks good. 8-) On 31/03/2016 19:54, Dmitry Samersoff wrote: > Cheleswer, > > Looks good for me! (R) > > -Dmitry > > > On 2016-03-31 12:46, Cheleswer Sahu wrote: >> Hi , >> >> I would like to go with the "print_raw()" option as this can print >> any length of thread name. I have modified the code and written a >> test case also for this bug. Please review the code changes from the >> below link >> >> http://cr.openjdk.java.net/~csahu/8151442/webrev.01/ >> >> Regards, >> Cheleswer >> >> -----Original Message----- >> From: Mattis Castegren >> Sent: Wednesday, March 30, 2016 10:42 PM >> To: Kevin Walls; David Holmes; Daniel Daugherty; Dmitry Samersoff; >> Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; >> serviceability-dev at openjdk.java.net >> Cc: Mattis Castegren >> Subject: RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation >> marks properly with threads' name greater than 1996 characters >> >> Hi >> >> It seems there are two approaches here, either we truncate long thread names, or we make sure to print the full thread name. >> >> I agree with Dmitry and Kirk that if the API allows these long names, the tooling should do the right thing (even though one has to wonder what these long names are). >> >> I suggest we move ahead with the print_raw approach. >> >> If we believe there should be a limit in the Thread name lenghts, I suggest we file a new bug for that. >> >> Kind Regards >> /Mattis >> >> -----Original Message----- >> From: Kevin Walls >> Sent: den 24 mars 2016 21:06 >> To: David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; >> hotspot-runtime-dev at openjdk.java.net; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation >> marks properly with threads' name greater than 1996 characters >> >> >> Hi >> >> I didn't think of %.XXXXs when Cheleswer and I discussed this briefly. >> I'd like to have suggested that, with the idea that the 2k long thread name is extreme, and it's so important that we preserve the format of the output, and keep that closing quote, even if we lost some of the thread name. We currently and probably always have truncated such names, the problem that triggered this was mainly that the format was broken. >> >> As there are several places we pass the name to the stream and could hit the length limit, should we have a THREAD_NAME_FORMAT defined for such use instead of using %s though the actual length can't be 1996, it's BUFLEN minus whatever else we expect to be printed in the same print call. We might guess as low as 1024? >> >> (Retaining one st->print() also minimises any risk of concurrent >> prints jumbling up the output.) >> >> Thanks >> Kevin >> >> >> On 21/03/2016 21:24, David Holmes wrote: >>> On 22/03/2016 2:31 AM, Daniel D. Daugherty wrote: >>>> On 3/21/16 2:39 AM, Dmitry Samersoff wrote: >>>>> David, >>>>> >>>>>> I still see %.Ns as the simplest solution - but whatever. >>>>> It spreads artificial limitation of thread name length across >>>>> hotspot sources. >>>>> >>>>> Brief grepping[1] shows couple of other places with the same >>>>> problem and if some days we decide to change default O_BUFLEN, we >>>>> have to not forget to change .N value in couple of places as well. >>>> There should be a way to pass the precision value as a parameter >>>> instead of hardcoding it in the format string. Something like: >>>> >>>> sprintf("%.*s", precision_value, string); >>> Yes the length limit can be passed as a variable. But I think Dmitry >>> just wants to allow for unlimited lengths. Not sure how to achieve >>> that at the lowest level though as we need to avoid complex >>> allocations etc in these print routines. >>> >>> David >>> >>> >>>> Dan >>>> >>>>> 1. >>>>> ./share/vm/prims/jni.cpp >>>>> 673: "in thread \"%s\" ", thread->get_thread_name()); >>>>> >>>>> ./share/vm/runtime/thread.cpp >>>>> 1766: get_thread_profiler()->print(get_thread_name()); >>>>> 1974: get_thread_profiler()->print(get_thread_name()); >>>>> 2896: st->print("\"%s\" ", get_thread_name()); >>>>> 2926: st->print("%s", get_thread_name_string(buf, buflen)); >>>>> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf, >>>>> buflen)); >>>>> >>>>> >>>>> ./share/vm/services/threadService.cpp >>>>> 882: ... st->print_cr("\"%s\":", >>>>> currentThread->get_thread_name()); >>>>> 919: ..."%s \"%s\"", owner_desc, >>>>> currentThread->get_thread_name()); >>>>> 932: ... st->print_cr("\"%s\":", >>>>> currentThread->get_thread_name()); >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2016-03-19 00:37, David Holmes wrote: >>>>>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote: >>>>>>> David, >>>>>>> >>>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just >>>>>>>> add the desired precision value to the %s than to split into >>>>>>>> two print statements. Or bite the bullet now and make the >>>>>>>> length immaterial by breaking the name into chunks. It's as >>>>>>>> easy to fix as to write the RFE :) >>>>>>> For this particular case the simplest solution is to use print_raw: >>>>>>> >>>>>>> print_raw("\""\"); print_raw(get_thread_name()); >>>>>>> print_raw("\""\"); >>>>>> I still see %.Ns as the simplest solution - but whatever. >>>>>> >>>>>>> But as soon as print() finally ends up with: >>>>>>> >>>>>>> const int written = vsnprintf(buffer, buflen, format, ap); ... >>>>>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output >>>>>>> truncated");) >>>>>>> >>>>>>> Complete fix should be something like: >>>>>>> >>>>>>> int desired_size = vsnprintf(NULL, 0, format, ap); if >>>>>>> (desired_size > O_BUFLEN) { >>>>>>> malloc >>>>>>> .... >>>>>>> } >>>>>>> >>>>>>> but it has performance penalty, so we should use some tricks to >>>>>>> cover most common %s/%d/%p cases. >>>>>> So you want to remove the internal limitation instead of have the >>>>>> clients deal with it? Not sure it is worth the effort - IIRC that >>>>>> code can be used at sensitive times hence the simple approach to >>>>>> buffer management. >>>>>> >>>>>> David >>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2016-03-18 15:51, David Holmes wrote: >>>>>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: David Holmes >>>>>>>>> Sent: Friday, March 18, 2016 2:42 PM >>>>>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close >>>>>>>>> quotation marks properly with threads' name greater than 1996 >>>>>>>>> characters >>>>>>>>> >>>>>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review the code changes for >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442. >>>>>>>>>> >>>>>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/ >>>>>>>>>> >>>>>>>>>> Bug Brief: >>>>>>>>>> >>>>>>>>>> In jstack thread dumps , thread name greater than 1996 >>>>>>>>>> characters doesn't close quotation marks properly. >>>>>>>>> Anyone giving a thread a name that long deserves to get a core >>>>>>>>> dump! >>>>>>>>> ;-) >>>>>>>>> >>>>>>>>>> Problem Identified: >>>>>>>>>> >>>>>>>>>> Jstack is using below code to print thread name >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>> >>>>>>>>>> void JavaThread::print_on(outputStream *st) const { >>>>>>>>>> >>>>>>>>>> st->print("\"%s\" ", get_thread_name()); >>>>>>>>>> >>>>>>>>>> Here "st->print()" internally uses max buffer length as >>>>>>>>>> O_BUFLEN (2000). >>>>>>>>>> >>>>>>>>>> void >>>>>>>>>> outputStream::do_vsnprintf_and_write_with_automatic_buffer(co >>>>>>>>>> ns >>>>>>>>>> t >>>>>>>>>> char* format, va_list ap, bool add_cr) { >>>>>>>>>> >>>>>>>>>> char buffer[O_BUFLEN]; >>>>>>>>>> >>>>>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls >>>>>>>>>> "vsnprintf()" which truncates the anything greater >>>>>>>>>> than the max size(2000). In this case thread's name(> 1996) >>>>>>>>>> along with quotation marks (2) >>>>>>>>>> >>>>>>>>>> plus one terminating character exceeds the max buffer size >>>>>>>>>> (2000), therefore the closing quotation marks gets truncated. >>>>>>>>>> >>>>>>>>>> Solution: >>>>>>>>>> >>>>>>>>>> Split the "st->print("\"%s\" ", get_thread_name())" in two >>>>>>>>>> statements >>>>>>>>>> >>>>>>>>>> 1.st->print("\"%s", get_thread_name()); >>>>>>>>>> >>>>>>>>>> 2.st->print("\" "); >>>>>>>>>> >>>>>>>>>> This will ensure presence of closing quotation mark always. >>>>>>>>> Can't we just limit the number of characters read by %s? >>>>>>>>> >>>>>>>>> Yes we can do it, but just one thing which I think of is, if >>>>>>>>> the truncation of output inside output stream issue get >>>>>>>>> resolves as Dmritry suggested or O_BUFFLEN size gets increased >>>>>>>>> in any future fix then we have to again make changes in this >>>>>>>>> code, as limiting the no. >>>>>>>>> of character read by %s will give truncated output . In such >>>>>>>>> case present fix will have no effect. >>>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just >>>>>>>> add the desired precision value to the %s than to split into >>>>>>>> two print statements. Or bite the bullet now and make the >>>>>>>> length immaterial by breaking the name into chunks. It's as >>>>>>>> easy to fix as to write the RFE :) >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Cheleswer >>>>>>>>>> > From marcus.larsson at oracle.com Fri Apr 1 08:45:08 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 1 Apr 2016 10:45:08 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <56FD679C.8070803@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> Message-ID: <56FE3514.5050104@oracle.com> Hi, On 03/31/2016 08:08 PM, Max Ockner wrote: > (Replies in line) > > On 3/30/2016 9:31 AM, Thomas St?fe wrote: >> Hi Max, >> >> Disclaimer: not a (R)eviewer. >> >> Do we really need a list of all tags and all decorators? >> > Just going by what we currently put in the hs_err file, I think this > may be the first "Do we really need" we've ever asked for this type of > change. > > All joking aside, I think it is a good idea to direct users toward > proper UL usage whenever we have a chance. > >> Also: I assume what you print is the Log state as it is at the time >> the hs-err file is printed. If logging was enabled/changed during >> lifetime of the VM, e.g. with jcmd, would it be possible to see that? >> At least a warning if logging was not enabled from the start on. >> > Would it be possible? Yes, but I think this would require a framework > change. It does not look like any marks are made when the > LogConfiguration changes during runtime, and we would need to record > that in order to know what to print when we dump into hs_err. Yes, this would required the framework to keep some sort of log of configuration changes. Is there value in knowing that the log configuration changed since startup? > > Thanks, > Max >> Kind Regards, Thomas >> >> >> >> >> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner > > wrote: >> >> Hello, >> Please review another Unified Logging change. They are almost >> done, and we are serious this time. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >> >> LogConfiguration::describe() takes the ConfigurationLock, which might be problematic for the error handler. I suppose the error handler could potentially deadlock if its thread already holds the lock. Unsure how to resolve this, because skipping to take the lock means that we might crash due to another thread changing the configuration as we read it. Thanks, Marcus >> >> The logging configuration is now printed in each hs_err file. The >> output is the same as you would see from -Xlog:logging=trace and >> it is obtained from LogConfiguration::describe(). >> >> Below is a sample of the hs_err contents. The Logging info is >> printed after VM Arguments and Whitebox, and before Environment >> Variables. >> >> VM Arguments: >> java_command: Kaboom >> java_class_path (initial): . >> Launcher Type: SUN_STANDARD >> >> Logging: >> Available log levels: off, trace, debug, info, warning, error >> Available log decorators: time (t), uptime (u), timemillis (tm), >> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname >> (hn), pid (p), tid (ti), level (l), tags (tg) >> Available log tags: alloc, age, barrier, biasedlocking, bot, >> census, classhisto, classresolve, classinit, classload, >> classloaderdata, classunload, classpath, compaction, cpu, cset, >> defaultmethods, ergo, exceptions, exit, freelist, gc, heap, >> humongous, ihop, itables, jni, liveness, logging, marking, >> metaspace, modules, monitorinflation, os, phases, plab, >> promotion, preorder, protectiondomain, ref, refine, region, >> remset, safepoint, safepointcleanup, scavenge, scrub, stacktrace, >> start, startuptime, state, stats, stringdedup, stringtable, >> survivor, sweep, task, thread, tlab, time, verboseverification, >> verify, vmoperation, vtables >> Log output configuration: >> #0: stdout all=off uptime,level,tags, >> #1: stderr all=warning uptime,level,tags, >> >> Environment Variables: >> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >> SHELL=/bin/bash >> OS=Linux >> >> > From david.simms at oracle.com Fri Apr 1 08:48:35 2016 From: david.simms at oracle.com (David Simms) Date: Fri, 1 Apr 2016 10:48:35 +0200 Subject: RFR (XXS): 8149442 : MonitorInUseLists should be on by default, deflate idle monitors taking too long Message-ID: <56FE35E3.8070001@oracle.com> Greetings, Bug: https://bugs.openjdk.java.net/browse/JDK-8149442 Webrev: http://cr.openjdk.java.net/~dsimms/8149442/ Safe-point's "deflate_idle_monitors" (clean up task during Safepoint::begin()), constantly scans all monitors, the entire population. Setting MonitorInUseLists to true by default would seem prudent, as the it reduces the scan to "InUse" thread lists. Reduction in "deflate idle monitor" execution time of up to a magnitude. There are certain applications (notably SPECjbb2013 use of ForkJoin) whose Java lock monitor total populations are quite high, but the actual number of in use monitors is low. Why these total populations grow so large, further work to reduce "deflate idle monitor" operations, is beyond the scope of this bug (see JDK-7021979 & JDK-8153224). Testing: no regressions spotted on the following benchmarks: * SpecJbb2005 * SpecJbb2008 * SpecJbb2013 * Volano Cheers / David Simms From cheleswer.sahu at oracle.com Fri Apr 1 12:30:58 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Fri, 1 Apr 2016 05:30:58 -0700 (PDT) Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" Message-ID: <7b9114bd-14d7-4a2f-8b5f-46fec1c90428@default> Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8054326. Webrev Link: http://cr.openjdk.java.net/~csahu/8054326/ Bug Brief: In output of remset statistics "Max" is printing as 0k, which is confusing for user. Problem Identified : "Max" value is rounded to KB, which result in 0k, if the value is less than 1024B. Solution Proposed: If the value for "Max" is less than 1 KB (1024 B), print the value in bytes (i.e. 1023B.) else print the value in KB. Regards, Cheleswer From andreas.eriksson at oracle.com Fri Apr 1 16:22:38 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Fri, 1 Apr 2016 18:22:38 +0200 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances In-Reply-To: <56FDBDBC.40103@oracle.com> References: <56FBC2BE.3060806@oracle.com> <56FC5BE7.2080009@oracle.com> <56FDBDBC.40103@oracle.com> Message-ID: <56FEA04E.4060002@oracle.com> Hi, When running some additional testing I had a test crash. Looks like sometimes data we need to run a full deallocate_contents call when we are in ~ClassLoaderData is already freed (seems to depend on what GC we are running, and what we have in the _deallocate_list). Doing the free_deallocate_list call in ClassLoaderDataGraph::do_unloading instead will most likely work, since it's run at an earlier point in the GC. Or I could do what I mentioned in the initial email, only run release_C_heap_structures() on constant pools in the list that do not have a corresponding InstanceKlass. I'm leaning towards, doing the free_deallocate_list call in ClassLoaderDataGraph::do_unloading, when we detect that the ClassLoaderData is dead. I'll send out a new review once I've had some time to test that fix. Thanks, Andreas On 2016-04-01 02:15, serguei.spitsyn at oracle.com wrote: > Andreas, > > I agree with Coleen, it is a good find and a good and safe fix. > > Thanks! > Serguei > > > On 3/30/16 16:06, Coleen Phillimore wrote: >> >> Andreas, >> >> Good find! This seems like a safe fix. It's unfortunate to have to >> walk the deallocate list, but I think it's short enough and less work >> in comparison to having to call free_C_heap_structures on all the >> other classes in the dead class loader data. And >> deallocate_contents removes the scratch_class from the CLD _klasses >> list so won't walk it twice. >> >> This is really good. >> >> Coleen >> >> On 3/30/16 8:12 AM, Andreas Eriksson wrote: >>> Hi, >>> >>> Please review this fix for 8135322: >>> ConstantPool::release_C_heap_structures not run in some circumstances. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 >>> Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 >>> >>> The way this occurs is: >>> >>> 1. A ConstantPool, /merge_cp/, without a corresponding InstanceKlass is >>> created during class redefinition. >>> 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is not >>> cleaned up by ClassLoaderDataGraph::do_unloading because the holding >>> ClassLoaderData is already dead. >>> 3. ClassLoaderData::~ClassLoaderData is called, which usually runs >>> InstanceKlass::release_C_heap_structures, which in turn will call >>> ConstantPool::release_C_heap_structures. But since there is no >>> corresponding InstanceKlass for /merge_cp/ it will never release its >>> C heap structures. >>> 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For >>> JDK 9 the Monitor has been removed, but we will miss doing a call to >>> ConstantPool::unreference_symbols, which is probably not good >>> either. >>> >>> >>> This change adds a call to free everything in the _deallocate_list >>> first thing in ClassLoaderData::~ClassLoaderData. >>> >>> Note: >>> Running deallocate_contents() on everything in the list might be >>> doing unnecessary work: >>> What we really would like to do is run release_C_heap_structures() >>> on constant pools in the list that do not have a corresponding >>> InstanceKlass. Not sure it's worth the effort to do the filtering, >>> since I believe the _deallocate_list is usually not that long. >>> >>> Note 2: >>> After fixing in JDK 9 I'll backport this to JDK 8, where it has a >>> more immediately visible effect. >>> >>> Regards, >>> Andreas >>> >> > From igor.veresov at oracle.com Fri Apr 1 18:28:35 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 1 Apr 2016 11:28:35 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime Message-ID: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ Thanks, igor From karen.kinnear at oracle.com Fri Apr 1 21:23:32 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 1 Apr 2016 17:23:32 -0400 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: <56FC64C0.9020003@oracle.com> References: <56F1ADEC.2050508@oracle.com> <56FC64C0.9020003@oracle.com> Message-ID: <8A037A40-34DD-4898-85B3-65978B6DEEB9@oracle.com> Dan, Impressive debugging and analysis! Thank you for the detailed notes. Would you mind adding to the comment that for performance, stack walkers check biased_locking first, then the displaced_header for the recursive case, before checking whether the monitor is inflated. The change looks good. I spent a day bringing this back into my memory cache, and looking for other similar holes and did not find any. I did not do a detailed exploration of AARCH64. thanks, Karen > On Mar 30, 2016, at 7:44 PM, Daniel D. Daugherty wrote: > > Greetings, > > I've updated the fixes for 8077392 and 8131715 based on code review > comments and test results. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/1-jdk9-hs-rt/ > > src/share/vm/runtime/sharedRuntime.cpp > Changed to disable ObjectSynchronizer::quick_enter() for ARM64 > since testing has shown that ARM64 still has hangs when the > quick_enter() optimization is enabled. See: > > JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs > https://bugs.openjdk.java.net/browse/JDK-8153107 > > I suspect a mis-match between the quick_enter() optimization > and the ARM64 MacroAssembler code... > > src/share/vm/runtime/synchronizer.cpp > Moved the init of the BasicLock's displaced_header to be > unconditional instead of only when Atomic::cmpxchg_ptr() > works. See the more detailed comments. > > Also fixed a code review request to rename the 'Lock' param. > > Redoing all the same testing... > > As always, comments, suggestions and/or questions are welcome. > > Dan > > > > On 3/22/16 2:41 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have fixes for the following two bugs: >> >> JDK-8077392 Stream fork/join tasks occasionally fail to complete >> https://bugs.openjdk.java.net/browse/JDK-8077392 >> >> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> >> Both fixes are very, very small and will be bundled together in the >> same changeset for obvious reasons. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ >> >> While the fix for JDK-8077392 is a simple 1-liner, the explanation of >> the race is much, much longer. I've attached the detailed evaluation >> to this RFR; it is a copy of the same note that I added to >> https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached >> copy has all the indentation white space intact. I don't know why >> JBS likes to reformat the notes, but it does... :-( >> >> Testing: >> >> - the original failing test is running in a parallel stress config >> on my Solaris X64 server; just under 23 hours and just under >> 3000 iterations without a failure in either instance; I'm planning >> to let the stress run go for at least 72 hours. >> - RT/SVC nightly equivalent (in progress) >> >> As always, comments, suggestions and/or questions are welcome. >> >> Dan > From daniel.daugherty at oracle.com Fri Apr 1 22:08:39 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Apr 2016 16:08:39 -0600 Subject: RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket In-Reply-To: <8A037A40-34DD-4898-85B3-65978B6DEEB9@oracle.com> References: <56F1ADEC.2050508@oracle.com> <56FC64C0.9020003@oracle.com> <8A037A40-34DD-4898-85B3-65978B6DEEB9@oracle.com> Message-ID: <56FEF167.6000301@oracle.com> On 4/1/16 3:23 PM, Karen Kinnear wrote: > Dan, > > Impressive debugging and analysis! Thanks! It was a long hunt, but worth it... > Thank you for the detailed notes. You're very welcome! Hope you enjoyed the nap... :-) > Would you mind adding to the comment that for performance, stack walkers check biased_locking first, then > the displaced_header for the recursive case, before checking whether the monitor is inflated. I'll figure out an acceptable addition off-thread with you and then update/add it before pushing. The 72 hour stress test doesn't finish until Sunday night... so I have time... > The change looks good. Thanks! > I spent a day bringing this back into my memory cache, I'm hoping that the wikis we're developing will help that process over time. It's certainly been good to get the lore written down and out of various folks heads... > and looking for other similar holes > and did not find any. Very cool! I've been planning to audit the places where we grab ownership of the ObjectMonitor, but I wanted some distance from the code first... > I did not do a detailed exploration of AARCH64. That will be done (by someone) with this bug: JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs https://bugs.openjdk.java.net/browse/JDK-8153107 Dan > > thanks, > Karen > > >> On Mar 30, 2016, at 7:44 PM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> I've updated the fixes for 8077392 and 8131715 based on code review >> comments and test results. >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/1-jdk9-hs-rt/ >> >> src/share/vm/runtime/sharedRuntime.cpp >> Changed to disable ObjectSynchronizer::quick_enter() for ARM64 >> since testing has shown that ARM64 still has hangs when the >> quick_enter() optimization is enabled. See: >> >> JDK-8153107 enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs >> https://bugs.openjdk.java.net/browse/JDK-8153107 >> >> I suspect a mis-match between the quick_enter() optimization >> and the ARM64 MacroAssembler code... >> >> src/share/vm/runtime/synchronizer.cpp >> Moved the init of the BasicLock's displaced_header to be >> unconditional instead of only when Atomic::cmpxchg_ptr() >> works. See the more detailed comments. >> >> Also fixed a code review request to rename the 'Lock' param. >> >> Redoing all the same testing... >> >> As always, comments, suggestions and/or questions are welcome. >> >> Dan >> >> >> >> On 3/22/16 2:41 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have fixes for the following two bugs: >>> >>> JDK-8077392 Stream fork/join tasks occasionally fail to complete >>> https://bugs.openjdk.java.net/browse/JDK-8077392 >>> >>> JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is fixed >>> https://bugs.openjdk.java.net/browse/JDK-8131715 >>> >>> Both fixes are very, very small and will be bundled together in the >>> same changeset for obvious reasons. >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/ >>> >>> While the fix for JDK-8077392 is a simple 1-liner, the explanation of >>> the race is much, much longer. I've attached the detailed evaluation >>> to this RFR; it is a copy of the same note that I added to >>> https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached >>> copy has all the indentation white space intact. I don't know why >>> JBS likes to reformat the notes, but it does... :-( >>> >>> Testing: >>> >>> - the original failing test is running in a parallel stress config >>> on my Solaris X64 server; just under 23 hours and just under >>> 3000 iterations without a failure in either instance; I'm planning >>> to let the stress run go for at least 72 hours. >>> - RT/SVC nightly equivalent (in progress) >>> >>> As always, comments, suggestions and/or questions are welcome. >>> >>> Dan From frederic.parain at oracle.com Mon Apr 4 08:31:35 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Mon, 4 Apr 2016 10:31:35 +0200 Subject: RFR (XS): JDK-8146093 [sparc only] compiler/interpreter/7116216/StackOverflow.java Program terminates with signal 11, Segmentation fault. in __1cLRegisterMap2t6MpnKJavaThread_b_v_ () Message-ID: <57022667.6070308@oracle.com> Greetings, Please review this small fix in the stack overflow check for the SPARC platform. The check was not updated when JEP-270 has been pushed. The one line fix in file templateInterpreterGenerator_sparc.cpp adjusts the check to the new execution stack layout introduced by JEP-270. Changes in interpreterRuntime.[ch]pp files are just a piggybacked clean up to remove a dead method from the JEP-270 push. Webrev: http://cr.openjdk.java.net/~fparain/8146093/webrev.00/ CR: https://bugs.openjdk.java.net/browse/JDK-8146093 The bug also triggered another type of failure which has been assigned to a different CR: https://bugs.openjdk.java.net/browse/JDK-8152675 The fix has been tested against the two failures and resolves both of them. Testing: JPRT with hotspot testset manual testing of the two tests indicated in CRs, with stress testing of several dozens hours each (stack overflow bugs are often hard to reproduce) Thanks, Fred -- Frederic Parain - Oracle Grenoble Engineering Center - France Phone: +33 4 76 18 81 17 Email: Frederic.Parain at oracle.com From rachel.protacio at oracle.com Mon Apr 4 14:11:30 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 4 Apr 2016 10:11:30 -0400 Subject: RFR: 8153026: Change logging tag 'verboseverification' to 'verification' Message-ID: <57027612.50002@oracle.com> Hello! Please review this fix, changing the redundant tag 'verboseverification' to 'verification'. Passes JPRT and RBT quick/non-colo tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8153026 Open webrev: http://cr.openjdk.java.net/~rprotacio/8153026.00/ Thank you! Rachel From harold.seigel at oracle.com Mon Apr 4 14:27:07 2016 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 4 Apr 2016 10:27:07 -0400 Subject: RFR: 8153026: Change logging tag 'verboseverification' to 'verification' In-Reply-To: <57027612.50002@oracle.com> References: <57027612.50002@oracle.com> Message-ID: <570279BB.7040204@oracle.com> Hi Rachel, 'verboseverification' is also in arguments.cpp and test RemovedDevelopFlagsTest.java. Can you check those files, also? Thanks, Harold On 4/4/2016 10:11 AM, Rachel Protacio wrote: > Hello! > > Please review this fix, changing the redundant tag > 'verboseverification' to 'verification'. Passes JPRT and RBT > quick/non-colo tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153026 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8153026.00/ > > Thank you! > Rachel From rachel.protacio at oracle.com Mon Apr 4 14:36:56 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 4 Apr 2016 10:36:56 -0400 Subject: RFR: 8153026: Change logging tag 'verboseverification' to 'verification' In-Reply-To: <570279BB.7040204@oracle.com> References: <57027612.50002@oracle.com> <570279BB.7040204@oracle.com> Message-ID: <57027C08.3020305@oracle.com> Thanks for noticing, Harold! That snuck by me when I grepped for log statements only, and it amusingly passed its own test. Updated the webrev with these files: http://cr.openjdk.java.net/~rprotacio/8153026.00/ Builds, RemovedDevelopFlagsTest.java passes. Rachel On 4/4/2016 10:27 AM, harold seigel wrote: > Hi Rachel, > > 'verboseverification' is also in arguments.cpp and test > RemovedDevelopFlagsTest.java. Can you check those files, also? > > Thanks, Harold > > On 4/4/2016 10:11 AM, Rachel Protacio wrote: >> Hello! >> >> Please review this fix, changing the redundant tag >> 'verboseverification' to 'verification'. Passes JPRT and RBT >> quick/non-colo tests. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153026 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8153026.00/ >> >> Thank you! >> Rachel > From harold.seigel at oracle.com Mon Apr 4 14:40:53 2016 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 4 Apr 2016 10:40:53 -0400 Subject: RFR: 8153026: Change logging tag 'verboseverification' to 'verification' In-Reply-To: <57027C08.3020305@oracle.com> References: <57027612.50002@oracle.com> <570279BB.7040204@oracle.com> <57027C08.3020305@oracle.com> Message-ID: <57027CF5.1050401@oracle.com> That looks good! Harold On 4/4/2016 10:36 AM, Rachel Protacio wrote: > Thanks for noticing, Harold! That snuck by me when I grepped for log > statements only, and it amusingly passed its own test. Updated the > webrev with these files: > http://cr.openjdk.java.net/~rprotacio/8153026.00/ > > Builds, RemovedDevelopFlagsTest.java passes. > > Rachel > > On 4/4/2016 10:27 AM, harold seigel wrote: >> Hi Rachel, >> >> 'verboseverification' is also in arguments.cpp and test >> RemovedDevelopFlagsTest.java. Can you check those files, also? >> >> Thanks, Harold >> >> On 4/4/2016 10:11 AM, Rachel Protacio wrote: >>> Hello! >>> >>> Please review this fix, changing the redundant tag >>> 'verboseverification' to 'verification'. Passes JPRT and RBT >>> quick/non-colo tests. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153026 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8153026.00/ >>> >>> Thank you! >>> Rachel >> > From lois.foltan at oracle.com Mon Apr 4 14:42:39 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 04 Apr 2016 10:42:39 -0400 Subject: RFR: 8153026: Change logging tag 'verboseverification' to 'verification' In-Reply-To: <57027C08.3020305@oracle.com> References: <57027612.50002@oracle.com> <570279BB.7040204@oracle.com> <57027C08.3020305@oracle.com> Message-ID: <57027D5F.6080706@oracle.com> Looks good. Lois On 4/4/2016 10:36 AM, Rachel Protacio wrote: > Thanks for noticing, Harold! That snuck by me when I grepped for log > statements only, and it amusingly passed its own test. Updated the > webrev with these files: > http://cr.openjdk.java.net/~rprotacio/8153026.00/ > > Builds, RemovedDevelopFlagsTest.java passes. > > Rachel > > On 4/4/2016 10:27 AM, harold seigel wrote: >> Hi Rachel, >> >> 'verboseverification' is also in arguments.cpp and test >> RemovedDevelopFlagsTest.java. Can you check those files, also? >> >> Thanks, Harold >> >> On 4/4/2016 10:11 AM, Rachel Protacio wrote: >>> Hello! >>> >>> Please review this fix, changing the redundant tag >>> 'verboseverification' to 'verification'. Passes JPRT and RBT >>> quick/non-colo tests. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153026 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8153026.00/ >>> >>> Thank you! >>> Rachel >> > From rachel.protacio at oracle.com Mon Apr 4 14:46:48 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 4 Apr 2016 10:46:48 -0400 Subject: RFR: 8153026: Change logging tag 'verboseverification' to 'verification' In-Reply-To: <57027D5F.6080706@oracle.com> References: <57027612.50002@oracle.com> <570279BB.7040204@oracle.com> <57027C08.3020305@oracle.com> <57027D5F.6080706@oracle.com> Message-ID: <57027E58.8010104@oracle.com> Thank you for reviewing, Harold and Lois! Rachel On 4/4/2016 10:42 AM, Lois Foltan wrote: > Looks good. > Lois > > On 4/4/2016 10:36 AM, Rachel Protacio wrote: >> Thanks for noticing, Harold! That snuck by me when I grepped for log >> statements only, and it amusingly passed its own test. Updated the >> webrev with these files: >> http://cr.openjdk.java.net/~rprotacio/8153026.00/ >> >> Builds, RemovedDevelopFlagsTest.java passes. >> >> Rachel >> >> On 4/4/2016 10:27 AM, harold seigel wrote: >>> Hi Rachel, >>> >>> 'verboseverification' is also in arguments.cpp and test >>> RemovedDevelopFlagsTest.java. Can you check those files, also? >>> >>> Thanks, Harold >>> >>> On 4/4/2016 10:11 AM, Rachel Protacio wrote: >>>> Hello! >>>> >>>> Please review this fix, changing the redundant tag >>>> 'verboseverification' to 'verification'. Passes JPRT and RBT >>>> quick/non-colo tests. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153026 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8153026.00/ >>>> >>>> Thank you! >>>> Rachel >>> >> > From robbin.ehn at oracle.com Mon Apr 4 15:09:07 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 4 Apr 2016 17:09:07 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests Message-ID: <57028393.5020104@oracle.com> Hi all, Please review, Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 Tested with internal vm test. Thanks! /Robbin From stefan.karlsson at oracle.com Mon Apr 4 15:23:42 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 4 Apr 2016 17:23:42 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests In-Reply-To: <57028393.5020104@oracle.com> References: <57028393.5020104@oracle.com> Message-ID: <570286FE.5080503@oracle.com> Looks good. StefanK On 2016-04-04 17:09, Robbin Ehn wrote: > Hi all, > > Please review, > > Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 > > Tested with internal vm test. > > Thanks! > > /Robbin From chris.plummer at oracle.com Mon Apr 4 16:09:45 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 4 Apr 2016 09:09:45 -0700 Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can be excluded when JVMTI is not supported In-Reply-To: <56FD50C5.4020303@oracle.com> References: <56FCC1B9.3060007@oracle.com> <56FCD404.8030601@oracle.com> <56FD50C5.4020303@oracle.com> Message-ID: <570291C9.30801@oracle.com> Ping! Still looking for one more reviewer. thanks, Chris On 3/31/16 9:31 AM, Chris Plummer wrote: > Hi Serguei, > > Thanks for the review. I'll make all the changes you suggested. > > cheers, > > Chris > > On 3/31/16 12:38 AM, serguei.spitsyn at oracle.com wrote: >> Hi Chris, >> >> >> It looks pretty good, thanks! >> >> Just some minor comments below. >> >> src/share/vm/ci/ciMethod.cpp >> >> The only file with old Copyright year. >> >> src/share/vm/oops/instanceKlass.hpp >> >> 907 // Breakpoint support (see methods on Method* for details) >> 908 #if INCLUDE_JVMTI >> 909 BreakpointInfo* breakpoints() const { return _breakpoints; }; >> 910 void set_breakpoints(BreakpointInfo* bps) { _breakpoints = bps; }; >> 911 #endif >> Better to move the comment at the L907 inside the ifdef block. >> >> 1280 // RedefineClasses support >> 1281 #if INCLUDE_JVMTI >> 1282 void link_previous_versions(InstanceKlass* pv) { _previous_versions = pv; } >> 1283 void mark_newly_obsolete_methods(Array* old_methods, int emcp_method_count); >> 1284 #endif >> Better to move the comment at the L1280 inside the ifdef block. >> >> >> src/share/vm/oops/method.hpp >> 1041 /// Fast Breakpoints. >> 1042 >> 1043 // If this structure gets more complicated (because bpts get numerous), >> 1044 // move it into its own header. >> 1045 >> 1046 // There is presently no provision for concurrent access >> 1047 // to breakpoint lists, which is only OK for JVMTI because >> 1048 // breakpoints are written only at safepoints, and are read >> 1049 // concurrently only outside of safepoints. >> 1050 >> 1051 #if INCLUDE_JVMTI >> Better to move the comments at the L1041-1949 inside the ifdef block. >> >> Consider it reviewed, I do not need to see another webrev. >> >> >> Thanks, >> Serguei >> >> >> On 3/30/16 23:20, Chris Plummer wrote: >>> Please review the following for removing some fields that are not >>> needed when not supporting JVMTI. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8148195 >>> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.02/webrev.hotspot/ >>> >>> I had passed a preliminary review around a month or so ago. The >>> webrev is here: >>> >>> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.01/webrev.hotspot/ >>> >>> I made a number of changes since then. I tried to reduce the number >>> of #ifdefs, but at the same time include less unnecessary code in >>> the INCLUDE_JVMTI=0 build. For example, BreakpointInfo is now >>> completely gone when not including JVMTI. I didn't really succeed at >>> the former since #ifdefs seem to have just moved around, but there >>> is a lot more code conditionally compiled out now, and I think it's >>> cleaner this way. >>> >>> Also since the previous webrev, I added some fixes for SA, although >>> these aren't possible to test right now. Currently the minimal VM is >>> the only one that supports excluding JVMTI, but it also excludes SA, >>> so that makes it hard to test conditionally removing some JVMTI >>> support from SA. I tried doing a client VM build without JVMTI, but >>> that's currently broken (can't build with INCLUDE_JVMTI=0 and >>> INCLUDE_SERVICES=1). It's a known issue that's already being worked on. >>> >>> Testing I've done: >>> >>> - jprt -testset hotspot >>> - jck vm tests with minimal vm on linux-x86 >>> - hotspot/test/:compact2_minimal with minimal vm on linux-x86 >>> - all the serviceability tests I could find supported by RBT. Ran >>> with client vm >>> on linux-x86 and server vm on linux-x64. >>> >>> I'm going to try to do more minimal VM testing. I need to figure out >>> more test suites I can run with minimal and not get a ton of errors >>> due to the tests using excluded functionality. >>> >>> thanks, >>> >>> Chris >> > From coleen.phillimore at oracle.com Mon Apr 4 17:51:59 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 4 Apr 2016 13:51:59 -0400 Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can be excluded when JVMTI is not supported In-Reply-To: <570291C9.30801@oracle.com> References: <56FCC1B9.3060007@oracle.com> <56FCD404.8030601@oracle.com> <56FD50C5.4020303@oracle.com> <570291C9.30801@oracle.com> Message-ID: <5702A9BF.9040408@oracle.com> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.02/webrev.hotspot/src/share/vm/oops/method.hpp.udiff.html Can you add // INCLUDE_JVMTI to this #endif around line 1069. My threshold for missing // INCLUDE comment at the end of #endif is about 4 lines. I think this looks good though. It should save a bit of memory and is not too invasive. thanks, Coleen On 4/4/16 12:09 PM, Chris Plummer wrote: > Ping! Still looking for one more reviewer. > > thanks, > > Chris > > On 3/31/16 9:31 AM, Chris Plummer wrote: >> Hi Serguei, >> >> Thanks for the review. I'll make all the changes you suggested. >> >> cheers, >> >> Chris >> >> On 3/31/16 12:38 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Chris, >>> >>> >>> It looks pretty good, thanks! >>> >>> Just some minor comments below. >>> >>> src/share/vm/ci/ciMethod.cpp >>> >>> The only file with old Copyright year. >>> >>> src/share/vm/oops/instanceKlass.hpp >>> >>> 907 // Breakpoint support (see methods on Method* for details) >>> 908 #if INCLUDE_JVMTI >>> 909 BreakpointInfo* breakpoints() const { return >>> _breakpoints; }; >>> 910 void set_breakpoints(BreakpointInfo* bps) { _breakpoints = >>> bps; }; >>> 911 #endif >>> Better to move the comment at the L907 inside the ifdef block. >>> >>> 1280 // RedefineClasses support >>> 1281 #if INCLUDE_JVMTI >>> 1282 void link_previous_versions(InstanceKlass* pv) { >>> _previous_versions = pv; } >>> 1283 void mark_newly_obsolete_methods(Array* old_methods, >>> int emcp_method_count); >>> 1284 #endif >>> Better to move the comment at the L1280 inside the ifdef block. >>> >>> >>> src/share/vm/oops/method.hpp >>> 1041 /// Fast Breakpoints. >>> 1042 >>> 1043 // If this structure gets more complicated (because bpts get >>> numerous), >>> 1044 // move it into its own header. >>> 1045 >>> 1046 // There is presently no provision for concurrent access >>> 1047 // to breakpoint lists, which is only OK for JVMTI because >>> 1048 // breakpoints are written only at safepoints, and are read >>> 1049 // concurrently only outside of safepoints. >>> 1050 >>> 1051 #if INCLUDE_JVMTI >>> Better to move the comments at the L1041-1949 inside the ifdef block. >>> >>> Consider it reviewed, I do not need to see another webrev. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 3/30/16 23:20, Chris Plummer wrote: >>>> Please review the following for removing some fields that are not >>>> needed when not supporting JVMTI. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8148195 >>>> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.02/webrev.hotspot/ >>>> >>>> >>>> I had passed a preliminary review around a month or so ago. The >>>> webrev is here: >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.01/webrev.hotspot/ >>>> >>>> >>>> I made a number of changes since then. I tried to reduce the number >>>> of #ifdefs, but at the same time include less unnecessary code in >>>> the INCLUDE_JVMTI=0 build. For example, BreakpointInfo is now >>>> completely gone when not including JVMTI. I didn't really succeed >>>> at the former since #ifdefs seem to have just moved around, but >>>> there is a lot more code conditionally compiled out now, and I >>>> think it's cleaner this way. >>>> >>>> Also since the previous webrev, I added some fixes for SA, although >>>> these aren't possible to test right now. Currently the minimal VM >>>> is the only one that supports excluding JVMTI, but it also excludes >>>> SA, so that makes it hard to test conditionally removing some JVMTI >>>> support from SA. I tried doing a client VM build without JVMTI, but >>>> that's currently broken (can't build with INCLUDE_JVMTI=0 and >>>> INCLUDE_SERVICES=1). It's a known issue that's already being worked >>>> on. >>>> >>>> Testing I've done: >>>> >>>> - jprt -testset hotspot >>>> - jck vm tests with minimal vm on linux-x86 >>>> - hotspot/test/:compact2_minimal with minimal vm on linux-x86 >>>> - all the serviceability tests I could find supported by RBT. Ran >>>> with client vm >>>> on linux-x86 and server vm on linux-x64. >>>> >>>> I'm going to try to do more minimal VM testing. I need to figure >>>> out more test suites I can run with minimal and not get a ton of >>>> errors due to the tests using excluded functionality. >>>> >>>> thanks, >>>> >>>> Chris >>> >> > From coleen.phillimore at oracle.com Mon Apr 4 19:53:19 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 4 Apr 2016 15:53:19 -0400 Subject: RFR: 8152905: hs_err file is missing gc threads In-Reply-To: <56FB48E8.5050609@oracle.com> References: <56FB48E8.5050609@oracle.com> Message-ID: <5702C62F.3060005@oracle.com> Hi Derek, Can you attach an example of the hs_err_pid.log file that shows these additions? thanks, Coleen On 3/29/16 11:32 PM, Derek White wrote: > Summary: List the GC threads in the hs_err file in the "Other Threads" > section > > There are 4 small parts to this: > 1) Fix G1CollectedHeap::gc_threads_do() to also iterate over > concurrent mark worker threads. > 2) Have Thread::print_on_error() print the thread name of NamedThreads. > 3) Factor out code that prints out each "Other Thread" to > Threads::print_on_error(). > 4) Call Threads::print_on_error() on every GC thread. > > BUG: 8152905: hs_err file is missing gc threads > > WEBREV: http://cr.openjdk.java.net/~drwhite/8152905/webrev.01/ > TESTING: > - Tested "java -XX:ErrorHandlerTest=1 -version" on all collectors. > - jprt > > Thanks, > > - Derek From calvin.cheung at oracle.com Mon Apr 4 21:07:50 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 04 Apr 2016 14:07:50 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive Message-ID: <5702D7A6.1090601@oracle.com> Please review this small fix for: https://bugs.openjdk.java.net/browse/JDK-8152329 The fix is to convert the buffer containing the jar manifest into lower case before performing strstr. webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ Testing: JPRT -testset hotspot The tests under runtime on the platforms built by JPRT. thanks, Calvin From ioi.lam at oracle.com Mon Apr 4 21:19:28 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 04 Apr 2016 14:19:28 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <5702D7A6.1090601@oracle.com> References: <5702D7A6.1090601@oracle.com> Message-ID: <5702DA60.8040103@oracle.com> Looks good to me. Thanks! - Ioi On 4/4/16 2:07 PM, Calvin Cheung wrote: > > Please review this small fix for: > https://bugs.openjdk.java.net/browse/JDK-8152329 > > The fix is to convert the buffer containing the jar manifest into > lower case before performing strstr. > > webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ > > Testing: > JPRT -testset hotspot > The tests under runtime on the platforms built by JPRT. > > thanks, > Calvin From calvin.cheung at oracle.com Mon Apr 4 21:30:24 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 04 Apr 2016 14:30:24 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <5702DA60.8040103@oracle.com> References: <5702D7A6.1090601@oracle.com> <5702DA60.8040103@oracle.com> Message-ID: <5702DCF0.10307@oracle.com> Thanks Ioi! Calvin On 4/4/16, 2:19 PM, Ioi Lam wrote: > Looks good to me. Thanks! > - Ioi > > On 4/4/16 2:07 PM, Calvin Cheung wrote: >> >> Please review this small fix for: >> https://bugs.openjdk.java.net/browse/JDK-8152329 >> >> The fix is to convert the buffer containing the jar manifest into >> lower case before performing strstr. >> >> webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ >> >> Testing: >> JPRT -testset hotspot >> The tests under runtime on the platforms built by JPRT. >> >> thanks, >> Calvin > From daniel.daugherty at oracle.com Mon Apr 4 22:32:10 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 4 Apr 2016 16:32:10 -0600 Subject: RFR (XS): JDK-8146093 [sparc only] compiler/interpreter/7116216/StackOverflow.java Program terminates with signal 11, Segmentation fault. in __1cLRegisterMap2t6MpnKJavaThread_b_v_ () In-Reply-To: <57022667.6070308@oracle.com> References: <57022667.6070308@oracle.com> Message-ID: <5702EB6A.2090401@oracle.com> On 4/4/16 2:31 AM, Frederic Parain wrote: > Greetings, > > Please review this small fix in the stack overflow check > for the SPARC platform. The check was not updated when > JEP-270 has been pushed. The one line fix in file > templateInterpreterGenerator_sparc.cpp adjusts the check > to the new execution stack layout introduced by JEP-270. > > Changes in interpreterRuntime.[ch]pp files are just > a piggybacked clean up to remove a dead method from the > JEP-270 push. > > Webrev: > http://cr.openjdk.java.net/~fparain/8146093/webrev.00/ src/share/vm/interpreter/interpreterRuntime.hpp No comments. src/share/vm/interpreter/interpreterRuntime.cpp No comments; thanks for fixing the bad indent on next function. src/cpu/sparc/vm/templateInterpreterGenerator_sparc.cpp No comments. Thumbs up. Dan > > CR: > https://bugs.openjdk.java.net/browse/JDK-8146093 > > The bug also triggered another type of failure which > has been assigned to a different CR: > https://bugs.openjdk.java.net/browse/JDK-8152675 > > The fix has been tested against the two failures and > resolves both of them. > > Testing: > JPRT with hotspot testset > manual testing of the two tests indicated in CRs, > with stress testing of several dozens hours each > (stack overflow bugs are often hard to reproduce) > > Thanks, > > Fred > > From coleen.phillimore at oracle.com Mon Apr 4 22:49:53 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 4 Apr 2016 18:49:53 -0400 Subject: RFR (XS): JDK-8146093 [sparc only] compiler/interpreter/7116216/StackOverflow.java Program terminates with signal 11, Segmentation fault. in __1cLRegisterMap2t6MpnKJavaThread_b_v_ () In-Reply-To: <57022667.6070308@oracle.com> References: <57022667.6070308@oracle.com> Message-ID: <5702EF91.8080008@oracle.com> Hi Fred, This looks good. It looks like aarch64 platform needs this change. I don't know if you want to file another bug for RedHat (or if one exists). Thanks, Coleen On 4/4/16 4:31 AM, Frederic Parain wrote: > Greetings, > > Please review this small fix in the stack overflow check > for the SPARC platform. The check was not updated when > JEP-270 has been pushed. The one line fix in file > templateInterpreterGenerator_sparc.cpp adjusts the check > to the new execution stack layout introduced by JEP-270. > > Changes in interpreterRuntime.[ch]pp files are just > a piggybacked clean up to remove a dead method from the > JEP-270 push. > > Webrev: > http://cr.openjdk.java.net/~fparain/8146093/webrev.00/ > > CR: > https://bugs.openjdk.java.net/browse/JDK-8146093 > > The bug also triggered another type of failure which > has been assigned to a different CR: > https://bugs.openjdk.java.net/browse/JDK-8152675 > > The fix has been tested against the two failures and > resolves both of them. > > Testing: > JPRT with hotspot testset > manual testing of the two tests indicated in CRs, > with stress testing of several dozens hours each > (stack overflow bugs are often hard to reproduce) > > Thanks, > > Fred > > From vladimir.kozlov at oracle.com Mon Apr 4 23:12:58 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 4 Apr 2016 16:12:58 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> Message-ID: <5702F4FA.3090305@oracle.com> Looks good to me. Thanks, Vladimir On 4/1/16 11:28 AM, Igor Veresov wrote: > When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 > Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ > > Thanks, > igor > From mikhailo.seledtsov at oracle.com Mon Apr 4 23:13:50 2016 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 4 Apr 2016 16:13:50 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <5702DCF0.10307@oracle.com> References: <5702D7A6.1090601@oracle.com> <5702DA60.8040103@oracle.com> <5702DCF0.10307@oracle.com> Message-ID: <5702F52E.5080600@oracle.com> Looks good to me. Misha On 4/4/2016 2:30 PM, Calvin Cheung wrote: > Thanks Ioi! > > Calvin > > On 4/4/16, 2:19 PM, Ioi Lam wrote: >> Looks good to me. Thanks! >> - Ioi >> >> On 4/4/16 2:07 PM, Calvin Cheung wrote: >>> >>> Please review this small fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8152329 >>> >>> The fix is to convert the buffer containing the jar manifest into >>> lower case before performing strstr. >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ >>> >>> Testing: >>> JPRT -testset hotspot >>> The tests under runtime on the platforms built by JPRT. >>> >>> thanks, >>> Calvin >> From igor.veresov at oracle.com Mon Apr 4 23:17:08 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 4 Apr 2016 16:17:08 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <5702F4FA.3090305@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5702F4FA.3090305@oracle.com> Message-ID: <77FFC56E-2B29-4D0F-8EB6-C181DFFD895D@oracle.com> Thanks, Vladimir! Can I please get another review from the runtime team? igor > On Apr 4, 2016, at 4:12 PM, Vladimir Kozlov wrote: > > Looks good to me. > > Thanks, > Vladimir > > On 4/1/16 11:28 AM, Igor Veresov wrote: >> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >> >> Thanks, >> igor >> From calvin.cheung at oracle.com Mon Apr 4 23:21:42 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Mon, 04 Apr 2016 16:21:42 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <5702F52E.5080600@oracle.com> References: <5702D7A6.1090601@oracle.com> <5702DA60.8040103@oracle.com> <5702DCF0.10307@oracle.com> <5702F52E.5080600@oracle.com> Message-ID: <5702F706.6050707@oracle.com> Thanks Misha! On 4/4/16, 4:13 PM, Mikhailo Seledtsov wrote: > Looks good to me. > > Misha > > On 4/4/2016 2:30 PM, Calvin Cheung wrote: >> Thanks Ioi! >> >> Calvin >> >> On 4/4/16, 2:19 PM, Ioi Lam wrote: >>> Looks good to me. Thanks! >>> - Ioi >>> >>> On 4/4/16 2:07 PM, Calvin Cheung wrote: >>>> >>>> Please review this small fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8152329 >>>> >>>> The fix is to convert the buffer containing the jar manifest into >>>> lower case before performing strstr. >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ >>>> >>>> Testing: >>>> JPRT -testset hotspot >>>> The tests under runtime on the platforms built by JPRT. >>>> >>>> thanks, >>>> Calvin >>> > From robbin.ehn at oracle.com Tue Apr 5 06:20:12 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 5 Apr 2016 08:20:12 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests In-Reply-To: <570286FE.5080503@oracle.com> References: <57028393.5020104@oracle.com> <570286FE.5080503@oracle.com> Message-ID: <5703591C.5060601@oracle.com> Thanks Stefan! /Robbin On 04/04/2016 05:23 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2016-04-04 17:09, Robbin Ehn wrote: >> Hi all, >> >> Please review, >> >> Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 >> >> Tested with internal vm test. >> >> Thanks! >> >> /Robbin > From bengt.rutisson at oracle.com Tue Apr 5 08:27:23 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 5 Apr 2016 10:27:23 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests In-Reply-To: <57028393.5020104@oracle.com> References: <57028393.5020104@oracle.com> Message-ID: <570376EB.1090504@oracle.com> Hi Robbin, On 2016-04-04 17:09, Robbin Ehn wrote: > Hi all, > > Please review, > > Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 Looks good. Bengt > > Tested with internal vm test. > > Thanks! > > /Robbin From robbin.ehn at oracle.com Tue Apr 5 08:46:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 5 Apr 2016 10:46:00 +0200 Subject: RFR(xs): 8153396: Remove unused ResourceMarks from UL internal vm tests In-Reply-To: <570376EB.1090504@oracle.com> References: <57028393.5020104@oracle.com> <570376EB.1090504@oracle.com> Message-ID: <57037B48.3000305@oracle.com> Thanks Bengt! /Robbin On 04/05/2016 10:27 AM, Bengt Rutisson wrote: > > > Hi Robbin, > > On 2016-04-04 17:09, Robbin Ehn wrote: >> Hi all, >> >> Please review, >> >> Webrev: http://cr.openjdk.java.net/~rehn/8153396/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153396 > > Looks good. > > Bengt > >> >> Tested with internal vm test. >> >> Thanks! >> >> /Robbin > From chris.hegarty at oracle.com Tue Apr 5 09:51:46 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 5 Apr 2016 10:51:46 +0100 Subject: RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module Message-ID: sun.misc.PostVMInitHook::run is called by the VM once its initialization is complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. Since sun.misc will be moved out of the base module, the VM should look for the PostVMInitHook in a more suitable place, say jdk.internal.vm. http://cr.openjdk.java.net/~chegar/8153498/ -Chris. From cheleswer.sahu at oracle.com Tue Apr 5 10:23:16 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Tue, 5 Apr 2016 03:23:16 -0700 (PDT) Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Message-ID: Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ Bug Brief: Test is failing on some platforms. Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. Regards, Cheleswer From filipp.zhinkin at gmail.com Tue Apr 5 11:14:35 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Tue, 5 Apr 2016 14:14:35 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: Message-ID: Hi Cheleswer, is it possible to use j.u.c.CountDownLatch for synchronization instead of sleep? Regards, Filipp. On Tue, Apr 5, 2016 at 1:23 PM, Cheleswer Sahu wrote: > Hi, > > > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8153319. > > > > Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ > > > > > > Bug Brief: Test is failing on some platforms. > > > > Problem Identified: Newly created child thread (NamedThread) is finished > its execution before main thread calls ?jstack?, which result in test > failure. > > > > Solution Proposed: Set the child thread in sleep state for forever and make > sure that ?jstack ? tool always gets executed after ? NamedThread? is > started. > > > > > > Regards, > > Cheleswer > > > > From Leonid.Mesnik at oracle.com Tue Apr 5 13:29:53 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Tue, 5 Apr 2016 16:29:53 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: Message-ID: <5703BDD1.5090108@oracle.com> Hi I don't think that sleep is a good way to ensure that thread is started. It is not reliable on the slow host / VM under stress and just waste of time on fast host. Is it possible just to add any explicit synchronization to ensure that NamedThread is started? Leonid On 05.04.2016 13:23, Cheleswer Sahu wrote: > Hi, > > > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. > > > > Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ > > > > > > Bug Brief: Test is failing on some platforms. > > > > Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. > > > > Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. > > > > > > Regards, > > Cheleswer > > > > From lois.foltan at oracle.com Tue Apr 5 13:59:47 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 05 Apr 2016 09:59:47 -0400 Subject: RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module In-Reply-To: References: Message-ID: <5703C4D3.1090108@oracle.com> Hotspot changes look good. Lois On 4/5/2016 5:51 AM, Chris Hegarty wrote: > sun.misc.PostVMInitHook::run is called by the VM once its initialization is > complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. > Since sun.misc will be moved out of the base module, the VM should > look for the PostVMInitHook in a more suitable place, say jdk.internal.vm. > > http://cr.openjdk.java.net/~chegar/8153498/ > > -Chris. From tom.rodriguez at oracle.com Tue Apr 5 15:21:53 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Apr 2016 08:21:53 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> Message-ID: looks good to me. tom > On Apr 1, 2016, at 11:28 AM, Igor Veresov wrote: > > When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 > Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Tue Apr 5 15:57:41 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Apr 2016 08:57:41 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> Message-ID: Thanks, Tom! igor > On Apr 5, 2016, at 8:21 AM, Tom Rodriguez wrote: > > looks good to me. > > tom > >> On Apr 1, 2016, at 11:28 AM, Igor Veresov wrote: >> >> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >> >> Thanks, >> igor > From chris.plummer at oracle.com Tue Apr 5 16:17:39 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 5 Apr 2016 09:17:39 -0700 Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can be excluded when JVMTI is not supported In-Reply-To: <5702A9BF.9040408@oracle.com> References: <56FCC1B9.3060007@oracle.com> <56FCD404.8030601@oracle.com> <56FD50C5.4020303@oracle.com> <570291C9.30801@oracle.com> <5702A9BF.9040408@oracle.com> Message-ID: <5703E523.7020902@oracle.com> Hi Coleen, Yep, I can do that. Although my threshold is a bit more than 4 lines, I normally would have put the comment on this one but I missed it. thanks, Chris On 4/4/16 10:51 AM, Coleen Phillimore wrote: > http://cr.openjdk.java.net/~cjplummer/8148195/webrev.02/webrev.hotspot/src/share/vm/oops/method.hpp.udiff.html > > > Can you add // INCLUDE_JVMTI to this #endif around line 1069. > > My threshold for missing // INCLUDE comment at the end of #endif is > about 4 lines. > > I think this looks good though. It should save a bit of memory and is > not too invasive. > > thanks, > Coleen > > On 4/4/16 12:09 PM, Chris Plummer wrote: >> Ping! Still looking for one more reviewer. >> >> thanks, >> >> Chris >> >> On 3/31/16 9:31 AM, Chris Plummer wrote: >>> Hi Serguei, >>> >>> Thanks for the review. I'll make all the changes you suggested. >>> >>> cheers, >>> >>> Chris >>> >>> On 3/31/16 12:38 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi Chris, >>>> >>>> >>>> It looks pretty good, thanks! >>>> >>>> Just some minor comments below. >>>> >>>> src/share/vm/ci/ciMethod.cpp >>>> >>>> The only file with old Copyright year. >>>> >>>> src/share/vm/oops/instanceKlass.hpp >>>> >>>> 907 // Breakpoint support (see methods on Method* for details) >>>> 908 #if INCLUDE_JVMTI >>>> 909 BreakpointInfo* breakpoints() const { return >>>> _breakpoints; }; >>>> 910 void set_breakpoints(BreakpointInfo* bps) { _breakpoints = >>>> bps; }; >>>> 911 #endif >>>> Better to move the comment at the L907 inside the ifdef block. >>>> >>>> 1280 // RedefineClasses support >>>> 1281 #if INCLUDE_JVMTI >>>> 1282 void link_previous_versions(InstanceKlass* pv) { >>>> _previous_versions = pv; } >>>> 1283 void mark_newly_obsolete_methods(Array* >>>> old_methods, int emcp_method_count); >>>> 1284 #endif >>>> Better to move the comment at the L1280 inside the ifdef block. >>>> >>>> >>>> src/share/vm/oops/method.hpp >>>> 1041 /// Fast Breakpoints. >>>> 1042 >>>> 1043 // If this structure gets more complicated (because bpts get >>>> numerous), >>>> 1044 // move it into its own header. >>>> 1045 >>>> 1046 // There is presently no provision for concurrent access >>>> 1047 // to breakpoint lists, which is only OK for JVMTI because >>>> 1048 // breakpoints are written only at safepoints, and are read >>>> 1049 // concurrently only outside of safepoints. >>>> 1050 >>>> 1051 #if INCLUDE_JVMTI >>>> Better to move the comments at the L1041-1949 inside the ifdef block. >>>> >>>> Consider it reviewed, I do not need to see another webrev. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 3/30/16 23:20, Chris Plummer wrote: >>>>> Please review the following for removing some fields that are not >>>>> needed when not supporting JVMTI. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8148195 >>>>> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.02/webrev.hotspot/ >>>>> >>>>> >>>>> I had passed a preliminary review around a month or so ago. The >>>>> webrev is here: >>>>> >>>>> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.01/webrev.hotspot/ >>>>> >>>>> >>>>> I made a number of changes since then. I tried to reduce the >>>>> number of #ifdefs, but at the same time include less unnecessary >>>>> code in the INCLUDE_JVMTI=0 build. For example, BreakpointInfo is >>>>> now completely gone when not including JVMTI. I didn't really >>>>> succeed at the former since #ifdefs seem to have just moved >>>>> around, but there is a lot more code conditionally compiled out >>>>> now, and I think it's cleaner this way. >>>>> >>>>> Also since the previous webrev, I added some fixes for SA, >>>>> although these aren't possible to test right now. Currently the >>>>> minimal VM is the only one that supports excluding JVMTI, but it >>>>> also excludes SA, so that makes it hard to test conditionally >>>>> removing some JVMTI support from SA. I tried doing a client VM >>>>> build without JVMTI, but that's currently broken (can't build with >>>>> INCLUDE_JVMTI=0 and INCLUDE_SERVICES=1). It's a known issue that's >>>>> already being worked on. >>>>> >>>>> Testing I've done: >>>>> >>>>> - jprt -testset hotspot >>>>> - jck vm tests with minimal vm on linux-x86 >>>>> - hotspot/test/:compact2_minimal with minimal vm on linux-x86 >>>>> - all the serviceability tests I could find supported by RBT. Ran >>>>> with client vm >>>>> on linux-x86 and server vm on linux-x64. >>>>> >>>>> I'm going to try to do more minimal VM testing. I need to figure >>>>> out more test suites I can run with minimal and not get a ton of >>>>> errors due to the tests using excluded functionality. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>> >>> >> > From lois.foltan at oracle.com Tue Apr 5 16:30:27 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 05 Apr 2016 12:30:27 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> Message-ID: <5703E823.8050400@oracle.com> Hi Igor, I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? Thanks, Lois On 4/1/2016 2:28 PM, Igor Veresov wrote: > When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 > Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ > > Thanks, > igor From igor.veresov at oracle.com Tue Apr 5 16:50:49 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Apr 2016 09:50:49 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <5703E823.8050400@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> Message-ID: <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> Hi Lois, Thanks for looking at it. Yes, it passes all hotspot jtreg tests. igor > On Apr 5, 2016, at 9:30 AM, Lois Foltan wrote: > > Hi Igor, > > I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? > > Thanks, > Lois > > On 4/1/2016 2:28 PM, Igor Veresov wrote: >> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >> >> Thanks, >> igor > From lois.foltan at oracle.com Tue Apr 5 17:34:15 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 05 Apr 2016 13:34:15 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> Message-ID: <5703F717.702@oracle.com> On 4/5/2016 12:50 PM, Igor Veresov wrote: > Hi Lois, > > Thanks for looking at it. Yes, it passes all hotspot jtreg tests. > > igor Hi Igor, Thanks for waiting on this. A couple of comments: - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. Just curious did you also run the testbase default methods tests? Lois > >> On Apr 5, 2016, at 9:30 AM, Lois Foltan wrote: >> >> Hi Igor, >> >> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >> >> Thanks, >> Lois >> >> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>> >>> Thanks, >>> igor From jiangli.zhou at oracle.com Tue Apr 5 17:44:52 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 5 Apr 2016 10:44:52 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <5702D7A6.1090601@oracle.com> References: <5702D7A6.1090601@oracle.com> Message-ID: <5FF42E5E-8C70-4E83-8F10-271737A55577@oracle.com> Hi Calvin, Have you thought about using strcasecmp()? The globalDefinitions_visCPP.hpp defines strcasecmp to _stricmp. So compiler dependency is not an issue. We have existing code that uses strcasecmp() for case insensitive comparison. // Non-standard stdlib-like stuff: inline int strcasecmp(const char *s1, const char *s2) { return _stricmp(s1,s2); } Thanks, Jiangli > On Apr 4, 2016, at 2:07 PM, Calvin Cheung wrote: > > > Please review this small fix for: > https://bugs.openjdk.java.net/browse/JDK-8152329 > > The fix is to convert the buffer containing the jar manifest into lower case before performing strstr. > > webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ > > Testing: > JPRT -testset hotspot > The tests under runtime on the platforms built by JPRT. > > thanks, > Calvin From igor.veresov at oracle.com Tue Apr 5 17:44:56 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Apr 2016 10:44:56 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <5703F717.702@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> Message-ID: > On Apr 5, 2016, at 10:34 AM, Lois Foltan wrote: > > > On 4/5/2016 12:50 PM, Igor Veresov wrote: >> Hi Lois, >> >> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >> >> igor > Hi Igor, > > Thanks for waiting on this. A couple of comments: > > - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. > > - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. > I looked at the call graphs of these guys and linktime_resolve_X_method() methods actually seem to only called within invokeX contexts. But may be I missed something. Can you give an example of a path that may cause, say, linktime_resolve_static_method() be invoked for non-invokestatic instruction? > Just curious did you also run the testbase default methods tests? Yes, within the context of a closed project. That?s actually what made these changes necessary. igor > Lois > >> >>> On Apr 5, 2016, at 9:30 AM, Lois Foltan wrote: >>> >>> Hi Igor, >>> >>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>> >>> Thanks, >>> Lois >>> >>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>> >>>> Thanks, >>>> igor > From harold.seigel at oracle.com Tue Apr 5 17:52:37 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 5 Apr 2016 13:52:37 -0400 Subject: RFR(XS) 8152846: Creation of ModuleEntryTable Investigate Need For OrderAccess::storestore() Message-ID: <5703FB65.7060504@oracle.com> Hi, Please review this small change to fix bug 8152846. This change removes an unneeded OrderAccess::storestore() call. Webrev: http://javaweb.us.oracle.com/~hseigel/webrev/bug_8152846/ JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152846 The fix was tested with JCK API, Lang, and VM tests, the UTE non-colocated quick tests, and the hotspot, JDK vm, java/io, java/lang, java/util, and java/security tests. Testing with UTE colocated tests is in progress. Thanks, Harold From calvin.cheung at oracle.com Tue Apr 5 17:53:54 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 05 Apr 2016 10:53:54 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <5FF42E5E-8C70-4E83-8F10-271737A55577@oracle.com> References: <5702D7A6.1090601@oracle.com> <5FF42E5E-8C70-4E83-8F10-271737A55577@oracle.com> Message-ID: <5703FBB2.2040205@oracle.com> On 4/5/16, 10:44 AM, Jiangli Zhou wrote: > Hi Calvin, > > Have you thought about using strcasecmp()? The > globalDefinitions_visCPP.hpp defines strcasecmp to _stricmp. So > compiler dependency is not an issue. We have existing code that uses > strcasecmp() for case insensitive comparison. I don't think it will work in this situation. It is because the manifest buffer contains all the jar manifest entries, not just the "Multi-Release" entry. In other words, "Multi-Release" isn't at the beginning of the string. thanks, Calvin > > // Non-standard stdlib-like stuff: > inline int strcasecmp(const char *s1, const char *s2) { return > _stricmp(s1,s2); } > > Thanks, > Jiangli >> On Apr 4, 2016, at 2:07 PM, Calvin Cheung > > wrote: >> >> >> Please review this small fix for: >> https://bugs.openjdk.java.net/browse/JDK-8152329 >> >> The fix is to convert the buffer containing the jar manifest into >> lower case before performing strstr. >> >> webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ >> >> Testing: >> JPRT -testset hotspot >> The tests under runtime on the platforms built by JPRT. >> >> thanks, >> Calvin > From tom.rodriguez at oracle.com Tue Apr 5 17:55:04 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 5 Apr 2016 10:55:04 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <5703F717.702@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> Message-ID: <29A506A0-BEC9-4514-B8E9-92E6C29B1E40@oracle.com> > Thanks for waiting on this. A couple of comments: > > - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. > > - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. Unless i?m misunderstanding the code, I?d say that it was a bug that nostatics was being passed as false. The standard naming in LinkResolver follows a pattern where the name is associated with the byte code being used for the invoke. So if you are in {linktime,runtime}_resolve_{foo}_method then an invokefoo byte code is what?s being used. resolve_interface_method is currently not following that naming scheme, which I think should be fixed. Maybe resolve_method_in_interface? I do agree we should be sure that the paths leading to this call agree about the actual byte code being used, but I can?t see a path where a different byte code could have been passed in. tom > > Just curious did you also run the testbase default methods tests? > Lois > >> >>> On Apr 5, 2016, at 9:30 AM, Lois Foltan wrote: >>> >>> Hi Igor, >>> >>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>> >>> Thanks, >>> Lois >>> >>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>> >>>> Thanks, >>>> igor > From igor.veresov at oracle.com Tue Apr 5 17:56:55 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Apr 2016 10:56:55 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> Message-ID: > On Apr 5, 2016, at 10:44 AM, Igor Veresov wrote: > >> >> On Apr 5, 2016, at 10:34 AM, Lois Foltan wrote: >> >> >> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>> Hi Lois, >>> >>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>> >>> igor >> Hi Igor, >> >> Thanks for waiting on this. A couple of comments: >> >> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >> >> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >> > > I looked at the call graphs of these guys and linktime_resolve_X_method() methods actually seem to only called within invokeX contexts. But may be I missed something. Can you give an example of a path that may cause, say, linktime_resolve_static_method() be invoked for non-invokestatic instruction? Actually, the easier way to think about it, would be: The answer returned by resolve_interface_method() is result of a method resolution in the interface class ?as if? it were invoked by the given bytecode instruction. It of course doesn?t not mean that the invocation is really a result of the said instruction. The context is. As you may see the logic around ?nostatic? did not change and the logic around resolve_interface_method() being called within the invokeinterface context is what we want it to be. The same effect could have been achieved by adding another bool argument to resolve_interface_method() to indicate a question within the invokeinterface context. But passing a bytecode makes it an easier to read code. igor > >> Just curious did you also run the testbase default methods tests? > > Yes, within the context of a closed project. That?s actually what made these changes necessary. > > igor > >> Lois >> >>> >>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan wrote: >>>> >>>> Hi Igor, >>>> >>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>> >>>> Thanks, >>>> Lois >>>> >>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>> >>>>> Thanks, >>>>> igor From rachel.protacio at oracle.com Tue Apr 5 18:00:27 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 5 Apr 2016 14:00:27 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging Message-ID: <5703FD3B.10307@oracle.com> Hello, Please review this change, converting -XX:+PrintCompressedOopsMode to -Xlog:gc+heap. The existing diagnostic flag has been aliased to the info level of this tagset (for the "Heap address" message that for example appears in the hs_err file), and there are both debug and trace levels of logging available as well, as per our established schema for assigning levels. Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ Passes JPRT and RBT quick/non-colo tests. Thanks! Rachel From vladimir.kozlov at oracle.com Tue Apr 5 18:10:30 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Apr 2016 11:10:30 -0700 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5703FD3B.10307@oracle.com> References: <5703FD3B.10307@oracle.com> Message-ID: <5703FF96.6090204@oracle.com> Looks fine except next change. Do we have a test which parse this output?: ! st->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", ! st->print("Heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", Thanks, Vladimir On 4/5/16 11:00 AM, Rachel Protacio wrote: > Hello, > > Please review this change, converting -XX:+PrintCompressedOopsMode to > -Xlog:gc+heap. The existing diagnostic flag has been aliased to the info > level of this tagset (for the "Heap address" message that for example > appears in the hs_err file), and there are both debug and trace levels > of logging available as well, as per our established schema for > assigning levels. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ > > Passes JPRT and RBT quick/non-colo tests. > > Thanks! > Rachel From karen.kinnear at oracle.com Tue Apr 5 18:12:41 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 5 Apr 2016 14:12:41 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> Message-ID: <01AE161D-FAE2-4F37-9E79-3951DB516EE0@oracle.com> Igor, I?d like to get back to you on this before you check in the change please. I need to sanity check the JVMS and the code. I have another set of tests written by Vladimir Ivanov that I will send you as well. thanks, Karen > On Apr 5, 2016, at 11:57 AM, Igor Veresov wrote: > > Thanks, Tom! > > igor > >> On Apr 5, 2016, at 8:21 AM, Tom Rodriguez wrote: >> >> looks good to me. >> >> tom >> >>> On Apr 1, 2016, at 11:28 AM, Igor Veresov wrote: >>> >>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>> >>> Thanks, >>> igor >> > From coleen.phillimore at oracle.com Tue Apr 5 18:51:07 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 14:51:07 -0400 Subject: RFR: 8152905: hs_err file is missing gc threads In-Reply-To: <56FBF448.9020608@oracle.com> References: <56FB48E8.5050609@oracle.com> <56FBF448.9020608@oracle.com> Message-ID: <5704091B.5020001@oracle.com> Hi Derek, I reviewed .02 webrev and it looks good. thanks, Coleen On 3/30/16 11:44 AM, Daniel D. Daugherty wrote: > On 3/29/16 9:32 PM, Derek White wrote: >> Summary: List the GC threads in the hs_err file in the "Other >> Threads" section >> >> There are 4 small parts to this: >> 1) Fix G1CollectedHeap::gc_threads_do() to also iterate over >> concurrent mark worker threads. >> 2) Have Thread::print_on_error() print the thread name of NamedThreads. >> 3) Factor out code that prints out each "Other Thread" to >> Threads::print_on_error(). >> 4) Call Threads::print_on_error() on every GC thread. >> >> BUG: 8152905: hs_err file is missing gc threads >> >> WEBREV: http://cr.openjdk.java.net/~drwhite/8152905/webrev.01/ > > src/share/vm/runtime/thread.hpp > No comments. > > src/share/vm/runtime/thread.cpp > L831: else st->print("Thread"); > L832: > L833: if (is_Named_thread()) { > L834: st->print(" \"%s\"", name()); > L835: } > > The new is_Named_thread() check is currently made for > every thread type, but only applies to the else-statement > on L831. That else-statement should change into an > else-block. Perhaps: > > else { > st->print("Thread"); > if (is_Named_thread()) { > st->print(" \"%s\"", name()); > } > } > > L4496: if (this_thread) { > Should not use an implied boolean. This should be: > > if (this_thread != NULL) { > > L4533: bool is_current = (current == thread); > L4534: found_current = found_current || is_current; > L4535: > L4536: st->print("%s", is_current ? "=>" : " "); > L4537: > L4538: st->print(PTR_FORMAT, p2i(thread)); > L4539: st->print(" "); > L4540: thread->print_on_error(st, buf, buflen); > L4541: st->cr(); > > I think this block can refactor into: > > print_on_error(thread, st, current, buf, buflen, > &found_current); > > src/share/vm/gc/g1/g1CollectedHeap.cpp > No comments. > > src/share/vm/gc/g1/g1ConcurrentMark.cpp > No comments. > > src/share/vm/gc/g1/g1ConcurrentMark.hpp > No comments. > > Dan > > >> TESTING: >> - Tested "java -XX:ErrorHandlerTest=1 -version" on all collectors. >> - jprt >> >> Thanks, >> >> - Derek >> > From karen.kinnear at oracle.com Tue Apr 5 19:04:12 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 5 Apr 2016 15:04:12 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <5703F717.702@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> Message-ID: I am in agreement with Lois that the JVMS looks good with moving the exception. With the checking I have done so far, I believe that linktime_resolve_static_method is only called with an invoke static - but after my next meeting I will check one more time. It might be worth adding a comment. My concern is specific to the code in jvmciCompilerToVM.cpp there is code called resolveMethod that checks if holder_klass->is_interface -> LR::linktime_resolve_interface_method_or_null. I think we need to study this one more closely - I suspect that you need a set of detailed tests that cover the corner cases here. I don?t know the code paths, but I would suggest following this approach of passing in the byte code, so that you get the correct behavior depending on the requesting byte code. I am not sure what resolveMethod is doing here - since you seem to already have the resolved method and the receiver - so I could use help studying this a bit more to understand if this really is resolution or is really selection. thanks, Karen > On Apr 5, 2016, at 1:34 PM, Lois Foltan wrote: > > > On 4/5/2016 12:50 PM, Igor Veresov wrote: >> Hi Lois, >> >> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >> >> igor > Hi Igor, > > Thanks for waiting on this. A couple of comments: > > - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. > > - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. > > Just curious did you also run the testbase default methods tests? > Lois > >> >>> On Apr 5, 2016, at 9:30 AM, Lois Foltan wrote: >>> >>> Hi Igor, >>> >>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>> >>> Thanks, >>> Lois >>> >>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>> >>>> Thanks, >>>> igor > From coleen.phillimore at oracle.com Tue Apr 5 19:42:13 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 15:42:13 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <56FE3514.5050104@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> Message-ID: <57041515.4020206@oracle.com> On 4/1/16 4:45 AM, Marcus Larsson wrote: > Hi, > > On 03/31/2016 08:08 PM, Max Ockner wrote: >> (Replies in line) >> >> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>> Hi Max, >>> >>> Disclaimer: not a (R)eviewer. >>> >>> Do we really need a list of all tags and all decorators? >>> >> Just going by what we currently put in the hs_err file, I think this >> may be the first "Do we really need" we've ever asked for this type >> of change. >> >> All joking aside, I think it is a good idea to direct users toward >> proper UL usage whenever we have a chance. >> >>> Also: I assume what you print is the Log state as it is at the time >>> the hs-err file is printed. If logging was enabled/changed during >>> lifetime of the VM, e.g. with jcmd, would it be possible to see >>> that? At least a warning if logging was not enabled from the start on. >>> >> Would it be possible? Yes, but I think this would require a framework >> change. It does not look like any marks are made when the >> LogConfiguration changes during runtime, and we would need to record >> that in order to know what to print when we dump into hs_err. > > Yes, this would required the framework to keep some sort of log of > configuration changes. Is there value in knowing that the log > configuration changed since startup? > Actually, there's an Event logger that saves events and then we print the last 'n' events out in the hs_err file. If you think this would be useful, please file an RFE. Thanks, Coleen >> >> Thanks, >> Max >>> Kind Regards, Thomas >>> >>> >>> >>> >>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >> > wrote: >>> >>> Hello, >>> Please review another Unified Logging change. They are almost >>> done, and we are serious this time. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>> >>> > > LogConfiguration::describe() takes the ConfigurationLock, which might > be problematic for the error handler. I suppose the error handler > could potentially deadlock if its thread already holds the lock. > Unsure how to resolve this, because skipping to take the lock means > that we might crash due to another thread changing the configuration > as we read it. > > Thanks, > Marcus > >>> >>> The logging configuration is now printed in each hs_err file. The >>> output is the same as you would see from -Xlog:logging=trace and >>> it is obtained from LogConfiguration::describe(). >>> >>> Below is a sample of the hs_err contents. The Logging info is >>> printed after VM Arguments and Whitebox, and before Environment >>> Variables. >>> >>> VM Arguments: >>> java_command: Kaboom >>> java_class_path (initial): . >>> Launcher Type: SUN_STANDARD >>> >>> Logging: >>> Available log levels: off, trace, debug, info, warning, error >>> Available log decorators: time (t), uptime (u), timemillis (tm), >>> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname >>> (hn), pid (p), tid (ti), level (l), tags (tg) >>> Available log tags: alloc, age, barrier, biasedlocking, bot, >>> census, classhisto, classresolve, classinit, classload, >>> classloaderdata, classunload, classpath, compaction, cpu, cset, >>> defaultmethods, ergo, exceptions, exit, freelist, gc, heap, >>> humongous, ihop, itables, jni, liveness, logging, marking, >>> metaspace, modules, monitorinflation, os, phases, plab, >>> promotion, preorder, protectiondomain, ref, refine, region, >>> remset, safepoint, safepointcleanup, scavenge, scrub, stacktrace, >>> start, startuptime, state, stats, stringdedup, stringtable, >>> survivor, sweep, task, thread, tlab, time, verboseverification, >>> verify, vmoperation, vtables >>> Log output configuration: >>> #0: stdout all=off uptime,level,tags, >>> #1: stderr all=warning uptime,level,tags, >>> >>> Environment Variables: >>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>> SHELL=/bin/bash >>> OS=Linux >>> >>> >> > From igor.veresov at oracle.com Tue Apr 5 19:43:51 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Apr 2016 12:43:51 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> Message-ID: <1EAD5675-6903-4C48-A778-05A99F591D1C@oracle.com> > On Apr 5, 2016, at 12:04 PM, Karen Kinnear wrote: > > I am in agreement with Lois that the JVMS looks good with moving the exception. Thanks! > > With the checking I have done so far, I believe that linktime_resolve_static_method is only called with an invoke static - but after my next > meeting I will check one more time. It might be worth adding a comment. Ok, I added a comment to resolve_interface_method(): http://cr.openjdk.java.net/~iveresov/8153115/webrev.01/ Again, the bytecode argument here indicates the context, not the actual bytecode. Of course, for example, the method may be invoked with a method handle. > > My concern is specific to the code in jvmciCompilerToVM.cpp there is code called resolveMethod that checks > if holder_klass->is_interface -> LR::linktime_resolve_interface_method_or_null. > That code needs fixing as well. We have the following issue filed for that: https://bugs.openjdk.java.net/browse/JDK-8152903 In the nutshell, resolveMethod() sort of emulates what happens during a virtual call (it is only called for invokevirtual and invokeinterface). It should do both linktime and runtime resolutions. The JVMCI version should work the same way as the CI version (see ciMethod::resolve_invoke() in ciMethod.cpp). igor > I think we need to study this one more closely - I suspect that you need a set of detailed tests that cover the > corner cases here. I don?t know the code paths, but I would suggest following this approach of passing in the byte code, > so that you get the correct behavior depending on the requesting byte code. > > I am not sure what resolveMethod is doing here - since you seem to already have the resolved method and the receiver - so > I could use help studying this a bit more to understand if this really is resolution or is really selection. > > thanks, > Karen > >> On Apr 5, 2016, at 1:34 PM, Lois Foltan wrote: >> >> >> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>> Hi Lois, >>> >>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>> >>> igor >> Hi Igor, >> >> Thanks for waiting on this. A couple of comments: >> >> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >> >> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >> >> Just curious did you also run the testbase default methods tests? >> Lois >> >>> >>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan wrote: >>>> >>>> Hi Igor, >>>> >>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>> >>>> Thanks, >>>> Lois >>>> >>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>> >>>>> Thanks, >>>>> igor >> > From coleen.phillimore at oracle.com Tue Apr 5 19:45:49 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 15:45:49 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <56FAD0E3.5090508@oracle.com> References: <56FAD0E3.5090508@oracle.com> Message-ID: <570415ED.1090808@oracle.com> This change looks good. You found the duplicated code for jcmd. To test this before you check this in to verify, start a JVM running some java program in an infinite loop, and do jcmd VM.info Thanks, Coleen On 3/29/16 3:00 PM, Max Ockner wrote: > Hello, > Please review another Unified Logging change. They are almost done, > and we are serious this time. > > bug: https://bugs.openjdk.java.net/browse/JDK-8151526 > webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ > > The logging configuration is now printed in each hs_err file. The > output is the same as you would see from -Xlog:logging=trace and it is > obtained from LogConfiguration::describe(). > > Below is a sample of the hs_err contents. The Logging info is printed > after VM Arguments and Whitebox, and before Environment Variables. > > VM Arguments: > java_command: Kaboom > java_class_path (initial): . > Launcher Type: SUN_STANDARD > > Logging: > Available log levels: off, trace, debug, info, warning, error > Available log decorators: time (t), uptime (u), timemillis (tm), > uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), > pid (p), tid (ti), level (l), tags (tg) > Available log tags: alloc, age, barrier, biasedlocking, bot, census, > classhisto, classresolve, classinit, classload, classloaderdata, > classunload, classpath, compaction, cpu, cset, defaultmethods, ergo, > exceptions, exit, freelist, gc, heap, humongous, ihop, itables, jni, > liveness, logging, marking, metaspace, modules, monitorinflation, os, > phases, plab, promotion, preorder, protectiondomain, ref, refine, > region, remset, safepoint, safepointcleanup, scavenge, scrub, > stacktrace, start, startuptime, state, stats, stringdedup, > stringtable, survivor, sweep, task, thread, tlab, time, > verboseverification, verify, vmoperation, vtables > Log output configuration: > #0: stdout all=off uptime,level,tags, > #1: stderr all=warning uptime,level,tags, > > Environment Variables: > JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk > > PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin > > SHELL=/bin/bash > OS=Linux > From lois.foltan at oracle.com Tue Apr 5 19:54:14 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 05 Apr 2016 15:54:14 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> Message-ID: <570417E6.60107@oracle.com> On 4/5/2016 1:56 PM, Igor Veresov wrote: > >> On Apr 5, 2016, at 10:44 AM, Igor Veresov > > wrote: >> >>> >>> On Apr 5, 2016, at 10:34 AM, Lois Foltan >> > wrote: >>> >>> >>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>> Hi Lois, >>>> >>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>> >>>> igor >>> Hi Igor, >>> >>> Thanks for waiting on this. A couple of comments: >>> >>> - Section 6.5 Instructions for invokeinterface does indicate that a >>> "Linking Exceptions" the VM can throw an ICCE if the resolved method >>> is static or private. So I think moving this exception from runtime >>> to linktime is okay. >>> >>> - I'm concerned about the change on line #998, #1030, #1316. I >>> don't think you are necessarily guaranteed to have the bytecodes >>> that you are now passing to resolve_interface_method. For example, >>> line #998 within linktime_resolve_static_method, you may not have an >>> invokestatic here, you may have another invoke* bytecode trying to >>> invoke a static interface method. Passing in >>> Bytecodes::_invokestatic seems wrong, because even if the resolved >>> method is static, "nostatics" was set to false. >>> >> >> I looked at the call graphs of these guys and >> linktime_resolve_X_method() methods actually seem to only called >> within invokeX contexts. But may be I missed something. Can you give >> an example of a path that may cause, say, >> linktime_resolve_static_method() be invoked for non-invokestatic >> instruction? > > Actually, the easier way to think about it, would be: The answer > returned by resolve_interface_method() is result of a method > resolution in the interface class ?as if? it were invoked by the given > bytecode instruction. It of course doesn?t not mean that the > invocation is really a result of the said instruction. The context is. > As you may see the logic around ?nostatic? did not change and the > logic around resolve_interface_method() being called within the > invokeinterface context is what we want it to be. > > The same effect could have been achieved by adding another bool > argument to resolve_interface_method() to indicate a question within > the invokeinterface context. But passing a bytecode makes it an easier > to read code. Okay, I saw Tom's reply as well to my comments and I reviewed all the call paths. I think the change is okay. I kind of wish that the original bytecode was stored in the LinkInfo structure so that we could just reference the actual bytecode used and make decisions based on that instead of the parameter approach, but that maybe a RFE to investigate later. Lois > > igor > >> >>> Just curious did you also run the testbase default methods tests? >> >> Yes, within the context of a closed project. That?s actually what >> made these changes necessary. >> >> igor >> >>> Lois >>> >>>> >>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan >>>> > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> I know you have two reviews for this but could you hold off >>>>> committing until I or Karen Kinnear have a chance to review. We >>>>> both worked in this area a lot to support default methods in JDK >>>>> 8. Also, have you run the hotspot/test/runtime/SelectionResolution >>>>> tests on this? >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>> When invoking private interface methods with invokeinterface we >>>>>> throw ICCE. The check for that happens in the runtime part of the >>>>>> resolution, however, doing it at linktime seems like a better >>>>>> place, since the check doesn't depend on the receiver type. It >>>>>> also allows compiler interfaces that rely on linktime resolution >>>>>> to detect inconsistencies during parsing (see >>>>>> ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() >>>>>> (JVMCI) that are affected). >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> igor > From coleen.phillimore at oracle.com Tue Apr 5 19:55:08 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 15:55:08 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5703FD3B.10307@oracle.com> References: <5703FD3B.10307@oracle.com> Message-ID: <5704181C.7020405@oracle.com> http://cr.openjdk.java.net/~rprotacio/8152896.00/test/runtime/logging/CompressedOopsTest.java.html I think the test needs to have a @requires 64 bit rather than. 55 if (Platform.is64bit()) { around part of it, because this -XX:+UseCompressedOops is unrecognized unless it's 64 bits. 67 pb = ProcessTools.createJavaProcessBuilder("-XX:+UseCompressedOops", The code changes look good to me. Coleen On 4/5/16 2:00 PM, Rachel Protacio wrote: > Hello, > > Please review this change, converting -XX:+PrintCompressedOopsMode to > -Xlog:gc+heap. The existing diagnostic flag has been aliased to the > info level of this tagset (for the "Heap address" message that for > example appears in the hs_err file), and there are both debug and > trace levels of logging available as well, as per our established > schema for assigning levels. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ > > Passes JPRT and RBT quick/non-colo tests. > > Thanks! > Rachel From coleen.phillimore at oracle.com Tue Apr 5 19:59:38 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 15:59:38 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <570417E6.60107@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <570417E6.60107@oracle.com> Message-ID: <5704192A.3010807@oracle.com> On 4/5/16 3:54 PM, Lois Foltan wrote: > > On 4/5/2016 1:56 PM, Igor Veresov wrote: >> >>> On Apr 5, 2016, at 10:44 AM, Igor Veresov >> > wrote: >>> >>>> >>>> On Apr 5, 2016, at 10:34 AM, Lois Foltan >>> > wrote: >>>> >>>> >>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>> Hi Lois, >>>>> >>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>> >>>>> igor >>>> Hi Igor, >>>> >>>> Thanks for waiting on this. A couple of comments: >>>> >>>> - Section 6.5 Instructions for invokeinterface does indicate that a >>>> "Linking Exceptions" the VM can throw an ICCE if the resolved >>>> method is static or private. So I think moving this exception from >>>> runtime to linktime is okay. >>>> >>>> - I'm concerned about the change on line #998, #1030, #1316. I >>>> don't think you are necessarily guaranteed to have the bytecodes >>>> that you are now passing to resolve_interface_method. For example, >>>> line #998 within linktime_resolve_static_method, you may not have >>>> an invokestatic here, you may have another invoke* bytecode trying >>>> to invoke a static interface method. Passing in >>>> Bytecodes::_invokestatic seems wrong, because even if the resolved >>>> method is static, "nostatics" was set to false. >>>> >>> >>> I looked at the call graphs of these guys and >>> linktime_resolve_X_method() methods actually seem to only called >>> within invokeX contexts. But may be I missed something. Can you give >>> an example of a path that may cause, say, >>> linktime_resolve_static_method() be invoked for non-invokestatic >>> instruction? >> >> Actually, the easier way to think about it, would be: The answer >> returned by resolve_interface_method() is result of a method >> resolution in the interface class ?as if? it were invoked by the >> given bytecode instruction. It of course doesn?t not mean that the >> invocation is really a result of the said instruction. The context >> is. As you may see the logic around ?nostatic? did not change and the >> logic around resolve_interface_method() being called within the >> invokeinterface context is what we want it to be. >> >> The same effect could have been achieved by adding another bool >> argument to resolve_interface_method() to indicate a question within >> the invokeinterface context. But passing a bytecode makes it an >> easier to read code. > > Okay, I saw Tom's reply as well to my comments and I reviewed all the > call paths. I think the change is okay. I kind of wish that the > original bytecode was stored in the LinkInfo structure so that we > could just reference the actual bytecode used and make decisions based > on that instead of the parameter approach, but that maybe a RFE to > investigate later. There's a change coming that does store the original bytecode for bug https://bugs.openjdk.java.net/browse/JDK-8145148 Just waiting for some test changes. Coleen > Lois > >> >> igor >> >>> >>>> Just curious did you also run the testbase default methods tests? >>> >>> Yes, within the context of a closed project. That?s actually what >>> made these changes necessary. >>> >>> igor >>> >>>> Lois >>>> >>>>> >>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan >>>>> > wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> I know you have two reviews for this but could you hold off >>>>>> committing until I or Karen Kinnear have a chance to review. We >>>>>> both worked in this area a lot to support default methods in JDK >>>>>> 8. Also, have you run the >>>>>> hotspot/test/runtime/SelectionResolution tests on this? >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>>> >>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>> When invoking private interface methods with invokeinterface we >>>>>>> throw ICCE. The check for that happens in the runtime part of >>>>>>> the resolution, however, doing it at linktime seems like a >>>>>>> better place, since the check doesn't depend on the receiver >>>>>>> type. It also allows compiler interfaces that rely on linktime >>>>>>> resolution to detect inconsistencies during parsing (see >>>>>>> ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() >>>>>>> (JVMCI) that are affected). >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> igor >> > From coleen.phillimore at oracle.com Tue Apr 5 20:04:45 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 16:04:45 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <5704192A.3010807@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <570417E6.60107@oracle.com> <5704192A.3010807@oracle.com> Message-ID: <57041A5D.4040909@oracle.com> On 4/5/16 3:59 PM, Coleen Phillimore wrote: > > > On 4/5/16 3:54 PM, Lois Foltan wrote: >> >> On 4/5/2016 1:56 PM, Igor Veresov wrote: >>> >>>> On Apr 5, 2016, at 10:44 AM, Igor Veresov >>> > wrote: >>>> >>>>> >>>>> On Apr 5, 2016, at 10:34 AM, Lois Foltan >>>> > wrote: >>>>> >>>>> >>>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>>> Hi Lois, >>>>>> >>>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>>> >>>>>> igor >>>>> Hi Igor, >>>>> >>>>> Thanks for waiting on this. A couple of comments: >>>>> >>>>> - Section 6.5 Instructions for invokeinterface does indicate that >>>>> a "Linking Exceptions" the VM can throw an ICCE if the resolved >>>>> method is static or private. So I think moving this exception >>>>> from runtime to linktime is okay. >>>>> >>>>> - I'm concerned about the change on line #998, #1030, #1316. I >>>>> don't think you are necessarily guaranteed to have the bytecodes >>>>> that you are now passing to resolve_interface_method. For >>>>> example, line #998 within linktime_resolve_static_method, you may >>>>> not have an invokestatic here, you may have another invoke* >>>>> bytecode trying to invoke a static interface method. Passing in >>>>> Bytecodes::_invokestatic seems wrong, because even if the resolved >>>>> method is static, "nostatics" was set to false. >>>>> >>>> >>>> I looked at the call graphs of these guys and >>>> linktime_resolve_X_method() methods actually seem to only called >>>> within invokeX contexts. But may be I missed something. Can you >>>> give an example of a path that may cause, say, >>>> linktime_resolve_static_method() be invoked for non-invokestatic >>>> instruction? >>> >>> Actually, the easier way to think about it, would be: The answer >>> returned by resolve_interface_method() is result of a method >>> resolution in the interface class ?as if? it were invoked by the >>> given bytecode instruction. It of course doesn?t not mean that the >>> invocation is really a result of the said instruction. The context >>> is. As you may see the logic around ?nostatic? did not change and >>> the logic around resolve_interface_method() being called within the >>> invokeinterface context is what we want it to be. >>> >>> The same effect could have been achieved by adding another bool >>> argument to resolve_interface_method() to indicate a question within >>> the invokeinterface context. But passing a bytecode makes it an >>> easier to read code. >> >> Okay, I saw Tom's reply as well to my comments and I reviewed all the >> call paths. I think the change is okay. I kind of wish that the >> original bytecode was stored in the LinkInfo structure so that we >> could just reference the actual bytecode used and make decisions >> based on that instead of the parameter approach, but that maybe a RFE >> to investigate later. > > There's a change coming that does store the original bytecode for bug > https://bugs.openjdk.java.net/browse/JDK-8145148 No, sorry, this change passes the 'tag'. nvm. Coleen > > Just waiting for some test changes. > > Coleen > >> Lois >> >>> >>> igor >>> >>>> >>>>> Just curious did you also run the testbase default methods tests? >>>> >>>> Yes, within the context of a closed project. That?s actually what >>>> made these changes necessary. >>>> >>>> igor >>>> >>>>> Lois >>>>> >>>>>> >>>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan >>>>>> > wrote: >>>>>>> >>>>>>> Hi Igor, >>>>>>> >>>>>>> I know you have two reviews for this but could you hold off >>>>>>> committing until I or Karen Kinnear have a chance to review. We >>>>>>> both worked in this area a lot to support default methods in JDK >>>>>>> 8. Also, have you run the >>>>>>> hotspot/test/runtime/SelectionResolution tests on this? >>>>>>> >>>>>>> Thanks, >>>>>>> Lois >>>>>>> >>>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>>> When invoking private interface methods with invokeinterface we >>>>>>>> throw ICCE. The check for that happens in the runtime part of >>>>>>>> the resolution, however, doing it at linktime seems like a >>>>>>>> better place, since the check doesn't depend on the receiver >>>>>>>> type. It also allows compiler interfaces that rely on linktime >>>>>>>> resolution to detect inconsistencies during parsing (see >>>>>>>> ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() >>>>>>>> (JVMCI) that are affected). >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> igor >>> >> > From coleen.phillimore at oracle.com Tue Apr 5 20:09:38 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 5 Apr 2016 16:09:38 -0400 Subject: RFR(XS) 8152846: Creation of ModuleEntryTable Investigate Need For OrderAccess::storestore() In-Reply-To: <5703FB65.7060504@oracle.com> References: <5703FB65.7060504@oracle.com> Message-ID: <57041B82.5090701@oracle.com> Looks good! Coleen On 4/5/16 1:52 PM, harold seigel wrote: > Hi, > > Please review this small change to fix bug 8152846. > > This change removes an unneeded OrderAccess::storestore() call. > > Webrev: http://javaweb.us.oracle.com/~hseigel/webrev/bug_8152846/ > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152846 > > The fix was tested with JCK API, Lang, and VM tests, the UTE > non-colocated quick tests, and the hotspot, JDK vm, java/io, > java/lang, java/util, and java/security tests. Testing with UTE > colocated tests is in progress. > > Thanks, Harold From karen.kinnear at oracle.com Tue Apr 5 20:17:36 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 5 Apr 2016 16:17:36 -0400 Subject: RFR(XS) 8152846: Creation of ModuleEntryTable Investigate Need For OrderAccess::storestore() In-Reply-To: <57041B82.5090701@oracle.com> References: <5703FB65.7060504@oracle.com> <57041B82.5090701@oracle.com> Message-ID: <3A06B2FD-D863-45C3-AEA6-B4AC657A33E2@oracle.com> Harold, Looks good. Thank you. Karen > On Apr 5, 2016, at 4:09 PM, Coleen Phillimore wrote: > > Looks good! > Coleen > > On 4/5/16 1:52 PM, harold seigel wrote: >> Hi, >> >> Please review this small change to fix bug 8152846. >> >> This change removes an unneeded OrderAccess::storestore() call. >> >> Webrev: http://javaweb.us.oracle.com/~hseigel/webrev/bug_8152846/ >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152846 >> >> The fix was tested with JCK API, Lang, and VM tests, the UTE non-colocated quick tests, and the hotspot, JDK vm, java/io, java/lang, java/util, and java/security tests. Testing with UTE colocated tests is in progress. >> >> Thanks, Harold > From harold.seigel at oracle.com Tue Apr 5 20:19:12 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 5 Apr 2016 16:19:12 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5703FD3B.10307@oracle.com> References: <5703FD3B.10307@oracle.com> Message-ID: <57041DC0.1030709@oracle.com> Hi Rachel, Does hotspot/test/runtime/CompressedOops/UseCompressedOops.java also need to change? private static OutputAnalyzer testCompressedOops(ArrayList flags1, String... flags2) throws Exception { ArrayList args = new ArrayList<>(); // Always run with these three: args.add("-XX:+UnlockDiagnosticVMOptions"); args.add("-XX:+PrintCompressedOopsMode"); Also, I think -XX:+UnlockDiagnosticVMOptions can be removed from this test and from CompressedClassPointers.java. Thanks, Harold On 4/5/2016 2:00 PM, Rachel Protacio wrote: > Hello, > > Please review this change, converting -XX:+PrintCompressedOopsMode to > -Xlog:gc+heap. The existing diagnostic flag has been aliased to the > info level of this tagset (for the "Heap address" message that for > example appears in the hs_err file), and there are both debug and > trace levels of logging available as well, as per our established > schema for assigning levels. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ > > Passes JPRT and RBT quick/non-colo tests. > > Thanks! > Rachel From harold.seigel at oracle.com Tue Apr 5 20:20:34 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 5 Apr 2016 16:20:34 -0400 Subject: RFR(XS) 8152846: Creation of ModuleEntryTable Investigate Need For OrderAccess::storestore() In-Reply-To: <3A06B2FD-D863-45C3-AEA6-B4AC657A33E2@oracle.com> References: <5703FB65.7060504@oracle.com> <57041B82.5090701@oracle.com> <3A06B2FD-D863-45C3-AEA6-B4AC657A33E2@oracle.com> Message-ID: <57041E12.5010104@oracle.com> Thanks Coleen and Karen, for the reviews. Harold On 4/5/2016 4:17 PM, Karen Kinnear wrote: > Harold, > > Looks good. Thank you. > > Karen > >> On Apr 5, 2016, at 4:09 PM, Coleen Phillimore wrote: >> >> Looks good! >> Coleen >> >> On 4/5/16 1:52 PM, harold seigel wrote: >>> Hi, >>> >>> Please review this small change to fix bug 8152846. >>> >>> This change removes an unneeded OrderAccess::storestore() call. >>> >>> Webrev: http://javaweb.us.oracle.com/~hseigel/webrev/bug_8152846/ >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152846 >>> >>> The fix was tested with JCK API, Lang, and VM tests, the UTE non-colocated quick tests, and the hotspot, JDK vm, java/io, java/lang, java/util, and java/security tests. Testing with UTE colocated tests is in progress. >>> >>> Thanks, Harold From jiangli.zhou at oracle.com Tue Apr 5 20:29:03 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 5 Apr 2016 13:29:03 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <5703FBB2.2040205@oracle.com> References: <5702D7A6.1090601@oracle.com> <5FF42E5E-8C70-4E83-8F10-271737A55577@oracle.com> <5703FBB2.2040205@oracle.com> Message-ID: Hi Calvin, > On Apr 5, 2016, at 10:53 AM, Calvin Cheung wrote: > > > > On 4/5/16, 10:44 AM, Jiangli Zhou wrote: >> >> Hi Calvin, >> >> Have you thought about using strcasecmp()? The globalDefinitions_visCPP.hpp defines strcasecmp to _stricmp. So compiler dependency is not an issue. We have existing code that uses strcasecmp() for case insensitive comparison. > I don't think it will work in this situation. It is because the manifest buffer contains all the jar manifest entries, not just the "Multi-Release" entry. In other words, "Multi-Release" isn't at the beginning of the string. Ok. There is strcasestr(), but it?s a nonstandard extension. I couldn?t find a Windows equivalent for that. Iterating the string to covert each char to lower case is slow although it?s only used in CDS dump time. To make it more efficient, you could add a new field, ?u1 is_multi_versioned' in ClassPathZipEntry to remember the result so you only need to do the case in-senstive strstr once, instead of everytime when ClassPathZipEntry::open_stream() is called. The new field could have three states, ?unknown?, ?yes? and ?no?. If it?s ?unknown?, is_multiple_versioned() opens the manifest, otherwise it can return quickly. Thanks, Jiangli > > thanks, > Calvin >> >> // Non-standard stdlib-like stuff: >> inline int strcasecmp(const char *s1, const char *s2) { return _stricmp(s1,s2); } >> >> Thanks, >> Jiangli >> >>> On Apr 4, 2016, at 2:07 PM, Calvin Cheung > wrote: >>> >>> >>> Please review this small fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8152329 >>> >>> The fix is to convert the buffer containing the jar manifest into lower case before performing strstr. >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ >>> >>> Testing: >>> JPRT -testset hotspot >>> The tests under runtime on the platforms built by JPRT. >>> >>> thanks, >>> Calvin >> From igor.veresov at oracle.com Tue Apr 5 22:08:03 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Apr 2016 15:08:03 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <57041A5D.4040909@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <570417E6.60107@oracle.com> <5704192A.3010807@oracle.com> <57041A5D.4040909@oracle.com> Message-ID: <11AC503F-CF56-4DC4-85EE-728B2D82FC6E@oracle.com> Coleen and Lois, So, ok to push? igor > On Apr 5, 2016, at 1:04 PM, Coleen Phillimore wrote: > > > > On 4/5/16 3:59 PM, Coleen Phillimore wrote: >> >> >> On 4/5/16 3:54 PM, Lois Foltan wrote: >>> >>> On 4/5/2016 1:56 PM, Igor Veresov wrote: >>>> >>>>> On Apr 5, 2016, at 10:44 AM, Igor Veresov > wrote: >>>>> >>>>>> >>>>>> On Apr 5, 2016, at 10:34 AM, Lois Foltan > wrote: >>>>>> >>>>>> >>>>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>>>> Hi Lois, >>>>>>> >>>>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>>>> >>>>>>> igor >>>>>> Hi Igor, >>>>>> >>>>>> Thanks for waiting on this. A couple of comments: >>>>>> >>>>>> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >>>>>> >>>>>> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >>>>>> >>>>> >>>>> I looked at the call graphs of these guys and linktime_resolve_X_method() methods actually seem to only called within invokeX contexts. But may be I missed something. Can you give an example of a path that may cause, say, linktime_resolve_static_method() be invoked for non-invokestatic instruction? >>>> >>>> Actually, the easier way to think about it, would be: The answer returned by resolve_interface_method() is result of a method resolution in the interface class ?as if? it were invoked by the given bytecode instruction. It of course doesn?t not mean that the invocation is really a result of the said instruction. The context is. As you may see the logic around ?nostatic? did not change and the logic around resolve_interface_method() being called within the invokeinterface context is what we want it to be. >>>> >>>> The same effect could have been achieved by adding another bool argument to resolve_interface_method() to indicate a question within the invokeinterface context. But passing a bytecode makes it an easier to read code. >>> >>> Okay, I saw Tom's reply as well to my comments and I reviewed all the call paths. I think the change is okay. I kind of wish that the original bytecode was stored in the LinkInfo structure so that we could just reference the actual bytecode used and make decisions based on that instead of the parameter approach, but that maybe a RFE to investigate later. >> >> There's a change coming that does store the original bytecode for bug https://bugs.openjdk.java.net/browse/JDK-8145148 > > No, sorry, this change passes the 'tag'. nvm. > > Coleen >> >> Just waiting for some test changes. >> >> Coleen >> >>> Lois >>> >>>> >>>> igor >>>> >>>>> >>>>>> Just curious did you also run the testbase default methods tests? >>>>> >>>>> Yes, within the context of a closed project. That?s actually what made these changes necessary. >>>>> >>>>> igor >>>>> >>>>>> Lois >>>>>> >>>>>>> >>>>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan > wrote: >>>>>>>> >>>>>>>> Hi Igor, >>>>>>>> >>>>>>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lois >>>>>>>> >>>>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> igor From lois.foltan at oracle.com Tue Apr 5 22:12:37 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 05 Apr 2016 18:12:37 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <11AC503F-CF56-4DC4-85EE-728B2D82FC6E@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <570417E6.60107@oracle.com> <5704192A.3010807@oracle.com> <57041A5D.4040909@oracle.com> <11AC503F-CF56-4DC4-85EE-728B2D82FC6E@oracle.com> Message-ID: <57043855.1000405@oracle.com> On 4/5/2016 6:08 PM, Igor Veresov wrote: > Coleen and Lois, > > So, ok to push? Yes, for me. Have you addressed all of Karen's concerns as well? Lois > > igor > > >> On Apr 5, 2016, at 1:04 PM, Coleen Phillimore wrote: >> >> >> >> On 4/5/16 3:59 PM, Coleen Phillimore wrote: >>> >>> On 4/5/16 3:54 PM, Lois Foltan wrote: >>>> On 4/5/2016 1:56 PM, Igor Veresov wrote: >>>>>> On Apr 5, 2016, at 10:44 AM, Igor Veresov > wrote: >>>>>> >>>>>>> On Apr 5, 2016, at 10:34 AM, Lois Foltan > wrote: >>>>>>> >>>>>>> >>>>>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>>>>> Hi Lois, >>>>>>>> >>>>>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>>>>> >>>>>>>> igor >>>>>>> Hi Igor, >>>>>>> >>>>>>> Thanks for waiting on this. A couple of comments: >>>>>>> >>>>>>> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >>>>>>> >>>>>>> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >>>>>>> >>>>>> I looked at the call graphs of these guys and linktime_resolve_X_method() methods actually seem to only called within invokeX contexts. But may be I missed something. Can you give an example of a path that may cause, say, linktime_resolve_static_method() be invoked for non-invokestatic instruction? >>>>> Actually, the easier way to think about it, would be: The answer returned by resolve_interface_method() is result of a method resolution in the interface class ?as if? it were invoked by the given bytecode instruction. It of course doesn?t not mean that the invocation is really a result of the said instruction. The context is. As you may see the logic around ?nostatic? did not change and the logic around resolve_interface_method() being called within the invokeinterface context is what we want it to be. >>>>> >>>>> The same effect could have been achieved by adding another bool argument to resolve_interface_method() to indicate a question within the invokeinterface context. But passing a bytecode makes it an easier to read code. >>>> Okay, I saw Tom's reply as well to my comments and I reviewed all the call paths. I think the change is okay. I kind of wish that the original bytecode was stored in the LinkInfo structure so that we could just reference the actual bytecode used and make decisions based on that instead of the parameter approach, but that maybe a RFE to investigate later. >>> There's a change coming that does store the original bytecode for bug https://bugs.openjdk.java.net/browse/JDK-8145148 >> No, sorry, this change passes the 'tag'. nvm. >> >> Coleen >>> Just waiting for some test changes. >>> >>> Coleen >>> >>>> Lois >>>> >>>>> igor >>>>> >>>>>>> Just curious did you also run the testbase default methods tests? >>>>>> Yes, within the context of a closed project. That?s actually what made these changes necessary. >>>>>> >>>>>> igor >>>>>> >>>>>>> Lois >>>>>>> >>>>>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan > wrote: >>>>>>>>> >>>>>>>>> Hi Igor, >>>>>>>>> >>>>>>>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Lois >>>>>>>>> >>>>>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>>>>>>> >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> igor From igor.veresov at oracle.com Tue Apr 5 22:16:48 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Apr 2016 15:16:48 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <57043855.1000405@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <570417E6.60107@oracle.com> <5704192A.3010807@oracle.com> <57041A5D.4040909@oracle.com> <11AC503F-CF56-4DC4-85EE-728B2D82FC6E@oracle.com> <57043855.1000405@oracle.com> Message-ID: > On Apr 5, 2016, at 3:12 PM, Lois Foltan wrote: > > > On 4/5/2016 6:08 PM, Igor Veresov wrote: >> Coleen and Lois, >> >> So, ok to push? > Yes, for me. Have you addressed all of Karen's concerns as well? Right.. Karen, is it alright? igor > Lois > >> >> igor >> >> >>> On Apr 5, 2016, at 1:04 PM, Coleen Phillimore wrote: >>> >>> >>> >>> On 4/5/16 3:59 PM, Coleen Phillimore wrote: >>>> >>>> On 4/5/16 3:54 PM, Lois Foltan wrote: >>>>> On 4/5/2016 1:56 PM, Igor Veresov wrote: >>>>>>> On Apr 5, 2016, at 10:44 AM, Igor Veresov > wrote: >>>>>>> >>>>>>>> On Apr 5, 2016, at 10:34 AM, Lois Foltan > wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>>>>>> Hi Lois, >>>>>>>>> >>>>>>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>>>>>> >>>>>>>>> igor >>>>>>>> Hi Igor, >>>>>>>> >>>>>>>> Thanks for waiting on this. A couple of comments: >>>>>>>> >>>>>>>> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >>>>>>>> >>>>>>>> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >>>>>>>> >>>>>>> I looked at the call graphs of these guys and linktime_resolve_X_method() methods actually seem to only called within invokeX contexts. But may be I missed something. Can you give an example of a path that may cause, say, linktime_resolve_static_method() be invoked for non-invokestatic instruction? >>>>>> Actually, the easier way to think about it, would be: The answer returned by resolve_interface_method() is result of a method resolution in the interface class ?as if? it were invoked by the given bytecode instruction. It of course doesn?t not mean that the invocation is really a result of the said instruction. The context is. As you may see the logic around ?nostatic? did not change and the logic around resolve_interface_method() being called within the invokeinterface context is what we want it to be. >>>>>> >>>>>> The same effect could have been achieved by adding another bool argument to resolve_interface_method() to indicate a question within the invokeinterface context. But passing a bytecode makes it an easier to read code. >>>>> Okay, I saw Tom's reply as well to my comments and I reviewed all the call paths. I think the change is okay. I kind of wish that the original bytecode was stored in the LinkInfo structure so that we could just reference the actual bytecode used and make decisions based on that instead of the parameter approach, but that maybe a RFE to investigate later. >>>> There's a change coming that does store the original bytecode for bug https://bugs.openjdk.java.net/browse/JDK-8145148 >>> No, sorry, this change passes the 'tag'. nvm. >>> >>> Coleen >>>> Just waiting for some test changes. >>>> >>>> Coleen >>>> >>>>> Lois >>>>> >>>>>> igor >>>>>> >>>>>>>> Just curious did you also run the testbase default methods tests? >>>>>>> Yes, within the context of a closed project. That?s actually what made these changes necessary. >>>>>>> >>>>>>> igor >>>>>>> >>>>>>>> Lois >>>>>>>> >>>>>>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan > wrote: >>>>>>>>>> >>>>>>>>>> Hi Igor, >>>>>>>>>> >>>>>>>>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Lois >>>>>>>>>> >>>>>>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>>>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>>>>>>>> >>>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> igor > From karen.kinnear at oracle.com Tue Apr 5 22:33:17 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 5 Apr 2016 18:33:17 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <1EAD5675-6903-4C48-A778-05A99F591D1C@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <1EAD5675-6903-4C48-A778-05A99F591D1C@oracle.com> Message-ID: <4C106849-365D-42E8-B4A5-ADC7297BEA1B@oracle.com> Igor, Do you run all the tests with -Xcomp or whatever flag ensures you test JVMCI vs. interpreter for instance? If so, I am ok with checking this in - further notes below. > On Apr 5, 2016, at 3:43 PM, Igor Veresov wrote: > > >> On Apr 5, 2016, at 12:04 PM, Karen Kinnear > wrote: >> >> I am in agreement with Lois that the JVMS looks good with moving the exception. > > Thanks! >> >> With the checking I have done so far, I believe that linktime_resolve_static_method is only called with an invoke static - but after my next >> meeting I will check one more time. It might be worth adding a comment. > > Ok, I added a comment to resolve_interface_method(): http://cr.openjdk.java.net/~iveresov/8153115/webrev.01/ > Again, the bytecode argument here indicates the context, not the actual bytecode. Of course, for example, the method may be invoked with a method handle. > >> >> My concern is specific to the code in jvmciCompilerToVM.cpp there is code called resolveMethod that checks >> if holder_klass->is_interface -> LR::linktime_resolve_interface_method_or_null. >> > > That code needs fixing as well. We have the following issue filed for that: https://bugs.openjdk.java.net/browse/JDK-8152903 > In the nutshell, resolveMethod() sort of emulates what happens during a virtual call (it is only called for invokevirtual and invokeinterface). It should do both linktime and runtime resolutions. The JVMCI version should work the same way as the CI version (see ciMethod::resolve_invoke() in ciMethod.cpp). Hmmm - I see the ciMethod::resolve_invoke has the same problem that I just called out, so making the JVMCI one match the CI version makes me wonder if we have sufficient test cases. But I hear that you would like to address that as a followup. That is ok with me - I will add a note to the bug. Also: I see a ciMethod::check_call that has a comment - IT appears to fail when applied to an invoke interface call site. FIXME: Remove this method and resolve_method_statically; refactor to use the other LinkResolver entry points. Could you possibly file a bug on this one? What I am seeing is a conditional for invoke static vs. invoke virtual that does not take the subtleties of invoke interface and invoke special into account. > > igor > >> I think we need to study this one more closely - I suspect that you need a set of detailed tests that cover the >> corner cases here. I don?t know the code paths, but I would suggest following this approach of passing in the byte code, >> so that you get the correct behavior depending on the requesting byte code. >> >> I am not sure what resolveMethod is doing here - since you seem to already have the resolved method and the receiver - so >> I could use help studying this a bit more to understand if this really is resolution or is really selection. >> >> thanks, >> Karen >> >>> On Apr 5, 2016, at 1:34 PM, Lois Foltan > wrote: >>> >>> >>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>> Hi Lois, >>>> >>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>> >>>> igor >>> Hi Igor, >>> >>> Thanks for waiting on this. A couple of comments: >>> >>> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >>> >>> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >>> >>> Just curious did you also run the testbase default methods tests? >>> Lois >>> >>>> >>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>>> >>>>> Thanks, >>>>> Lois >>>>> >>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> igor >>> >> > From igor.veresov at oracle.com Tue Apr 5 23:22:37 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Apr 2016 16:22:37 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <4C106849-365D-42E8-B4A5-ADC7297BEA1B@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <1EAD5675-6903-4C48-A778-05A99F591D1C@oracle.com> <4C106849-365D-42E8-B4A5-ADC7297BEA1B@oracle.com> Message-ID: <9F99FE47-E84D-4C4A-B854-F6432D10BC6C@oracle.com> > On Apr 5, 2016, at 3:33 PM, Karen Kinnear wrote: > > Igor, > > Do you run all the tests with -Xcomp or whatever flag ensures you test JVMCI vs. interpreter > for instance? Yes, I ran our RBT round of testing that does that -Xcomp and -Xmixed. > > If so, I am ok with checking this in - further notes below. > >> On Apr 5, 2016, at 3:43 PM, Igor Veresov > wrote: >> >> >>> On Apr 5, 2016, at 12:04 PM, Karen Kinnear > wrote: >>> >>> I am in agreement with Lois that the JVMS looks good with moving the exception. >> >> Thanks! >>> >>> With the checking I have done so far, I believe that linktime_resolve_static_method is only called with an invoke static - but after my next >>> meeting I will check one more time. It might be worth adding a comment. >> >> Ok, I added a comment to resolve_interface_method(): http://cr.openjdk.java.net/~iveresov/8153115/webrev.01/ >> Again, the bytecode argument here indicates the context, not the actual bytecode. Of course, for example, the method may be invoked with a method handle. >> >>> >>> My concern is specific to the code in jvmciCompilerToVM.cpp there is code called resolveMethod that checks >>> if holder_klass->is_interface -> LR::linktime_resolve_interface_method_or_null. >>> >> >> That code needs fixing as well. We have the following issue filed for that: https://bugs.openjdk.java.net/browse/JDK-8152903 >> In the nutshell, resolveMethod() sort of emulates what happens during a virtual call (it is only called for invokevirtual and invokeinterface). It should do both linktime and runtime resolutions. The JVMCI version should work the same way as the CI version (see ciMethod::resolve_invoke() in ciMethod.cpp). > > Hmmm - I see the ciMethod::resolve_invoke has the same problem that I just called out, so making the JVMCI one match > the CI version makes me wonder if we have sufficient test cases. But I hear that you would like to address that as a followup. > That is ok with me - I will add a note to the bug. Could you please explain what is the problem again? Are you concerned that the bytecode is not passed to resolve_invoke, so we may call linktime_resolve_interface_or_null, for an interface holder when in reality it was an invokevirtual instruction and vice versa? > > Also: I see a ciMethod::check_call that has a comment - > IT appears to fail when applied to an invoke interface call site. > FIXME: Remove this method and resolve_method_statically; refactor to use the other LinkResolver entry points. > This comment is odd. I don?t see why it would fail for invokeinterface. The code certainly seems to account for it. May be the comment is wrong? Any ideas? igor > Could you possibly file a bug on this one? What I am seeing is a conditional for invoke static vs. invoke virtual that does not take > the subtleties of invoke interface and invoke special into account. >> >> igor >> >>> I think we need to study this one more closely - I suspect that you need a set of detailed tests that cover the >>> corner cases here. I don?t know the code paths, but I would suggest following this approach of passing in the byte code, >>> so that you get the correct behavior depending on the requesting byte code. >>> >>> I am not sure what resolveMethod is doing here - since you seem to already have the resolved method and the receiver - so >>> I could use help studying this a bit more to understand if this really is resolution or is really selection. >>> >>> thanks, >>> Karen >>> >>>> On Apr 5, 2016, at 1:34 PM, Lois Foltan > wrote: >>>> >>>> >>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>> Hi Lois, >>>>> >>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>> >>>>> igor >>>> Hi Igor, >>>> >>>> Thanks for waiting on this. A couple of comments: >>>> >>>> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >>>> >>>> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >>>> >>>> Just curious did you also run the testbase default methods tests? >>>> Lois >>>> >>>>> >>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan > wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>>>> >>>>>> Thanks, >>>>>> Lois >>>>>> >>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> igor From mandy.chung at oracle.com Tue Apr 5 23:33:00 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 Apr 2016 16:33:00 -0700 Subject: RFR [9] 8153498: Update the PostVMInitHook mechanism to use an internal package in the base module In-Reply-To: References: Message-ID: <55EB013A-6F42-424F-BED7-490BF635BB70@oracle.com> > On Apr 5, 2016, at 2:51 AM, Chris Hegarty wrote: > > sun.misc.PostVMInitHook::run is called by the VM once its initialization is > complete, when jdk_version_info.post_vm_init_hook_enabled bit is true. > Since sun.misc will be moved out of the base module, the VM should > look for the PostVMInitHook in a more suitable place, say jdk.internal.vm. > > http://cr.openjdk.java.net/~chegar/8153498/ Looks okay. Minor nit: would it be better to rename the vmSymbol to match the package name: vmSymbols::jdk_internal_vm_PostVMInitHook() Mandy From calvin.cheung at oracle.com Wed Apr 6 00:13:16 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 05 Apr 2016 17:13:16 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: References: <5702D7A6.1090601@oracle.com> <5FF42E5E-8C70-4E83-8F10-271737A55577@oracle.com> <5703FBB2.2040205@oracle.com> Message-ID: <5704549C.1080508@oracle.com> On 4/5/16, 1:29 PM, Jiangli Zhou wrote: > Hi Calvin, > >> On Apr 5, 2016, at 10:53 AM, Calvin Cheung > > wrote: >> >> >> >> On 4/5/16, 10:44 AM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>> Have you thought about using strcasecmp()? The >>> globalDefinitions_visCPP.hpp defines strcasecmp to _stricmp. So >>> compiler dependency is not an issue. We have existing code that uses >>> strcasecmp() for case insensitive comparison. >> I don't think it will work in this situation. It is because the >> manifest buffer contains all the jar manifest entries, not just the >> "Multi-Release" entry. In other words, "Multi-Release" isn't at the >> beginning of the string. > > Ok. There is strcasestr(), but it?s a nonstandard extension. I > couldn?t find a Windows equivalent for that. Iterating the string to > covert each char to lower case is slow although it?s only used in CDS > dump time. To make it more efficient, you could add a new field, ?u1 > is_multi_versioned' in ClassPathZipEntry to remember the result so you > only need to do the case in-senstive strstr once, instead of everytime > when ClassPathZipEntry::open_stream() is called. The new field could > have three states, ?unknown?, ?yes? and ?no?. If it?s ?unknown?, > is_multiple_versioned() opens the manifest, otherwise it can return > quickly. I've an updated webrev for the above change. http://cr.openjdk.java.net/~ccheung/8152329/webrev.02/ Some testing in progress. thanks, Calvin > > Thanks, > Jiangli > > >> >> thanks, >> Calvin >>> >>> // Non-standard stdlib-like stuff: >>> inline int strcasecmp(const char *s1, const char *s2) { return >>> _stricmp(s1,s2); } >>> >>> Thanks, >>> Jiangli >>>> On Apr 4, 2016, at 2:07 PM, Calvin Cheung >>> > wrote: >>>> >>>> >>>> Please review this small fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8152329 >>>> >>>> The fix is to convert the buffer containing the jar manifest into >>>> lower case before performing strstr. >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ >>>> >>>> Testing: >>>> JPRT -testset hotspot >>>> The tests under runtime on the platforms built by JPRT. >>>> >>>> thanks, >>>> Calvin >>> > From cheleswer.sahu at oracle.com Wed Apr 6 06:15:30 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Tue, 5 Apr 2016 23:15:30 -0700 (PDT) Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" In-Reply-To: <7b9114bd-14d7-4a2f-8b5f-46fec1c90428@default> References: <7b9114bd-14d7-4a2f-8b5f-46fec1c90428@default> Message-ID: <8f62ae83-fa8b-4423-bbc5-57343760afe3@default> Hi, This fix is waiting for review, can somebody please review this change. Regards, Cheleswer From: Cheleswer Sahu Sent: Friday, April 01, 2016 6:01 PM To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Cc: Mattis Castegren Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8054326. Webrev Link: http://cr.openjdk.java.net/~csahu/8054326/ Bug Brief: In output of remset statistics "Max" is printing as 0k, which is confusing for user. Problem Identified : "Max" value is rounded to KB, which result in 0k, if the value is less than 1024B. Solution Proposed: If the value for "Max" is less than 1 KB (1024 B), print the value in bytes (i.e. 1023B.) else print the value in KB. Regards, Cheleswer From marcus.larsson at oracle.com Wed Apr 6 06:46:08 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 6 Apr 2016 08:46:08 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. Message-ID: <5704B0B0.4010404@oracle.com> Hi, Please review the following patch to add a warning for when tag selections in -Xlog or VM.log don't match any tag sets used in the VM. Webrev: http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8150894 Testing: Internal VM tests with RBT Thanks, Marcus From thomas.stuefe at gmail.com Wed Apr 6 07:09:37 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Apr 2016 09:09:37 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <56FE3514.5050104@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> Message-ID: Hi Marcus, sorry for the delay. On Fri, Apr 1, 2016 at 10:45 AM, Marcus Larsson wrote: > Hi, > > On 03/31/2016 08:08 PM, Max Ockner wrote: > > (Replies in line) > > On 3/30/2016 9:31 AM, Thomas St?fe wrote: > > Hi Max, > > Disclaimer: not a (R)eviewer. > > Do we really need a list of all tags and all decorators? > > Just going by what we currently put in the hs_err file, I think this may > be the first "Do we really need" we've ever asked for this type of change. > > All joking aside, I think it is a good idea to direct users toward proper > UL usage whenever we have a chance. > > Also: I assume what you print is the Log state as it is at the time the > hs-err file is printed. If logging was enabled/changed during lifetime of > the VM, e.g. with jcmd, would it be possible to see that? At least a > warning if logging was not enabled from the start on. > > Would it be possible? Yes, but I think this would require a framework > change. It does not look like any marks are made when the LogConfiguration > changes during runtime, and we would need to record that in order to know > what to print when we dump into hs_err. > > > Yes, this would required the framework to keep some sort of log of > configuration changes. Is there value in knowing that the log configuration > changed since startup? > > I think the only reason to print the log configuration is that we can find the associated log output and interpret it. I guess most supporters would assume that the log configuration in the hs-err file was active the whole process life. If it was not, the supporter may interpret missing output somehow ("I did not see my trace line so it did not happen"). So I think it makes sense to write out a flag if the log configuration was active the whole process life or did change. I think nothing more complicated than that is needed. Kind regards, Thomas > > Thanks, > Max > > Kind Regards, Thomas > > > > > On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner wrote: > >> Hello, >> Please review another Unified Logging change. They are almost done, and >> we are serious this time. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >> > > LogConfiguration::describe() takes the ConfigurationLock, which might be > problematic for the error handler. I suppose the error handler could > potentially deadlock if its thread already holds the lock. Unsure how to > resolve this, because skipping to take the lock means that we might crash > due to another thread changing the configuration as we read it. > > Thanks, > Marcus > > >> The logging configuration is now printed in each hs_err file. The output >> is the same as you would see from -Xlog:logging=trace and it is obtained >> from LogConfiguration::describe(). >> >> Below is a sample of the hs_err contents. The Logging info is printed >> after VM Arguments and Whitebox, and before Environment Variables. >> >> VM Arguments: >> java_command: Kaboom >> java_class_path (initial): . >> Launcher Type: SUN_STANDARD >> >> Logging: >> Available log levels: off, trace, debug, info, warning, error >> Available log decorators: time (t), uptime (u), timemillis (tm), >> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), pid >> (p), tid (ti), level (l), tags (tg) >> Available log tags: alloc, age, barrier, biasedlocking, bot, census, >> classhisto, classresolve, classinit, classload, classloaderdata, >> classunload, classpath, compaction, cpu, cset, defaultmethods, ergo, >> exceptions, exit, freelist, gc, heap, humongous, ihop, itables, jni, >> liveness, logging, marking, metaspace, modules, monitorinflation, os, >> phases, plab, promotion, preorder, protectiondomain, ref, refine, region, >> remset, safepoint, safepointcleanup, scavenge, scrub, stacktrace, start, >> startuptime, state, stats, stringdedup, stringtable, survivor, sweep, task, >> thread, tlab, time, verboseverification, verify, vmoperation, vtables >> Log output configuration: >> #0: stdout all=off uptime,level,tags, >> #1: stderr all=warning uptime,level,tags, >> >> Environment Variables: >> >> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >> >> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >> SHELL=/bin/bash >> OS=Linux >> >> > > > From thomas.stuefe at gmail.com Wed Apr 6 07:11:21 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Apr 2016 09:11:21 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <57041515.4020206@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57041515.4020206@oracle.com> Message-ID: Hi Coleen, On Tue, Apr 5, 2016 at 9:42 PM, Coleen Phillimore < coleen.phillimore at oracle.com> wrote: > > > On 4/1/16 4:45 AM, Marcus Larsson wrote: > >> Hi, >> >> On 03/31/2016 08:08 PM, Max Ockner wrote: >> >>> (Replies in line) >>> >>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>> >>>> Hi Max, >>>> >>>> Disclaimer: not a (R)eviewer. >>>> >>>> Do we really need a list of all tags and all decorators? >>>> >>>> Just going by what we currently put in the hs_err file, I think this >>> may be the first "Do we really need" we've ever asked for this type of >>> change. >>> >>> All joking aside, I think it is a good idea to direct users toward >>> proper UL usage whenever we have a chance. >>> >>> Also: I assume what you print is the Log state as it is at the time the >>>> hs-err file is printed. If logging was enabled/changed during lifetime of >>>> the VM, e.g. with jcmd, would it be possible to see that? At least a >>>> warning if logging was not enabled from the start on. >>>> >>>> Would it be possible? Yes, but I think this would require a framework >>> change. It does not look like any marks are made when the LogConfiguration >>> changes during runtime, and we would need to record that in order to know >>> what to print when we dump into hs_err. >>> >> >> Yes, this would required the framework to keep some sort of log of >> configuration changes. Is there value in knowing that the log configuration >> changed since startup? >> >> > Actually, there's an Event logger that saves events and then we print the > last 'n' events out in the hs_err file. If you think this would be useful, > please file an RFE. > > Not sure this is the best mechanism: 1) the event gets rolled out if it is too old, and 2) it would make sense to print this information together with the log configuration, not in the middle of many other events. This is just my opinion, though. Kind Regards, Thomas > Thanks, > Coleen > > > >>> Thanks, >>> Max >>> >>>> Kind Regards, Thomas >>>> >>>> >>>> >>>> >>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>> > wrote: >>>> >>>> Hello, >>>> Please review another Unified Logging change. They are almost >>>> done, and we are serious this time. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>> >>>> >>>> >> LogConfiguration::describe() takes the ConfigurationLock, which might be >> problematic for the error handler. I suppose the error handler could >> potentially deadlock if its thread already holds the lock. Unsure how to >> resolve this, because skipping to take the lock means that we might crash >> due to another thread changing the configuration as we read it. >> >> Thanks, >> Marcus >> >> >>>> The logging configuration is now printed in each hs_err file. The >>>> output is the same as you would see from -Xlog:logging=trace and >>>> it is obtained from LogConfiguration::describe(). >>>> >>>> Below is a sample of the hs_err contents. The Logging info is >>>> printed after VM Arguments and Whitebox, and before Environment >>>> Variables. >>>> >>>> VM Arguments: >>>> java_command: Kaboom >>>> java_class_path (initial): . >>>> Launcher Type: SUN_STANDARD >>>> >>>> Logging: >>>> Available log levels: off, trace, debug, info, warning, error >>>> Available log decorators: time (t), uptime (u), timemillis (tm), >>>> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname >>>> (hn), pid (p), tid (ti), level (l), tags (tg) >>>> Available log tags: alloc, age, barrier, biasedlocking, bot, >>>> census, classhisto, classresolve, classinit, classload, >>>> classloaderdata, classunload, classpath, compaction, cpu, cset, >>>> defaultmethods, ergo, exceptions, exit, freelist, gc, heap, >>>> humongous, ihop, itables, jni, liveness, logging, marking, >>>> metaspace, modules, monitorinflation, os, phases, plab, >>>> promotion, preorder, protectiondomain, ref, refine, region, >>>> remset, safepoint, safepointcleanup, scavenge, scrub, stacktrace, >>>> start, startuptime, state, stats, stringdedup, stringtable, >>>> survivor, sweep, task, thread, tlab, time, verboseverification, >>>> verify, vmoperation, vtables >>>> Log output configuration: >>>> #0: stdout all=off uptime,level,tags, >>>> #1: stderr all=warning uptime,level,tags, >>>> >>>> Environment Variables: >>>> >>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>> >>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>> SHELL=/bin/bash >>>> OS=Linux >>>> >>>> >>>> >>> >> > From mikael.gerdin at oracle.com Wed Apr 6 11:09:19 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 6 Apr 2016 13:09:19 +0200 Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" In-Reply-To: <8f62ae83-fa8b-4423-bbc5-57343760afe3@default> References: <7b9114bd-14d7-4a2f-8b5f-46fec1c90428@default> <8f62ae83-fa8b-4423-bbc5-57343760afe3@default> Message-ID: <5704EE5F.1000109@oracle.com> Hi, this is GC code and the rewview should go to hotspot-gc-dev. I'm redirecting this mail there. /Mikael On 2016-04-06 08:15, Cheleswer Sahu wrote: > Hi, > > > > This fix is waiting for review, can somebody please review this change. > > > > Regards, > > Cheleswer > > > > From: Cheleswer Sahu > Sent: Friday, April 01, 2016 6:01 PM > To: hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Cc: Mattis Castegren > Subject: RFR[9u-dev]: 8054326: Confusing message in "Current rem set statistics" > > > > Hi, > > > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8054326. > > > > Webrev Link: http://cr.openjdk.java.net/~csahu/8054326/ > > > > Bug Brief: In output of remset statistics "Max" is printing as 0k, which is confusing for user. > > > > Problem Identified : "Max" value is rounded to KB, which result in 0k, if the value is less than 1024B. > > > > Solution Proposed: If the value for "Max" is less than 1 KB (1024 B), print the value in bytes (i.e. 1023B.) else > > print the value in KB. > > > > > > > > Regards, > > Cheleswer > > > From dmitry.samersoff at oracle.com Wed Apr 6 11:21:33 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 6 Apr 2016 14:21:33 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: Message-ID: <5704F13D.1050400@oracle.com> Cheleswer, Some times ago I invented LingeredAppWithDeadlock for tests like this one. Please take a look at: .../jdk/test/sun/tools/jstack/DeadlockDetectionTest.java .../hotspot/test/serviceability/sa/DeadlockDetectionTest.java -Dmitry On 2016-04-05 13:23, Cheleswer Sahu wrote: > Hi, > > > > Please review the code changes for > https://bugs.openjdk.java.net/browse/JDK-8153319. > > > > Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ > > > > > > Bug Brief: Test is failing on some platforms. > > > > Problem Identified: Newly created child thread (NamedThread) is > finished its execution before main thread calls ?jstack?, which result > in test failure. > > > > Solution Proposed: Set the child thread in sleep state for forever and > make sure that ?jstack ? tool always gets executed after ? NamedThread? > is started. > > > > > > Regards, > > Cheleswer > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From stefan.johansson at oracle.com Wed Apr 6 11:33:18 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 6 Apr 2016 13:33:18 +0200 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5703FD3B.10307@oracle.com> References: <5703FD3B.10307@oracle.com> Message-ID: <5704F3FE.4030906@oracle.com> Hi Rachel, On 2016-04-05 20:00, Rachel Protacio wrote: > Hello, > > Please review this change, converting -XX:+PrintCompressedOopsMode to > -Xlog:gc+heap. The existing diagnostic flag has been aliased to the > info level of this tagset (for the "Heap address" message that for > example appears in the hs_err file), and there are both debug and > trace levels of logging available as well, as per our established > schema for assigning levels. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ > The change looks good in general but I see that some log messages have a dot in the end. I know you're just moving this over to UL but would you mind removing these dots to have the same style as other (gc, heap) messages. Thanks, Stefan > Passes JPRT and RBT quick/non-colo tests. > > Thanks! > Rachel From thomas.stuefe at gmail.com Wed Apr 6 12:26:14 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Apr 2016 14:26:14 +0200 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5703FD3B.10307@oracle.com> References: <5703FD3B.10307@oracle.com> Message-ID: Hi Rachel, one question, does this change the output for -XX:PrintCompressedOopsMode much? It seems to be wired now to "LOG_TAGS(gc, heap)", which prints much more than just heap reservation for the compressed oops mode. Would it be possible to add a "coops" tag or similar to isolate this output? The reason I ask is that we used this flag extensively when optimizing heap reservation on AIX for compressed oops, and may want to continue using it or an alternative which gives the same output. Kind Regards, Thomas On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio wrote: > Hello, > > Please review this change, converting -XX:+PrintCompressedOopsMode to > -Xlog:gc+heap. The existing diagnostic flag has been aliased to the info > level of this tagset (for the "Heap address" message that for example > appears in the hs_err file), and there are both debug and trace levels of > logging available as well, as per our established schema for assigning > levels. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ > > Passes JPRT and RBT quick/non-colo tests. > > Thanks! > Rachel > From erik.osterlund at oracle.com Wed Apr 6 14:14:30 2016 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 6 Apr 2016 16:14:30 +0200 Subject: RFR(M): 8152995: Solaris os::available_memory() doesn't do what we think it does In-Reply-To: <5705187E.3020000@oracle.com> References: <5705187E.3020000@oracle.com> Message-ID: <570519C6.3060201@oracle.com> Looping in runtime. Thanks, /Erik On 2016-04-06 16:09, Erik ?sterlund wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152995 > CR: http://cr.openjdk.java.net/~eosterlund/8152995/webrev.00/ > > On Solaris, the os::available_memory() function is currently > calculated with sysconf(_SC_AVPHYS_PAGES). > > Unfortunately this does not match intended semantics. The intended > semantics is to return how much memory can be allocated by mmap into > physical memory. But, what _SC_AVPHYS_PAGES does is to return how many > physical pages are available to be used by virtual memory as backing > storage on-demand once it is touched, without any connection > whatsoever to virtual memory. > > Even if we mmap to commit heap memory without NORESERVE, the > _SC_AVPHYS_PAGES metric does not change its value - at least not until > somebody actually touches the mmaped memory and it starts becoming > backed by actual physical memory. So the JVM can in theory commit the > whole physical memory, and _SC_AVPHYS_PAGES will still reply that all > that memory is still available given that it has not been touched yet. > > It is likely that this is related to random swap-related test > failures, where too many JVMs are created based on this metric. Even > if it is not, the os::available_memory() call is still broken in its > current state and should be fixed regardless. > > My proposed fix uses kstat to get the available memory that can be > mmapped (which actually relates to virtual memory). It then uses > swapctl() to find out the amount of free swap, subtracting that from > the kstat value, to make sure we do not count swap memory as being > available for grabbing, to mimick the current behaviour of other > platforms. The code iterates over the potentially many swap resources > and adds up the free swap memory. > > kstat gives us all memory that can be made available, including memory > already used by the OS for things like file caches, and swap memory. > When this value is 0, mmap will fail. That's why I calculate the > amount of swap and remove that, assuming it is okay to use memory that > isn't immediately available but can be made available, as long as it > does not involve paging to the swap memory. > > Testing: > * JPRT > * Made my own test program that can be found in the comments of the > BUG to report on memory values, so I could verify what is going on and > that when the new os::available_memory() becomes 0, is indeed when > paging to swap starts happening using vmstat. > > I need a sponsor to push this if anyone is interested. > > Thanks, > /Erik From rachel.protacio at oracle.com Wed Apr 6 15:31:47 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 6 Apr 2016 11:31:47 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5704181C.7020405@oracle.com> References: <5703FD3B.10307@oracle.com> <5704181C.7020405@oracle.com> Message-ID: <57052BE3.8070308@oracle.com> Ok, will fix. Thanks for the review! Rachel On 4/5/2016 3:55 PM, Coleen Phillimore wrote: > > http://cr.openjdk.java.net/~rprotacio/8152896.00/test/runtime/logging/CompressedOopsTest.java.html > > > I think the test needs to have a @requires 64 bit rather than. > > 55 if (Platform.is64bit()) { > > > around part of it, because this -XX:+UseCompressedOops is unrecognized > unless it's 64 bits. > > 67 pb = > ProcessTools.createJavaProcessBuilder("-XX:+UseCompressedOops", > > The code changes look good to me. > > Coleen > > On 4/5/16 2:00 PM, Rachel Protacio wrote: >> Hello, >> >> Please review this change, converting -XX:+PrintCompressedOopsMode to >> -Xlog:gc+heap. The existing diagnostic flag has been aliased to the >> info level of this tagset (for the "Heap address" message that for >> example appears in the hs_err file), and there are both debug and >> trace levels of logging available as well, as per our established >> schema for assigning levels. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >> >> Passes JPRT and RBT quick/non-colo tests. >> >> Thanks! >> Rachel > From max.ockner at oracle.com Wed Apr 6 15:33:28 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 06 Apr 2016 11:33:28 -0400 Subject: RFR: 8152468: PrintMiscellaneous in constantPool should use classresolve logging. Message-ID: <57052C48.6070906@oracle.com> Hello hello everyone, Please review this addition to classresolve logging. Bug https://bugs.openjdk.java.net/browse/JDK-8152468 Webrev http://cr.openjdk.java.net/~mockner/8152468.01/ There were a few bits of classresolve logging that was guarded by PrintMiscellaneous instead of TraceClassResolution, and were missed in the initial conversion. This has been fixed and the classresolve test has been updated to check or new output. Tested with jtreg runtime. Thanks, Max From rachel.protacio at oracle.com Wed Apr 6 15:39:01 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 6 Apr 2016 11:39:01 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5704F3FE.4030906@oracle.com> References: <5703FD3B.10307@oracle.com> <5704F3FE.4030906@oracle.com> Message-ID: <57052D95.3020208@oracle.com> Thanks for the review, Stefan. I have removed the periods. Rachel On 4/6/2016 7:33 AM, Stefan Johansson wrote: > Hi Rachel, > > On 2016-04-05 20:00, Rachel Protacio wrote: >> Hello, >> >> Please review this change, converting -XX:+PrintCompressedOopsMode to >> -Xlog:gc+heap. The existing diagnostic flag has been aliased to the >> info level of this tagset (for the "Heap address" message that for >> example appears in the hs_err file), and there are both debug and >> trace levels of logging available as well, as per our established >> schema for assigning levels. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >> > The change looks good in general but I see that some log messages have > a dot in the end. I know you're just moving this over to UL but would > you mind removing these dots to have the same style as other (gc, > heap) messages. > > Thanks, > Stefan > >> Passes JPRT and RBT quick/non-colo tests. >> >> Thanks! >> Rachel > From rachel.protacio at oracle.com Wed Apr 6 15:53:29 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 6 Apr 2016 11:53:29 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: References: <5703FD3B.10307@oracle.com> Message-ID: <570530F9.8000901@oracle.com> Hi, Thanks for the response. Yes, there is other gc+heap logging already present. As you can see from the grep below, there are a number of other messages, especially in the trace level (which is to be expected as verbose anyway). Additionally, there's the question of which level should be aliased to. Right now, I have it at the info level, which just prints the "Heap address" line but I could make it debug level to print the other ones from virtualspace.cpp. I'm fine with adding another tag, but I want to make sure we have a consensus before I do so. Does anyone else want to weigh in? Thanks, Rachel src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS ergo set MaxNewSize: " SIZE_FORMAT, MaxNewSize); src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, heap)("CMS set min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT " max_heap: " SIZE_FORMAT, src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, heap)("CMS ergo set NewSize: " SIZE_FORMAT, NewSize); src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, heap)("CMS ergo set OldSize: " SIZE_FORMAT, OldSize); src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" Maximum heap size " SIZE_FORMAT, (size_t) reasonable_max); src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, heap)(" Initial heap size " SIZE_FORMAT, (size_t)reasonable_initial); src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, heap)(" Minimum heap size " SIZE_FORMAT, min_heap_size()); src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " Maximum heap " SIZE_FORMAT, src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, heap)("1: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT " Maximum young " SIZE_FORMAT, src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, heap)("2: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT " Maximum young " SIZE_FORMAT, src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " Maximum old " SIZE_FORMAT, src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " SIZE_FORMAT "K", src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, heap)("Garbage collection disabled, expanded heap instead"); src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, heap)("TenuredGeneration::compute_new_size:"); src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, heap)(" minimum_free_percentage: %6.2f maximum_used_percentage: %6.2f", src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK capacity_after_gc : %6.1fK", src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, heap)(" free_percentage: %6.2f", free_percentage); src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, heap)(" expanding: minimum_desired_capacity: %6.1fK expand_bytes: %6.1fK _min_heap_delta_bytes: %6.1fK", src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, heap)(" maximum_free_percentage: %6.2f minimum_used_percentage: %6.2f", src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, heap)(" _capacity_at_prologue: %6.1fK minimum_desired_capacity: %6.1fK maximum_desired_capacity: %6.1fK", src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: %.1fK", src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, heap)(" shrink_bytes: %.1fK current_shrink_factor: " SIZE_FORMAT " new shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: %.1fK", src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, heap)(" aggressive shrinking: _capacity_at_prologue: %.1fK capacity_after_gc: %.1fK expansion_for_promotion: %.1fK shrink_bytes: %.1fK", src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, heap) log; src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: log_info(gc, heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap region size: " SIZE_FORMAT "M", GrainBytes / M); src/share/vm/gc/g1/g1HeapTransition.cpp:89: if (log_is_enabled(Trace, gc, heap)) { src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, heap)("Eden regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" SIZE_FORMAT ")", src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" Used: 0K, Waste: 0K"); src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, heap)("Survivor regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" SIZE_FORMAT ")", src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, heap)("Old regions: " SIZE_FORMAT "->" SIZE_FORMAT, src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, heap)("Reserved memory not at requested address: " PTR_FORMAT " vs " PTR_FORMAT, p2i(base), p2i(requested_address)); src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, heap)("Reserve regular memory without large pages"); src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, heap)("Protected page at the reserved heap base: " src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, heap)("Trying to allocate at address " PTR_FORMAT src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, heap)("Reserve regular memory without large pages"); src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, heap)("Trying to allocate at address NULL heap of size " SIZE_FORMAT_HEX, size + noaccess_prefix); src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, gc, heap)) { src/share/vm/memory/universe.cpp:752: outputStream* logst = Log(gc, heap)::info_stream(); src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; On 4/6/2016 8:26 AM, Thomas St?fe wrote: > Hi Rachel, > > one question, does this change the output for > -XX:PrintCompressedOopsMode much? It seems to be wired now to > "LOG_TAGS(gc, heap)", which prints much more than just heap > reservation for the compressed oops mode. Would it be possible to add > a "coops" tag or similar to isolate this output? > > The reason I ask is that we used this flag extensively when optimizing > heap reservation on AIX for compressed oops, and may want to continue > using it or an alternative which gives the same output. > > Kind Regards, Thomas > > > On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio > > wrote: > > Hello, > > Please review this change, converting -XX:+PrintCompressedOopsMode > to -Xlog:gc+heap. The existing diagnostic flag has been aliased to > the info level of this tagset (for the "Heap address" message that > for example appears in the hs_err file), and there are both debug > and trace levels of logging available as well, as per our > established schema for assigning levels. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ > > > Passes JPRT and RBT quick/non-colo tests. > > Thanks! > Rachel > > From rachel.protacio at oracle.com Wed Apr 6 15:58:25 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 6 Apr 2016 11:58:25 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5703FF96.6090204@oracle.com> References: <5703FD3B.10307@oracle.com> <5703FF96.6090204@oracle.com> Message-ID: <57053221.2000606@oracle.com> Thanks for the review! There are no appearances of the string "heap address" in any jtreg tests or tonga tests. Is there any other place that might check? Rachel On 4/5/2016 2:10 PM, Vladimir Kozlov wrote: > Looks fine except next change. Do we have a test which parse this > output?: > > ! st->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", > ! st->print("Heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", > > Thanks, > Vladimir > > On 4/5/16 11:00 AM, Rachel Protacio wrote: >> Hello, >> >> Please review this change, converting -XX:+PrintCompressedOopsMode to >> -Xlog:gc+heap. The existing diagnostic flag has been aliased to the info >> level of this tagset (for the "Heap address" message that for example >> appears in the hs_err file), and there are both debug and trace levels >> of logging available as well, as per our established schema for >> assigning levels. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >> >> Passes JPRT and RBT quick/non-colo tests. >> >> Thanks! >> Rachel From vladimir.kozlov at oracle.com Wed Apr 6 16:29:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 6 Apr 2016 09:29:10 -0700 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <57053221.2000606@oracle.com> References: <5703FD3B.10307@oracle.com> <5703FF96.6090204@oracle.com> <57053221.2000606@oracle.com> Message-ID: <57053956.5000907@oracle.com> I doubt anyone except using it. Okay, I agree with this change. Thanks, Vladimir On 4/6/16 8:58 AM, Rachel Protacio wrote: > Thanks for the review! > There are no appearances of the string "heap address" in any jtreg tests > or tonga tests. Is there any other place that might check? > Rachel > > On 4/5/2016 2:10 PM, Vladimir Kozlov wrote: >> Looks fine except next change. Do we have a test which parse this >> output?: >> >> ! st->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", >> ! st->print("Heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", >> >> Thanks, >> Vladimir >> >> On 4/5/16 11:00 AM, Rachel Protacio wrote: >>> Hello, >>> >>> Please review this change, converting -XX:+PrintCompressedOopsMode to >>> -Xlog:gc+heap. The existing diagnostic flag has been aliased to the info >>> level of this tagset (for the "Heap address" message that for example >>> appears in the hs_err file), and there are both debug and trace levels >>> of logging available as well, as per our established schema for >>> assigning levels. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>> >>> Passes JPRT and RBT quick/non-colo tests. >>> >>> Thanks! >>> Rachel > From vladimir.kozlov at oracle.com Wed Apr 6 16:30:49 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 6 Apr 2016 09:30:49 -0700 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <57053956.5000907@oracle.com> References: <5703FD3B.10307@oracle.com> <5703FF96.6090204@oracle.com> <57053221.2000606@oracle.com> <57053956.5000907@oracle.com> Message-ID: <570539B9.1040406@oracle.com> On 4/6/16 9:29 AM, Vladimir Kozlov wrote: > I doubt anyone except using it. Okay, I agree with this change. except us > > Thanks, > Vladimir > > On 4/6/16 8:58 AM, Rachel Protacio wrote: >> Thanks for the review! >> There are no appearances of the string "heap address" in any jtreg tests >> or tonga tests. Is there any other place that might check? >> Rachel >> >> On 4/5/2016 2:10 PM, Vladimir Kozlov wrote: >>> Looks fine except next change. Do we have a test which parse this >>> output?: >>> >>> ! st->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", >>> ! st->print("Heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " MB", >>> >>> Thanks, >>> Vladimir >>> >>> On 4/5/16 11:00 AM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review this change, converting -XX:+PrintCompressedOopsMode to >>>> -Xlog:gc+heap. The existing diagnostic flag has been aliased to the >>>> info >>>> level of this tagset (for the "Heap address" message that for example >>>> appears in the hs_err file), and there are both debug and trace levels >>>> of logging available as well, as per our established schema for >>>> assigning levels. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>>> >>>> Passes JPRT and RBT quick/non-colo tests. >>>> >>>> Thanks! >>>> Rachel >> From daniel.daugherty at oracle.com Wed Apr 6 16:31:58 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 10:31:58 -0600 Subject: RFR(M): 8152995: Solaris os::available_memory() doesn't do what we think it does In-Reply-To: <5705187E.3020000@oracle.com> References: <5705187E.3020000@oracle.com> Message-ID: <570539FE.3060406@oracle.com> Erik, Thanks for adding Runtime to this discussion. The topic is definitely of interest to Runtime folks... More below... On 2016-04-06 16:09, Erik ?sterlund wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152995 > CR: http://cr.openjdk.java.net/~eosterlund/8152995/webrev.00/ > > On Solaris, the os::available_memory() function is currently > calculated with sysconf(_SC_AVPHYS_PAGES). The Solaris man page for sysconf(_SC_AVPHYS_PAGES): _SC_AVPHYS_PAGES Number of physical memory pages not currently in use by system > Unfortunately this does not match intended semantics. The intended > semantics is to return how much memory can be allocated by mmap into > physical memory. But, what _SC_AVPHYS_PAGES does is to return how many > physical pages are available to be used by virtual memory as backing > storage on-demand once it is touched, without any connection > whatsoever to virtual memory. This part has me curious: > The intended semantics is to return how much memory can be allocated > by mmap into physical memory. since I don't understand where you found the "intended semantics". Only one of the platforms has any comments about available_memory: src/os/bsd/vm/os_bsd.cpp: // available here means free julong os::Bsd::available_memory() { the rest just don't say... Personally, I've always interpreted available_memory() to mean available physical pages, as in pages that are not in use now. This matches the definition of _SC_AVPHYS_PAGES above... > Even if we mmap to commit heap memory without NORESERVE, the > _SC_AVPHYS_PAGES metric does not change its value - at least not until > somebody actually touches the mmaped memory and it starts becoming > backed by actual physical memory. So the JVM can in theory commit the > whole physical memory, and _SC_AVPHYS_PAGES will still reply that all > that memory is still available given that it has not been touched yet. Yes, I believe that is exactly how things work and I think that available_memory() is returning that information correctly. > It is likely that this is related to random swap-related test > failures, where too many JVMs are created based on this metric. Please explain further. What do you mean by "too many JVMs are created based on this metric"? > Even > if it is not, the os::available_memory() call is still broken in its > current state and should be fixed regardless. I'm not yet convinced that available_memory() is broken and needs to be fixed. I don't see available_memory() being used in a lot of places and those uses that I do see are mostly just reports of the value... So what am I missing about how os::available_memory() is being used? Dan > My proposed fix uses kstat to get the available memory that can be > mmapped (which actually relates to virtual memory). It then uses > swapctl() to find out the amount of free swap, subtracting that from > the kstat value, to make sure we do not count swap memory as being > available for grabbing, to mimick the current behaviour of other > platforms. The code iterates over the potentially many swap resources > and adds up the free swap memory. > > kstat gives us all memory that can be made available, including memory > already used by the OS for things like file caches, and swap memory. > When this value is 0, mmap will fail. That's why I calculate the > amount of swap and remove that, assuming it is okay to use memory that > isn't immediately available but can be made available, as long as it > does not involve paging to the swap memory. > > Testing: > * JPRT > * Made my own test program that can be found in the comments of the > BUG to report on memory values, so I could verify what is going on and > that when the new os::available_memory() becomes 0, is indeed when > paging to swap starts happening using vmstat. > > I need a sponsor to push this if anyone is interested. > > Thanks, > /Erik From coleen.phillimore at oracle.com Wed Apr 6 16:46:05 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Apr 2016 12:46:05 -0400 Subject: RFR: 8152468: PrintMiscellaneous in constantPool should use classresolve logging. In-Reply-To: <57052C48.6070906@oracle.com> References: <57052C48.6070906@oracle.com> Message-ID: <57053D4D.7060501@oracle.com> Hi Max, Thanks for doing this. // FIXME: should be an assert *if (PrintMiscellaneous && (Verbose||WizardMode)) {* *tty->print_cr("bad operand %d in:", which); cpool->print();* *}* *+log_trace(classresolve)("bad operand %d in:", which); cpool->print();* Can you make this log_debug() since it seems to be trying to catch a bug? For the other two changes, I don't see a ResourceMark. Can you add one to both with ResourceMark rm(THREAD); The THREAD parameter makes the ResourceMark inexpensive in terms of code generated. Also I just noticed that trace_class_resolution does a bit of work even when logging is disabled. Can you add a if (log_is_enabled(Debug, classresolve)) { before the trace_class_resolution call? Lastly, I think we should point out that we agreed that the classresolve tag is going to become the tag set class,resolve, with an RFE that you're going to file. Thanks, Coleen On 4/6/16 11:33 AM, Max Ockner wrote: > Hello hello everyone, > > Please review this addition to classresolve logging. > > Bug https://bugs.openjdk.java.net/browse/JDK-8152468 > Webrev http://cr.openjdk.java.net/~mockner/8152468.01/ > > There were a few bits of classresolve logging that was guarded by > PrintMiscellaneous instead of TraceClassResolution, and were missed in > the initial conversion. This has been fixed and the classresolve test > has been updated to check or new output. > > Tested with jtreg runtime. > > Thanks, > Max > From rachel.protacio at oracle.com Wed Apr 6 17:06:53 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 6 Apr 2016 13:06:53 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <570539B9.1040406@oracle.com> References: <5703FD3B.10307@oracle.com> <5703FF96.6090204@oracle.com> <57053221.2000606@oracle.com> <57053956.5000907@oracle.com> <570539B9.1040406@oracle.com> Message-ID: <5705422D.4040503@oracle.com> Great. Rachel On 4/6/2016 12:30 PM, Vladimir Kozlov wrote: > On 4/6/16 9:29 AM, Vladimir Kozlov wrote: >> I doubt anyone except using it. Okay, I agree with this change. > > except us > >> >> Thanks, >> Vladimir >> >> On 4/6/16 8:58 AM, Rachel Protacio wrote: >>> Thanks for the review! >>> There are no appearances of the string "heap address" in any jtreg >>> tests >>> or tonga tests. Is there any other place that might check? >>> Rachel >>> >>> On 4/5/2016 2:10 PM, Vladimir Kozlov wrote: >>>> Looks fine except next change. Do we have a test which parse this >>>> output?: >>>> >>>> ! st->print("heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " >>>> MB", >>>> ! st->print("Heap address: " PTR_FORMAT ", size: " SIZE_FORMAT " >>>> MB", >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 4/5/16 11:00 AM, Rachel Protacio wrote: >>>>> Hello, >>>>> >>>>> Please review this change, converting -XX:+PrintCompressedOopsMode to >>>>> -Xlog:gc+heap. The existing diagnostic flag has been aliased to the >>>>> info >>>>> level of this tagset (for the "Heap address" message that for example >>>>> appears in the hs_err file), and there are both debug and trace >>>>> levels >>>>> of logging available as well, as per our established schema for >>>>> assigning levels. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>>>> >>>>> Passes JPRT and RBT quick/non-colo tests. >>>>> >>>>> Thanks! >>>>> Rachel >>> From rachel.protacio at oracle.com Wed Apr 6 17:19:51 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 6 Apr 2016 13:19:51 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <57041DC0.1030709@oracle.com> References: <5703FD3B.10307@oracle.com> <57041DC0.1030709@oracle.com> Message-ID: <57054537.5060404@oracle.com> Hi, Harold, Thanks for noticing. The only output UseCompressedOops.java looks for is from the info-level logging in universe.cpp. The rest is src/share/vm/runtime/arguments.cpp:1902: warning("Max heap size too large for Compressed Oops"); So since PrintCompressedOopsMode is aliased to the info level of the logging, it still would work as-is ("would" because the test is currently @ignore'd). But in terms of the UnlockDiagnosticVMOptions, that's true that it's not needed now for PrintCompressedOopsMode. I'll make sure it'snot needed for the other flags and if not, I'll delete it from those two tests. Rachel On 4/5/2016 4:19 PM, harold seigel wrote: > Hi Rachel, > > Does hotspot/test/runtime/CompressedOops/UseCompressedOops.java also > need to change? > > private static OutputAnalyzer testCompressedOops(ArrayList > flags1, String... flags2) throws Exception { > ArrayList args = new ArrayList<>(); > > // Always run with these three: > args.add("-XX:+UnlockDiagnosticVMOptions"); > args.add("-XX:+PrintCompressedOopsMode"); > > > Also, I think -XX:+UnlockDiagnosticVMOptions can be removed from this > test and from CompressedClassPointers.java. > > Thanks, Harold > > On 4/5/2016 2:00 PM, Rachel Protacio wrote: >> Hello, >> >> Please review this change, converting -XX:+PrintCompressedOopsMode to >> -Xlog:gc+heap. The existing diagnostic flag has been aliased to the >> info level of this tagset (for the "Heap address" message that for >> example appears in the hs_err file), and there are both debug and >> trace levels of logging available as well, as per our established >> schema for assigning levels. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >> >> Passes JPRT and RBT quick/non-colo tests. >> >> Thanks! >> Rachel > From jiangli.zhou at oracle.com Wed Apr 6 17:42:36 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 6 Apr 2016 10:42:36 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <5704549C.1080508@oracle.com> References: <5702D7A6.1090601@oracle.com> <5FF42E5E-8C70-4E83-8F10-271737A55577@oracle.com> <5703FBB2.2040205@oracle.com> <5704549C.1080508@oracle.com> Message-ID: <86B4F024-94B1-43B6-BCA2-21D00682C958@oracle.com> Hi Calvin, Looks good. Thank you for making the change. Thanks, Jiangli > On Apr 5, 2016, at 5:13 PM, Calvin Cheung wrote: > > > > On 4/5/16, 1:29 PM, Jiangli Zhou wrote: >> >> Hi Calvin, >> >>> On Apr 5, 2016, at 10:53 AM, Calvin Cheung > wrote: >>> >>> >>> >>> On 4/5/16, 10:44 AM, Jiangli Zhou wrote: >>>> >>>> Hi Calvin, >>>> >>>> Have you thought about using strcasecmp()? The globalDefinitions_visCPP.hpp defines strcasecmp to _stricmp. So compiler dependency is not an issue. We have existing code that uses strcasecmp() for case insensitive comparison. >>> I don't think it will work in this situation. It is because the manifest buffer contains all the jar manifest entries, not just the "Multi-Release" entry. In other words, "Multi-Release" isn't at the beginning of the string. >> >> Ok. There is strcasestr(), but it?s a nonstandard extension. I couldn?t find a Windows equivalent for that. Iterating the string to covert each char to lower case is slow although it?s only used in CDS dump time. To make it more efficient, you could add a new field, ?u1 is_multi_versioned' in ClassPathZipEntry to remember the result so you only need to do the case in-senstive strstr once, instead of everytime when ClassPathZipEntry::open_stream() is called. The new field could have three states, ?unknown?, ?yes? and ?no?. If it?s ?unknown?, is_multiple_versioned() opens the manifest, otherwise it can return quickly. > I've an updated webrev for the above change. > http://cr.openjdk.java.net/~ccheung/8152329/webrev.02/ > > Some testing in progress. > > thanks, > Calvin >> >> Thanks, >> Jiangli >> >> >>> >>> thanks, >>> Calvin >>>> >>>> // Non-standard stdlib-like stuff: >>>> inline int strcasecmp(const char *s1, const char *s2) { return _stricmp(s1,s2); } >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Apr 4, 2016, at 2:07 PM, Calvin Cheung > wrote: >>>>> >>>>> >>>>> Please review this small fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8152329 >>>>> >>>>> The fix is to convert the buffer containing the jar manifest into lower case before performing strstr. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ >>>>> >>>>> Testing: >>>>> JPRT -testset hotspot >>>>> The tests under runtime on the platforms built by JPRT. >>>>> >>>>> thanks, >>>>> Calvin >>>> >> > From igor.veresov at oracle.com Wed Apr 6 17:49:31 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 6 Apr 2016 10:49:31 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <9F99FE47-E84D-4C4A-B854-F6432D10BC6C@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <1EAD5675-6903-4C48-A778-05A99F591D1C@oracle.com> <4C106849-365D-42E8-B4A5-ADC7297BEA1B@oracle.com> <9F99FE47-E84D-4C4A-B854-F6432D10BC6C@oracle.com> Message-ID: <713E9C18-274A-41F5-AA40-56A78A608763@oracle.com> Karen, am I correct to assume I can consider the current change reviewed? I?d like to push it. We can discuss how to harden/refactor other dimensions of the use of LinkResolver by compilers separately. Thanks, igor > On Apr 5, 2016, at 4:22 PM, Igor Veresov wrote: > > >> On Apr 5, 2016, at 3:33 PM, Karen Kinnear wrote: >> >> Igor, >> >> Do you run all the tests with -Xcomp or whatever flag ensures you test JVMCI vs. interpreter >> for instance? > > Yes, I ran our RBT round of testing that does that -Xcomp and -Xmixed. > >> >> If so, I am ok with checking this in - further notes below. >> >>> On Apr 5, 2016, at 3:43 PM, Igor Veresov > wrote: >>> >>> >>>> On Apr 5, 2016, at 12:04 PM, Karen Kinnear > wrote: >>>> >>>> I am in agreement with Lois that the JVMS looks good with moving the exception. >>> >>> Thanks! >>>> >>>> With the checking I have done so far, I believe that linktime_resolve_static_method is only called with an invoke static - but after my next >>>> meeting I will check one more time. It might be worth adding a comment. >>> >>> Ok, I added a comment to resolve_interface_method(): http://cr.openjdk.java.net/~iveresov/8153115/webrev.01/ >>> Again, the bytecode argument here indicates the context, not the actual bytecode. Of course, for example, the method may be invoked with a method handle. >>> >>>> >>>> My concern is specific to the code in jvmciCompilerToVM.cpp there is code called resolveMethod that checks >>>> if holder_klass->is_interface -> LR::linktime_resolve_interface_method_or_null. >>>> >>> >>> That code needs fixing as well. We have the following issue filed for that: https://bugs.openjdk.java.net/browse/JDK-8152903 >>> In the nutshell, resolveMethod() sort of emulates what happens during a virtual call (it is only called for invokevirtual and invokeinterface). It should do both linktime and runtime resolutions. The JVMCI version should work the same way as the CI version (see ciMethod::resolve_invoke() in ciMethod.cpp). >> >> Hmmm - I see the ciMethod::resolve_invoke has the same problem that I just called out, so making the JVMCI one match >> the CI version makes me wonder if we have sufficient test cases. But I hear that you would like to address that as a followup. >> That is ok with me - I will add a note to the bug. > > Could you please explain what is the problem again? Are you concerned that the bytecode is not passed to resolve_invoke, so we may call linktime_resolve_interface_or_null, for an interface holder when in reality it was an invokevirtual instruction and vice versa? > >> >> Also: I see a ciMethod::check_call that has a comment - >> IT appears to fail when applied to an invoke interface call site. >> FIXME: Remove this method and resolve_method_statically; refactor to use the other LinkResolver entry points. >> > > This comment is odd. I don?t see why it would fail for invokeinterface. The code certainly seems to account for it. May be the comment is wrong? Any ideas? > > igor > >> Could you possibly file a bug on this one? What I am seeing is a conditional for invoke static vs. invoke virtual that does not take >> the subtleties of invoke interface and invoke special into account. >>> >>> igor >>> >>>> I think we need to study this one more closely - I suspect that you need a set of detailed tests that cover the >>>> corner cases here. I don?t know the code paths, but I would suggest following this approach of passing in the byte code, >>>> so that you get the correct behavior depending on the requesting byte code. >>>> >>>> I am not sure what resolveMethod is doing here - since you seem to already have the resolved method and the receiver - so >>>> I could use help studying this a bit more to understand if this really is resolution or is really selection. >>>> >>>> thanks, >>>> Karen >>>> >>>>> On Apr 5, 2016, at 1:34 PM, Lois Foltan > wrote: >>>>> >>>>> >>>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>>> Hi Lois, >>>>>> >>>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>>> >>>>>> igor >>>>> Hi Igor, >>>>> >>>>> Thanks for waiting on this. A couple of comments: >>>>> >>>>> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >>>>> >>>>> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >>>>> >>>>> Just curious did you also run the testbase default methods tests? >>>>> Lois >>>>> >>>>>> >>>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan > wrote: >>>>>>> >>>>>>> Hi Igor, >>>>>>> >>>>>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>>>>> >>>>>>> Thanks, >>>>>>> Lois >>>>>>> >>>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> igor > From calvin.cheung at oracle.com Wed Apr 6 18:07:02 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 06 Apr 2016 11:07:02 -0700 Subject: RFR(xs): JDK-8152329: jvm should treat the "Multi-Release" jar manifest attribute name as case insensitive In-Reply-To: <86B4F024-94B1-43B6-BCA2-21D00682C958@oracle.com> References: <5702D7A6.1090601@oracle.com> <5FF42E5E-8C70-4E83-8F10-271737A55577@oracle.com> <5703FBB2.2040205@oracle.com> <5704549C.1080508@oracle.com> <86B4F024-94B1-43B6-BCA2-21D00682C958@oracle.com> Message-ID: <57055046.4070209@oracle.com> Hi Jiangli, Thanks for your re-review. Calvin On 4/6/16, 10:42 AM, Jiangli Zhou wrote: > Hi Calvin, > > Looks good. Thank you for making the change. > > Thanks, > Jiangli > >> On Apr 5, 2016, at 5:13 PM, Calvin Cheung > > wrote: >> >> >> >> On 4/5/16, 1:29 PM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>>> On Apr 5, 2016, at 10:53 AM, Calvin Cheung >>>> > wrote: >>>> >>>> >>>> >>>> On 4/5/16, 10:44 AM, Jiangli Zhou wrote: >>>>> Hi Calvin, >>>>> >>>>> Have you thought about using strcasecmp()? The >>>>> globalDefinitions_visCPP.hpp defines strcasecmp to _stricmp. So >>>>> compiler dependency is not an issue. We have existing code that >>>>> uses strcasecmp() for case insensitive comparison. >>>> I don't think it will work in this situation. It is because the >>>> manifest buffer contains all the jar manifest entries, not just the >>>> "Multi-Release" entry. In other words, "Multi-Release" isn't at the >>>> beginning of the string. >>> >>> Ok. There is strcasestr(), but it?s a nonstandard extension. I >>> couldn?t find a Windows equivalent for that. Iterating the string to >>> covert each char to lower case is slow although it?s only used in >>> CDS dump time. To make it more efficient, you could add a new field, >>> ?u1 is_multi_versioned' in ClassPathZipEntry to remember the result >>> so you only need to do the case in-senstive strstr once, instead of >>> everytime when ClassPathZipEntry::open_stream() is called. The new >>> field could have three states, ?unknown?, ?yes? and ?no?. If it?s >>> ?unknown?, is_multiple_versioned() opens the manifest, otherwise it >>> can return quickly. >> I've an updated webrev for the above change. >> http://cr.openjdk.java.net/~ccheung/8152329/webrev.02/ >> >> Some testing in progress. >> >> thanks, >> Calvin >>> >>> Thanks, >>> Jiangli >>> >>> >>>> >>>> thanks, >>>> Calvin >>>>> >>>>> // Non-standard stdlib-like stuff: >>>>> inlineintstrcasecmp(constchar*s1,constchar*s2) >>>>> {return_stricmp(s1,s2); } >>>>> >>>>> Thanks, >>>>> Jiangli >>>>>> On Apr 4, 2016, at 2:07 PM, Calvin Cheung >>>>>> > wrote: >>>>>> >>>>>> >>>>>> Please review this small fix for: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8152329 >>>>>> >>>>>> The fix is to convert the buffer containing the jar manifest into >>>>>> lower case before performing strstr. >>>>>> >>>>>> webrev:http://cr.openjdk.java.net/~ccheung/8152329/webrev.01/ >>>>>> >>>>>> Testing: >>>>>> JPRT -testset hotspot >>>>>> The tests under runtime on the platforms built by JPRT. >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>> >>> >> > From coleen.phillimore at oracle.com Wed Apr 6 19:09:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 6 Apr 2016 15:09:28 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <570530F9.8000901@oracle.com> References: <5703FD3B.10307@oracle.com> <570530F9.8000901@oracle.com> Message-ID: <57055EE8.1020209@oracle.com> I think adding the coops tag to isolate this logging from all the other GC logging is a good idea. The name "coops" to mean "compressed oops" for the tag has meaning for us in the vm so it's not a bad abbreviation. Coleen On 4/6/16 11:53 AM, Rachel Protacio wrote: > Hi, > > Thanks for the response. Yes, there is other gc+heap logging already > present. As you can see from the grep below, there are a number of > other messages, especially in the trace level (which is to be expected > as verbose anyway). Additionally, there's the question of which level > should be aliased to. Right now, I have it at the info level, which > just prints the "Heap address" line but I could make it debug level to > print the other ones from virtualspace.cpp. > > I'm fine with adding another tag, but I want to make sure we have a > consensus before I do so. Does anyone else want to weigh in? > > Thanks, > Rachel > > > > src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS > ergo set MaxNewSize: " SIZE_FORMAT, MaxNewSize); > src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, heap)("CMS > set min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT > " max_heap: " SIZE_FORMAT, > src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, > heap)("CMS ergo set NewSize: " SIZE_FORMAT, NewSize); > src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, > heap)("CMS ergo set OldSize: " SIZE_FORMAT, OldSize); > src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, > heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT > src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" > Maximum heap size " SIZE_FORMAT, (size_t) reasonable_max); > src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, heap)(" > Initial heap size " SIZE_FORMAT, (size_t)reasonable_initial); > src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, heap)(" > Minimum heap size " SIZE_FORMAT, min_heap_size()); > src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, > heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " > Maximum heap " SIZE_FORMAT, > src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, > heap)("1: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT > " Maximum young " SIZE_FORMAT, > src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, > heap)("2: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT > " Maximum young " SIZE_FORMAT, > src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, > heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " > Maximum old " SIZE_FORMAT, > src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, > heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " > SIZE_FORMAT "K", > src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, > heap)("Garbage collection disabled, expanded heap instead"); > src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, > heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", > src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, > heap)("TenuredGeneration::compute_new_size:"); > src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, > heap)(" minimum_free_percentage: %6.2f maximum_used_percentage: > %6.2f", > src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, > heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK > capacity_after_gc : %6.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, > heap)(" free_percentage: %6.2f", free_percentage); > src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, > heap)(" expanding: minimum_desired_capacity: %6.1fK > expand_bytes: %6.1fK _min_heap_delta_bytes: %6.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, > heap)(" maximum_free_percentage: %6.2f minimum_used_percentage: > %6.2f", > src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, > heap)(" _capacity_at_prologue: %6.1fK minimum_desired_capacity: > %6.1fK maximum_desired_capacity: %6.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, > heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: > %.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, > heap)(" shrink_bytes: %.1fK current_shrink_factor: " SIZE_FORMAT > " new shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: %.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, > heap)(" aggressive shrinking: _capacity_at_prologue: %.1fK > capacity_after_gc: %.1fK expansion_for_promotion: %.1fK > shrink_bytes: %.1fK", > src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, > heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, > heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: > " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, > heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, > heap) log; > src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: > log_info(gc, heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" > SIZE_FORMAT "K)", > src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap > region size: " SIZE_FORMAT "M", GrainBytes / M); > src/share/vm/gc/g1/g1HeapTransition.cpp:89: if > (log_is_enabled(Trace, gc, heap)) { > src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, > heap)("Eden regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" SIZE_FORMAT > ")", > src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" > Used: 0K, Waste: 0K"); > src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, > heap)("Survivor regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" > SIZE_FORMAT ")", > src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" > Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", > src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, > heap)("Old regions: " SIZE_FORMAT "->" SIZE_FORMAT, > src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" > Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", > src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, > heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, > src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" > Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", > src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, > heap)("Reserved memory not at requested address: " PTR_FORMAT " vs " > PTR_FORMAT, p2i(base), p2i(requested_address)); > src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, > heap)("Reserve regular memory without large pages"); > src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, > heap)("Protected page at the reserved heap base: " > src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, > heap)("Trying to allocate at address " PTR_FORMAT > src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, > heap)("Reserve regular memory without large pages"); > src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, > heap)("Trying to allocate at address NULL heap of size " > SIZE_FORMAT_HEX, size + noaccess_prefix); > src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, > gc, heap)) { > src/share/vm/memory/universe.cpp:752: outputStream* logst = > Log(gc, heap)::info_stream(); > src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; > src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; > > > On 4/6/2016 8:26 AM, Thomas St?fe wrote: >> Hi Rachel, >> >> one question, does this change the output for >> -XX:PrintCompressedOopsMode much? It seems to be wired now to >> "LOG_TAGS(gc, heap)", which prints much more than just heap >> reservation for the compressed oops mode. Would it be possible to add >> a "coops" tag or similar to isolate this output? >> >> The reason I ask is that we used this flag extensively when >> optimizing heap reservation on AIX for compressed oops, and may want >> to continue using it or an alternative which gives the same output. >> >> Kind Regards, Thomas >> >> >> On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio >> > wrote: >> >> Hello, >> >> Please review this change, converting -XX:+PrintCompressedOopsMode >> to -Xlog:gc+heap. The existing diagnostic flag has been aliased to >> the info level of this tagset (for the "Heap address" message that >> for example appears in the hs_err file), and there are both debug >> and trace levels of logging available as well, as per our >> established schema for assigning levels. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >> >> >> Passes JPRT and RBT quick/non-colo tests. >> >> Thanks! >> Rachel >> >> > From rachel.protacio at oracle.com Wed Apr 6 19:27:39 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 6 Apr 2016 15:27:39 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <57055EE8.1020209@oracle.com> References: <5703FD3B.10307@oracle.com> <570530F9.8000901@oracle.com> <57055EE8.1020209@oracle.com> Message-ID: <5705632B.9090006@oracle.com> Ok, I've gone ahead and added the 'coops' tag, making this conversion PrintCompressedOopsMode -> -Xlog:gc+heap+coops New webrev: http://cr.openjdk.java.net/~rprotacio/8152896.01 Also deleted ending periods in log messages, removed "UnlockDiagnosticVMOptions" from tests where it is now unnecessary, and @require'd 64 bit in the new test. Thanks, Rachel On 4/6/2016 3:09 PM, Coleen Phillimore wrote: > > I think adding the coops tag to isolate this logging from all the > other GC logging is a good idea. The name "coops" to mean "compressed > oops" for the tag has meaning for us in the vm so it's not a bad > abbreviation. > > Coleen > > On 4/6/16 11:53 AM, Rachel Protacio wrote: >> Hi, >> >> Thanks for the response. Yes, there is other gc+heap logging already >> present. As you can see from the grep below, there are a number of >> other messages, especially in the trace level (which is to be >> expected as verbose anyway). Additionally, there's the question of >> which level should be aliased to. Right now, I have it at the info >> level, which just prints the "Heap address" line but I could make it >> debug level to print the other ones from virtualspace.cpp. >> >> I'm fine with adding another tag, but I want to make sure we have a >> consensus before I do so. Does anyone else want to weigh in? >> >> Thanks, >> Rachel >> >> >> >> src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS >> ergo set MaxNewSize: " SIZE_FORMAT, MaxNewSize); >> src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, heap)("CMS >> set min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT >> " max_heap: " SIZE_FORMAT, >> src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, >> heap)("CMS ergo set NewSize: " SIZE_FORMAT, NewSize); >> src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, >> heap)("CMS ergo set OldSize: " SIZE_FORMAT, OldSize); >> src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, >> heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT >> src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" >> Maximum heap size " SIZE_FORMAT, (size_t) reasonable_max); >> src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, >> heap)(" Initial heap size " SIZE_FORMAT, (size_t)reasonable_initial); >> src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, >> heap)(" Minimum heap size " SIZE_FORMAT, min_heap_size()); >> src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, >> heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " >> Maximum heap " SIZE_FORMAT, >> src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, >> heap)("1: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT >> " Maximum young " SIZE_FORMAT, >> src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, >> heap)("2: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT >> " Maximum young " SIZE_FORMAT, >> src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, >> heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " >> Maximum old " SIZE_FORMAT, >> src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, >> heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " >> SIZE_FORMAT "K", >> src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, >> heap)("Garbage collection disabled, expanded heap instead"); >> src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, >> heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", >> src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, >> heap)("TenuredGeneration::compute_new_size:"); >> src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, >> heap)(" minimum_free_percentage: %6.2f maximum_used_percentage: >> %6.2f", >> src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, >> heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK >> capacity_after_gc : %6.1fK", >> src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, >> heap)(" free_percentage: %6.2f", free_percentage); >> src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, >> heap)(" expanding: minimum_desired_capacity: %6.1fK >> expand_bytes: %6.1fK _min_heap_delta_bytes: %6.1fK", >> src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, >> heap)(" maximum_free_percentage: %6.2f minimum_used_percentage: >> %6.2f", >> src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, >> heap)(" _capacity_at_prologue: %6.1fK minimum_desired_capacity: >> %6.1fK maximum_desired_capacity: %6.1fK", >> src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, >> heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: >> %.1fK", >> src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, >> heap)(" shrink_bytes: %.1fK current_shrink_factor: " SIZE_FORMAT >> " new shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: %.1fK", >> src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, >> heap)(" aggressive shrinking: _capacity_at_prologue: %.1fK >> capacity_after_gc: %.1fK expansion_for_promotion: %.1fK >> shrink_bytes: %.1fK", >> src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, >> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >> src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, >> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >> src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: >> " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >> src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, >> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, >> heap) log; >> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: >> log_info(gc, heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" >> SIZE_FORMAT "K)", >> src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap >> region size: " SIZE_FORMAT "M", GrainBytes / M); >> src/share/vm/gc/g1/g1HeapTransition.cpp:89: if >> (log_is_enabled(Trace, gc, heap)) { >> src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, >> heap)("Eden regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >> SIZE_FORMAT ")", >> src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" >> Used: 0K, Waste: 0K"); >> src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, >> heap)("Survivor regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >> SIZE_FORMAT ")", >> src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" >> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >> src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, >> heap)("Old regions: " SIZE_FORMAT "->" SIZE_FORMAT, >> src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" >> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >> src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, >> heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, >> src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" >> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >> src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, >> heap)("Reserved memory not at requested address: " PTR_FORMAT " vs " >> PTR_FORMAT, p2i(base), p2i(requested_address)); >> src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, >> heap)("Reserve regular memory without large pages"); >> src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, >> heap)("Protected page at the reserved heap base: " >> src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, >> heap)("Trying to allocate at address " PTR_FORMAT >> src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, >> heap)("Reserve regular memory without large pages"); >> src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, >> heap)("Trying to allocate at address NULL heap of size " >> SIZE_FORMAT_HEX, size + noaccess_prefix); >> src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, >> gc, heap)) { >> src/share/vm/memory/universe.cpp:752: outputStream* logst = >> Log(gc, heap)::info_stream(); >> src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; >> src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; >> >> >> On 4/6/2016 8:26 AM, Thomas St?fe wrote: >>> Hi Rachel, >>> >>> one question, does this change the output for >>> -XX:PrintCompressedOopsMode much? It seems to be wired now to >>> "LOG_TAGS(gc, heap)", which prints much more than just heap >>> reservation for the compressed oops mode. Would it be possible to >>> add a "coops" tag or similar to isolate this output? >>> >>> The reason I ask is that we used this flag extensively when >>> optimizing heap reservation on AIX for compressed oops, and may want >>> to continue using it or an alternative which gives the same output. >>> >>> Kind Regards, Thomas >>> >>> >>> On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio >>> > wrote: >>> >>> Hello, >>> >>> Please review this change, converting -XX:+PrintCompressedOopsMode >>> to -Xlog:gc+heap. The existing diagnostic flag has been aliased to >>> the info level of this tagset (for the "Heap address" message that >>> for example appears in the hs_err file), and there are both debug >>> and trace levels of logging available as well, as per our >>> established schema for assigning levels. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>> >>> >>> Passes JPRT and RBT quick/non-colo tests. >>> >>> Thanks! >>> Rachel >>> >>> >> > From daniel.daugherty at oracle.com Wed Apr 6 23:11:59 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 17:11:59 -0600 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command Message-ID: <570597BF.8070703@oracle.com> Greetings, It appears that the fix for this bug: JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command https://bugs.openjdk.java.net/browse/JDK-4858370 has been causing intermittent test failures in the JDK9-hs-rt nightly. ************************************************************ I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. ************************************************************ This bug is being using to backout JDK-4858370: JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command https://bugs.openjdk.java.net/browse/JDK-8153673 Here is the backout webrev URL: http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ Here are the changeset link for JDK-4858370: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 Jesper and Serguei, thanks, in advance, for the reviews! Gory details below... Dan Here's my jdk repo sanity check note: Daniel Daugherty added a comment - 1 hour ago Sanity checks for backing out this fix and its test: $ hg log -r 277d7584fa03 changeset: 13880:277d7584fa03 parent: 13877:645a9be6eddb user: sgehwolf date: Mon Mar 21 11:24:09 2016 +0100 summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command $ hg status M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c R test/com/sun/jdi/OomDebugTest.java ? files.list $ hg diff -r 13877 `cat files.list ` $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 05:30:48 2016 +0200 +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 14:57:33 2016 -0700 @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ } return error; -} - -/* - * Delete global references from the request which got put there before a - * invoke request was carried out. See fillInvokeRequest() and invoker invoke*() - * impls. - */ -static void -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) -{ - void *cursor; - jint argIndex = 0; - jvalue *argument = request->arguments; - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor); - - if (request->clazz != NULL) { - tossGlobalRef(env, &(request->clazz)); - } - if (request->instance != NULL) { - tossGlobalRef(env, &(request->instance)); - } - /* Delete global argument references */ - while (argIndex < request->argumentCount) { - if ((argumentTag == JDWP_TAG(OBJECT)) || - (argumentTag == JDWP_TAG(ARRAY))) { - if (argument->l != NULL) { - tossGlobalRef(env, &(argument->l)); - } - } - argument++; - argIndex++; - argumentTag = nextArgumentTypeTag(&cursor); - } - /* Delete potentially saved return values */ - if ((request->invokeType == INVOKE_CONSTRUCTOR) || - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { - if (request->returnValue.l != NULL) { - tossGlobalRef(env, &(request->returnValue.l)); - } - } } static jvmtiError @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th (void)outStream_writeObjectRef(env, &out, exc); outStream_sendReply(&out); } - - /* - * At this time, there's no need to retain global references on - * arguments since the reply is processed. No one will deal with - * this request ID anymore, so we must call deleteGlobalRefs(). - */ - deleteGlobalRefs(env, request); } jboolean $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c From daniel.daugherty at oracle.com Wed Apr 6 23:34:50 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 17:34:50 -0600 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command Message-ID: <57059D1A.4060000@oracle.com> Resending with Jesper and Serguei on directly... Greetings, It appears that the fix for this bug: JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command https://bugs.openjdk.java.net/browse/JDK-4858370 has been causing intermittent test failures in the JDK9-hs-rt nightly. ************************************************************ I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. ************************************************************ This bug is being using to backout JDK-4858370: JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command https://bugs.openjdk.java.net/browse/JDK-8153673 Here is the backout webrev URL: http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ Here are the changeset link for JDK-4858370: http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 Jesper and Serguei, thanks, in advance, for the reviews! Gory details below... Dan Here's my jdk repo sanity check note: Daniel Daugherty added a comment - 1 hour ago Sanity checks for backing out this fix and its test: $ hg log -r 277d7584fa03 changeset: 13880:277d7584fa03 parent: 13877:645a9be6eddb user: sgehwolf date: Mon Mar 21 11:24:09 2016 +0100 summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command $ hg status M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c R test/com/sun/jdi/OomDebugTest.java ? files.list $ hg diff -r 13877 `cat files.list ` $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 05:30:48 2016 +0200 +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 14:57:33 2016 -0700 @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ } return error; -} - -/* - * Delete global references from the request which got put there before a - * invoke request was carried out. See fillInvokeRequest() and invoker invoke*() - * impls. - */ -static void -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) -{ - void *cursor; - jint argIndex = 0; - jvalue *argument = request->arguments; - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor); - - if (request->clazz != NULL) { - tossGlobalRef(env, &(request->clazz)); - } - if (request->instance != NULL) { - tossGlobalRef(env, &(request->instance)); - } - /* Delete global argument references */ - while (argIndex < request->argumentCount) { - if ((argumentTag == JDWP_TAG(OBJECT)) || - (argumentTag == JDWP_TAG(ARRAY))) { - if (argument->l != NULL) { - tossGlobalRef(env, &(argument->l)); - } - } - argument++; - argIndex++; - argumentTag = nextArgumentTypeTag(&cursor); - } - /* Delete potentially saved return values */ - if ((request->invokeType == INVOKE_CONSTRUCTOR) || - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { - if (request->returnValue.l != NULL) { - tossGlobalRef(env, &(request->returnValue.l)); - } - } } static jvmtiError @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th (void)outStream_writeObjectRef(env, &out, exc); outStream_sendReply(&out); } - - /* - * At this time, there's no need to retain global references on - * arguments since the reply is processed. No one will deal with - * this request ID anymore, so we must call deleteGlobalRefs(). - */ - deleteGlobalRefs(env, request); } jboolean $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c From jesper.wilhelmsson at oracle.com Wed Apr 6 23:43:55 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 7 Apr 2016 01:43:55 +0200 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57059D1A.4060000@oracle.com> References: <57059D1A.4060000@oracle.com> Message-ID: <57059F3B.1030705@oracle.com> Looks good! /Jesper Den 7/4/16 kl. 01:34, skrev Daniel D. Daugherty: > Resending with Jesper and Serguei on directly... > > Greetings, > > It appears that the fix for this bug: > > JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when processing > invokeMethod command > https://bugs.openjdk.java.net/browse/JDK-4858370 > > has been causing intermittent test failures in the JDK9-hs-rt nightly. > > > ************************************************************ > I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. > ************************************************************ > > > This bug is being using to backout JDK-4858370: > > JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when > processing invokeMethod command > https://bugs.openjdk.java.net/browse/JDK-8153673 > > Here is the backout webrev URL: > > http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ > > Here are the changeset link for JDK-4858370: > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 > > Jesper and Serguei, thanks, in advance, for the reviews! > > Gory details below... > > Dan > > > > Here's my jdk repo sanity check note: > > Daniel Daugherty added a comment - 1 hour ago > Sanity checks for backing out this fix and its test: > > $ hg log -r 277d7584fa03 > changeset: 13880:277d7584fa03 > parent: 13877:645a9be6eddb > user: sgehwolf > date: Mon Mar 21 11:24:09 2016 +0100 > summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when processing > invokeMethod command > > $ hg status > M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > R test/com/sun/jdi/OomDebugTest.java > ? files.list > > $ hg diff -r 13877 `cat files.list ` > > > $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 05:30:48 2016 > +0200 > +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 14:57:33 2016 > -0700 > @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ > } > > return error; > -} > - > -/* > - * Delete global references from the request which got put there before a > - * invoke request was carried out. See fillInvokeRequest() and invoker invoke*() > - * impls. > - */ > -static void > -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) > -{ > - void *cursor; > - jint argIndex = 0; > - jvalue *argument = request->arguments; > - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor); > - > - if (request->clazz != NULL) { > - tossGlobalRef(env, &(request->clazz)); > - } > - if (request->instance != NULL) { > - tossGlobalRef(env, &(request->instance)); > - } > - /* Delete global argument references */ > - while (argIndex < request->argumentCount) { > - if ((argumentTag == JDWP_TAG(OBJECT)) || > - (argumentTag == JDWP_TAG(ARRAY))) { > - if (argument->l != NULL) { > - tossGlobalRef(env, &(argument->l)); > - } > - } > - argument++; > - argIndex++; > - argumentTag = nextArgumentTypeTag(&cursor); > - } > - /* Delete potentially saved return values */ > - if ((request->invokeType == INVOKE_CONSTRUCTOR) || > - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || > - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { > - if (request->returnValue.l != NULL) { > - tossGlobalRef(env, &(request->returnValue.l)); > - } > - } > } > > static jvmtiError > @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th > (void)outStream_writeObjectRef(env, &out, exc); > outStream_sendReply(&out); > } > - > - /* > - * At this time, there's no need to retain global references on > - * arguments since the reply is processed. No one will deal with > - * this request ID anymore, so we must call deleteGlobalRefs(). > - */ > - deleteGlobalRefs(env, request); > } > > jboolean > > $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > > From daniel.daugherty at oracle.com Wed Apr 6 23:45:49 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 17:45:49 -0600 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57059F3B.1030705@oracle.com> References: <57059D1A.4060000@oracle.com> <57059F3B.1030705@oracle.com> Message-ID: <57059FAD.2080105@oracle.com> Thanks! Dan On 4/6/16 5:43 PM, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Den 7/4/16 kl. 01:34, skrev Daniel D. Daugherty: >> Resending with Jesper and Serguei on directly... >> >> Greetings, >> >> It appears that the fix for this bug: >> >> JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when >> processing >> invokeMethod command >> https://bugs.openjdk.java.net/browse/JDK-4858370 >> >> has been causing intermittent test failures in the JDK9-hs-rt nightly. >> >> >> ************************************************************ >> I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. >> ************************************************************ >> >> >> This bug is being using to backout JDK-4858370: >> >> JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never >> deleted when >> processing invokeMethod command >> https://bugs.openjdk.java.net/browse/JDK-8153673 >> >> Here is the backout webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ >> >> Here are the changeset link for JDK-4858370: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 >> >> Jesper and Serguei, thanks, in advance, for the reviews! >> >> Gory details below... >> >> Dan >> >> >> >> Here's my jdk repo sanity check note: >> >> Daniel Daugherty added a comment - 1 hour ago >> Sanity checks for backing out this fix and its test: >> >> $ hg log -r 277d7584fa03 >> changeset: 13880:277d7584fa03 >> parent: 13877:645a9be6eddb >> user: sgehwolf >> date: Mon Mar 21 11:24:09 2016 +0100 >> summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when >> processing >> invokeMethod command >> >> $ hg status >> M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> R test/com/sun/jdi/OomDebugTest.java >> ? files.list >> >> $ hg diff -r 13877 `cat files.list ` >> >> >> $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 >> 05:30:48 2016 >> +0200 >> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 >> 14:57:33 2016 >> -0700 >> @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ >> } >> >> return error; >> -} >> - >> -/* >> - * Delete global references from the request which got put there >> before a >> - * invoke request was carried out. See fillInvokeRequest() and >> invoker invoke*() >> - * impls. >> - */ >> -static void >> -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) >> -{ >> - void *cursor; >> - jint argIndex = 0; >> - jvalue *argument = request->arguments; >> - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, >> &cursor); >> - >> - if (request->clazz != NULL) { >> - tossGlobalRef(env, &(request->clazz)); >> - } >> - if (request->instance != NULL) { >> - tossGlobalRef(env, &(request->instance)); >> - } >> - /* Delete global argument references */ >> - while (argIndex < request->argumentCount) { >> - if ((argumentTag == JDWP_TAG(OBJECT)) || >> - (argumentTag == JDWP_TAG(ARRAY))) { >> - if (argument->l != NULL) { >> - tossGlobalRef(env, &(argument->l)); >> - } >> - } >> - argument++; >> - argIndex++; >> - argumentTag = nextArgumentTypeTag(&cursor); >> - } >> - /* Delete potentially saved return values */ >> - if ((request->invokeType == INVOKE_CONSTRUCTOR) || >> - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || >> - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { >> - if (request->returnValue.l != NULL) { >> - tossGlobalRef(env, &(request->returnValue.l)); >> - } >> - } >> } >> >> static jvmtiError >> @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th >> (void)outStream_writeObjectRef(env, &out, exc); >> outStream_sendReply(&out); >> } >> - >> - /* >> - * At this time, there's no need to retain global references on >> - * arguments since the reply is processed. No one will deal with >> - * this request ID anymore, so we must call deleteGlobalRefs(). >> - */ >> - deleteGlobalRefs(env, request); >> } >> >> jboolean >> >> $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> >> From serguei.spitsyn at oracle.com Wed Apr 6 23:45:41 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Apr 2016 16:45:41 -0700 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57059D1A.4060000@oracle.com> References: <57059D1A.4060000@oracle.com> Message-ID: <57059FA5.9030806@oracle.com> Hi Dan, The fix looks right. Thank you for taking care about the hs-rt stability! It makes sense to back the fix of the 4858370 out at least because it introduced new test that started failing intermittently. The following 3 bugs have similar manifestation and related to the remote invocation of a method or a constructor in the target VM: https://bugs.openjdk.java.net/browse/JDK-8152586 https://bugs.openjdk.java.net/browse/JDK-8152686 https://bugs.openjdk.java.net/browse/JDK-8152985 I'm still in process of isolation of the JDK-8152586 regression. I took a wrong path at some point and need to redo some of my steps. Thanks, Serguei On 4/6/16 16:34, Daniel D. Daugherty wrote: > Resending with Jesper and Serguei on directly... > > Greetings, > > It appears that the fix for this bug: > > JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when > processing > invokeMethod command > https://bugs.openjdk.java.net/browse/JDK-4858370 > > has been causing intermittent test failures in the JDK9-hs-rt nightly. > > > ************************************************************ > I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. > ************************************************************ > > > This bug is being using to backout JDK-4858370: > > JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted > when > processing invokeMethod command > https://bugs.openjdk.java.net/browse/JDK-8153673 > > Here is the backout webrev URL: > > http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ > > Here are the changeset link for JDK-4858370: > > http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 > > Jesper and Serguei, thanks, in advance, for the reviews! > > Gory details below... > > Dan > > > > Here's my jdk repo sanity check note: > > Daniel Daugherty added a comment - 1 hour ago > Sanity checks for backing out this fix and its test: > > $ hg log -r 277d7584fa03 > changeset: 13880:277d7584fa03 > parent: 13877:645a9be6eddb > user: sgehwolf > date: Mon Mar 21 11:24:09 2016 +0100 > summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when > processing invokeMethod command > > $ hg status > M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > R test/com/sun/jdi/OomDebugTest.java > ? files.list > > $ hg diff -r 13877 `cat files.list ` > > > $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 > 05:30:48 2016 +0200 > +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 > 14:57:33 2016 -0700 > @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ > } > > return error; > -} > - > -/* > - * Delete global references from the request which got put there > before a > - * invoke request was carried out. See fillInvokeRequest() and > invoker invoke*() > - * impls. > - */ > -static void > -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) > -{ > - void *cursor; > - jint argIndex = 0; > - jvalue *argument = request->arguments; > - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, > &cursor); > - > - if (request->clazz != NULL) { > - tossGlobalRef(env, &(request->clazz)); > - } > - if (request->instance != NULL) { > - tossGlobalRef(env, &(request->instance)); > - } > - /* Delete global argument references */ > - while (argIndex < request->argumentCount) { > - if ((argumentTag == JDWP_TAG(OBJECT)) || > - (argumentTag == JDWP_TAG(ARRAY))) { > - if (argument->l != NULL) { > - tossGlobalRef(env, &(argument->l)); > - } > - } > - argument++; > - argIndex++; > - argumentTag = nextArgumentTypeTag(&cursor); > - } > - /* Delete potentially saved return values */ > - if ((request->invokeType == INVOKE_CONSTRUCTOR) || > - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || > - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { > - if (request->returnValue.l != NULL) { > - tossGlobalRef(env, &(request->returnValue.l)); > - } > - } > } > > static jvmtiError > @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th > (void)outStream_writeObjectRef(env, &out, exc); > outStream_sendReply(&out); > } > - > - /* > - * At this time, there's no need to retain global references on > - * arguments since the reply is processed. No one will deal with > - * this request ID anymore, so we must call deleteGlobalRefs(). > - */ > - deleteGlobalRefs(env, request); > } > > jboolean > > $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c > > From daniel.daugherty at oracle.com Wed Apr 6 23:51:35 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Apr 2016 17:51:35 -0600 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <57059FA5.9030806@oracle.com> References: <57059D1A.4060000@oracle.com> <57059FA5.9030806@oracle.com> Message-ID: <5705A107.1030105@oracle.com> On 4/6/16 5:45 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > The fix looks right. Thanks! > Thank you for taking care about the hs-rt stability! You are very welcome. > It makes sense to back the fix of the 4858370 out at least because > it introduced new test that started failing intermittently. > > The following 3 bugs have similar manifestation and related to the > remote invocation > of a method or a constructor in the target VM: > https://bugs.openjdk.java.net/browse/JDK-8152586 > https://bugs.openjdk.java.net/browse/JDK-8152686 > https://bugs.openjdk.java.net/browse/JDK-8152985 I wasn't sure that JDK-8152586 was part of the mix because I thought it was first spotted before JDK-4858370 was pushed... but I based that guess on your notes... I suspect that the cleanup of the global refs is happening too early and some things that were relying on those globals refs are now unhappy... but it has been a long time since I've been in that code... Dan > > > I'm still in process of isolation of the JDK-8152586 regression. > I took a wrong path at some point and need to redo some of my steps. > > Thanks, > Serguei > > > On 4/6/16 16:34, Daniel D. Daugherty wrote: >> Resending with Jesper and Serguei on directly... >> >> Greetings, >> >> It appears that the fix for this bug: >> >> JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when >> processing >> invokeMethod command >> https://bugs.openjdk.java.net/browse/JDK-4858370 >> >> has been causing intermittent test failures in the JDK9-hs-rt nightly. >> >> >> ************************************************************ >> I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. >> ************************************************************ >> >> >> This bug is being using to backout JDK-4858370: >> >> JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted >> when >> processing invokeMethod command >> https://bugs.openjdk.java.net/browse/JDK-8153673 >> >> Here is the backout webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ >> >> Here are the changeset link for JDK-4858370: >> >> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 >> >> Jesper and Serguei, thanks, in advance, for the reviews! >> >> Gory details below... >> >> Dan >> >> >> >> Here's my jdk repo sanity check note: >> >> Daniel Daugherty added a comment - 1 hour ago >> Sanity checks for backing out this fix and its test: >> >> $ hg log -r 277d7584fa03 >> changeset: 13880:277d7584fa03 >> parent: 13877:645a9be6eddb >> user: sgehwolf >> date: Mon Mar 21 11:24:09 2016 +0100 >> summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when >> processing invokeMethod command >> >> $ hg status >> M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> R test/com/sun/jdi/OomDebugTest.java >> ? files.list >> >> $ hg diff -r 13877 `cat files.list ` >> >> >> $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 >> 05:30:48 2016 +0200 >> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 >> 14:57:33 2016 -0700 >> @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ >> } >> >> return error; >> -} >> - >> -/* >> - * Delete global references from the request which got put there >> before a >> - * invoke request was carried out. See fillInvokeRequest() and >> invoker invoke*() >> - * impls. >> - */ >> -static void >> -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) >> -{ >> - void *cursor; >> - jint argIndex = 0; >> - jvalue *argument = request->arguments; >> - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, >> &cursor); >> - >> - if (request->clazz != NULL) { >> - tossGlobalRef(env, &(request->clazz)); >> - } >> - if (request->instance != NULL) { >> - tossGlobalRef(env, &(request->instance)); >> - } >> - /* Delete global argument references */ >> - while (argIndex < request->argumentCount) { >> - if ((argumentTag == JDWP_TAG(OBJECT)) || >> - (argumentTag == JDWP_TAG(ARRAY))) { >> - if (argument->l != NULL) { >> - tossGlobalRef(env, &(argument->l)); >> - } >> - } >> - argument++; >> - argIndex++; >> - argumentTag = nextArgumentTypeTag(&cursor); >> - } >> - /* Delete potentially saved return values */ >> - if ((request->invokeType == INVOKE_CONSTRUCTOR) || >> - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || >> - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { >> - if (request->returnValue.l != NULL) { >> - tossGlobalRef(env, &(request->returnValue.l)); >> - } >> - } >> } >> >> static jvmtiError >> @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th >> (void)outStream_writeObjectRef(env, &out, exc); >> outStream_sendReply(&out); >> } >> - >> - /* >> - * At this time, there's no need to retain global references on >> - * arguments since the reply is processed. No one will deal with >> - * this request ID anymore, so we must call deleteGlobalRefs(). >> - */ >> - deleteGlobalRefs(env, request); >> } >> >> jboolean >> >> $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >> >> > From serguei.spitsyn at oracle.com Wed Apr 6 23:58:30 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 6 Apr 2016 16:58:30 -0700 Subject: URGENT RFR 8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never deleted when processing invokeMethod command In-Reply-To: <5705A107.1030105@oracle.com> References: <57059D1A.4060000@oracle.com> <57059FA5.9030806@oracle.com> <5705A107.1030105@oracle.com> Message-ID: <5705A2A6.60505@oracle.com> On 4/6/16 16:51, Daniel D. Daugherty wrote: > On 4/6/16 5:45 PM, serguei.spitsyn at oracle.com wrote: >> Hi Dan, >> >> The fix looks right. > > Thanks! > > >> Thank you for taking care about the hs-rt stability! > > You are very welcome. > > >> It makes sense to back the fix of the 4858370 out at least because >> it introduced new test that started failing intermittently. >> >> The following 3 bugs have similar manifestation and related to the >> remote invocation >> of a method or a constructor in the target VM: >> https://bugs.openjdk.java.net/browse/JDK-8152586 >> https://bugs.openjdk.java.net/browse/JDK-8152686 >> https://bugs.openjdk.java.net/browse/JDK-8152985 > > I wasn't sure that JDK-8152586 was part of the mix because I > thought it was first spotted before JDK-4858370 was pushed... > but I based that guess on your notes... > > I suspect that the cleanup of the global refs is happening > too early and some things that were relying on those globals > refs are now unhappy... but it has been a long time since I've > been in that code... I meditated on the JDK-4858370 fix for some time but did not find anything specifically wrong and was of guesses. One issue with this fix is that it is impossible to track the issue back. Earlier jprt builds fail with OOM on new test as it checks that GlobalRefs are properly deleted. Thanks, Serguei > > Dan > > >> >> >> I'm still in process of isolation of the JDK-8152586 regression. >> I took a wrong path at some point and need to redo some of my steps. >> >> Thanks, >> Serguei >> >> >> On 4/6/16 16:34, Daniel D. Daugherty wrote: >>> Resending with Jesper and Serguei on directly... >>> >>> Greetings, >>> >>> It appears that the fix for this bug: >>> >>> JDK-4858370 JDWP: Memory Leak: GlobalRefs never deleted when >>> processing >>> invokeMethod command >>> https://bugs.openjdk.java.net/browse/JDK-4858370 >>> >>> has been causing intermittent test failures in the JDK9-hs-rt nightly. >>> >>> >>> ************************************************************ >>> I need reviews from Jesper Wilhelmsson and Serguei Spitsyn. >>> ************************************************************ >>> >>> >>> This bug is being using to backout JDK-4858370: >>> >>> JDK-8153673 [BACKOUT] JDWP: Memory Leak: GlobalRefs never >>> deleted when >>> processing invokeMethod command >>> https://bugs.openjdk.java.net/browse/JDK-8153673 >>> >>> Here is the backout webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8153673-webrev/0-jdk9-hs-rt-jdk/ >>> >>> Here are the changeset link for JDK-4858370: >>> >>> http://hg.openjdk.java.net/jdk9/hs-rt/jdk/rev/277d7584fa03 >>> >>> Jesper and Serguei, thanks, in advance, for the reviews! >>> >>> Gory details below... >>> >>> Dan >>> >>> >>> >>> Here's my jdk repo sanity check note: >>> >>> Daniel Daugherty added a comment - 1 hour ago >>> Sanity checks for backing out this fix and its test: >>> >>> $ hg log -r 277d7584fa03 >>> changeset: 13880:277d7584fa03 >>> parent: 13877:645a9be6eddb >>> user: sgehwolf >>> date: Mon Mar 21 11:24:09 2016 +0100 >>> summary: 4858370: JDWP: Memory Leak: GlobalRefs never deleted when >>> processing invokeMethod command >>> >>> $ hg status >>> M src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >>> R test/com/sun/jdi/OomDebugTest.java >>> ? files.list >>> >>> $ hg diff -r 13877 `cat files.list ` >>> >>> >>> $ hg diff src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >>> diff -r 96b1cfa80016 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >>> --- a/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Sat Apr 02 >>> 05:30:48 2016 +0200 >>> +++ b/src/jdk.jdwp.agent/share/native/libjdwp/invoker.c Wed Apr 06 >>> 14:57:33 2016 -0700 >>> @@ -209,47 +209,6 @@ createGlobalRefs(JNIEnv *env, InvokeRequ >>> } >>> >>> return error; >>> -} >>> - >>> -/* >>> - * Delete global references from the request which got put there >>> before a >>> - * invoke request was carried out. See fillInvokeRequest() and >>> invoker invoke*() >>> - * impls. >>> - */ >>> -static void >>> -deleteGlobalRefs(JNIEnv *env, InvokeRequest *request) >>> -{ >>> - void *cursor; >>> - jint argIndex = 0; >>> - jvalue *argument = request->arguments; >>> - jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, >>> &cursor); >>> - >>> - if (request->clazz != NULL) { >>> - tossGlobalRef(env, &(request->clazz)); >>> - } >>> - if (request->instance != NULL) { >>> - tossGlobalRef(env, &(request->instance)); >>> - } >>> - /* Delete global argument references */ >>> - while (argIndex < request->argumentCount) { >>> - if ((argumentTag == JDWP_TAG(OBJECT)) || >>> - (argumentTag == JDWP_TAG(ARRAY))) { >>> - if (argument->l != NULL) { >>> - tossGlobalRef(env, &(argument->l)); >>> - } >>> - } >>> - argument++; >>> - argIndex++; >>> - argumentTag = nextArgumentTypeTag(&cursor); >>> - } >>> - /* Delete potentially saved return values */ >>> - if ((request->invokeType == INVOKE_CONSTRUCTOR) || >>> - (returnTypeTag(request->methodSignature) == JDWP_TAG(OBJECT)) || >>> - (returnTypeTag(request->methodSignature) == JDWP_TAG(ARRAY))) { >>> - if (request->returnValue.l != NULL) { >>> - tossGlobalRef(env, &(request->returnValue.l)); >>> - } >>> - } >>> } >>> >>> static jvmtiError >>> @@ -777,13 +736,6 @@ invoker_completeInvokeRequest(jthread th >>> (void)outStream_writeObjectRef(env, &out, exc); >>> outStream_sendReply(&out); >>> } >>> - >>> - /* >>> - * At this time, there's no need to retain global references on >>> - * arguments since the reply is processed. No one will deal with >>> - * this request ID anymore, so we must call deleteGlobalRefs(). >>> - */ >>> - deleteGlobalRefs(env, request); >>> } >>> >>> jboolean >>> >>> $ hg diff -r 13877 src/jdk.jdwp.agent/share/native/libjdwp/invoker.c >>> >>> >> > From thomas.stuefe at gmail.com Thu Apr 7 07:28:58 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Apr 2016 09:28:58 +0200 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <570530F9.8000901@oracle.com> References: <5703FD3B.10307@oracle.com> <570530F9.8000901@oracle.com> Message-ID: Hi Rachel, On Wed, Apr 6, 2016 at 5:53 PM, Rachel Protacio wrote: > Hi, > > Thanks for the response. Yes, there is other gc+heap logging already > present. As you can see from the grep below, there are a number of other > messages, especially in the trace level (which is to be expected as verbose > anyway). Additionally, there's the question of which level should be > aliased to. Right now, I have it at the info level, which just prints the > "Heap address" line but I could make it debug level to print the other ones > from virtualspace.cpp. > > I'm fine with adding another tag, but I want to make sure we have a > consensus before I do so. Does anyone else want to weigh in? > > Thanks, > Rachel > > Thank you for considering this. It would be nice to have but is not terribly important. Thomas > > > src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS ergo > set MaxNewSize: " SIZE_FORMAT, MaxNewSize); > src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, heap)("CMS set > min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT " > max_heap: " SIZE_FORMAT, > src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, heap)("CMS > ergo set NewSize: " SIZE_FORMAT, NewSize); > src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, heap)("CMS > ergo set OldSize: " SIZE_FORMAT, OldSize); > src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, > heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT > src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" Maximum > heap size " SIZE_FORMAT, (size_t) reasonable_max); > src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, heap)(" > Initial heap size " SIZE_FORMAT, (size_t)reasonable_initial); > src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, heap)(" > Minimum heap size " SIZE_FORMAT, min_heap_size()); > src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, > heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " Maximum > heap " SIZE_FORMAT, > src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, heap)("1: > Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT " Maximum young > " SIZE_FORMAT, > src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, heap)("2: > Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT " Maximum young > " SIZE_FORMAT, > src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, > heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " Maximum > old " SIZE_FORMAT, > src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, > heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " > SIZE_FORMAT "K", > src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, > heap)("Garbage collection disabled, expanded heap instead"); > src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, > heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", > src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, > heap)("TenuredGeneration::compute_new_size:"); > src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, heap)(" > minimum_free_percentage: %6.2f maximum_used_percentage: %6.2f", > src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, > heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK > capacity_after_gc : %6.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, > heap)(" free_percentage: %6.2f", free_percentage); > src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, heap)(" > expanding: minimum_desired_capacity: %6.1fK expand_bytes: %6.1fK > _min_heap_delta_bytes: %6.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, heap)(" > maximum_free_percentage: %6.2f minimum_used_percentage: %6.2f", > src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, heap)(" > _capacity_at_prologue: %6.1fK minimum_desired_capacity: %6.1fK > maximum_desired_capacity: %6.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, > heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: %.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, > heap)(" shrink_bytes: %.1fK current_shrink_factor: " SIZE_FORMAT " new > shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: %.1fK", > src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, heap)(" > aggressive shrinking: _capacity_at_prologue: %.1fK capacity_after_gc: > %.1fK expansion_for_promotion: %.1fK shrink_bytes: %.1fK", > src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, heap)("%s: > " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, heap)("%s: > " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: " > SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, heap)("%s: " > SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, heap) > log; > src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: log_info(gc, > heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", > src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap region > size: " SIZE_FORMAT "M", GrainBytes / M); > src/share/vm/gc/g1/g1HeapTransition.cpp:89: if (log_is_enabled(Trace, gc, > heap)) { > src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, heap)("Eden > regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" SIZE_FORMAT ")", > src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" Used: > 0K, Waste: 0K"); > src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, heap)("Survivor > regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" SIZE_FORMAT ")", > src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" Used: > " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", > src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, heap)("Old > regions: " SIZE_FORMAT "->" SIZE_FORMAT, > src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" Used: > " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", > src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, > heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, > src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" Used: > " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", > src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, heap)("Reserved > memory not at requested address: " PTR_FORMAT " vs " PTR_FORMAT, p2i(base), > p2i(requested_address)); > src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, > heap)("Reserve regular memory without large pages"); > src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, > heap)("Protected page at the reserved heap base: " > src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, heap)("Trying to > allocate at address " PTR_FORMAT > src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, > heap)("Reserve regular memory without large pages"); > src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, heap)("Trying > to allocate at address NULL heap of size " SIZE_FORMAT_HEX, size + > noaccess_prefix); > src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, gc, > heap)) { > src/share/vm/memory/universe.cpp:752: outputStream* logst = Log(gc, > heap)::info_stream(); > src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; > src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; > > > On 4/6/2016 8:26 AM, Thomas St?fe wrote: > > Hi Rachel, > > one question, does this change the output for -XX:PrintCompressedOopsMode > much? It seems to be wired now to "LOG_TAGS(gc, heap)", which prints much > more than just heap reservation for the compressed oops mode. Would it be > possible to add a "coops" tag or similar to isolate this output? > > The reason I ask is that we used this flag extensively when optimizing > heap reservation on AIX for compressed oops, and may want to continue using > it or an alternative which gives the same output. > > Kind Regards, Thomas > > > On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio < > rachel.protacio at oracle.com> wrote: > >> Hello, >> >> Please review this change, converting -XX:+PrintCompressedOopsMode to >> -Xlog:gc+heap. The existing diagnostic flag has been aliased to the info >> level of this tagset (for the "Heap address" message that for example >> appears in the hs_err file), and there are both debug and trace levels of >> logging available as well, as per our established schema for assigning >> levels. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >> >> Passes JPRT and RBT quick/non-colo tests. >> >> Thanks! >> Rachel >> > > > From cheleswer.sahu at oracle.com Thu Apr 7 13:50:21 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 7 Apr 2016 06:50:21 -0700 (PDT) Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: <5703BDD1.5090108@oracle.com> References: <5703BDD1.5090108@oracle.com> Message-ID: Hi , Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below link http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ Regards, Cheleswer -----Original Message----- From: Leonid Mesnik Sent: Tuesday, April 05, 2016 7:00 PM To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Hi I don't think that sleep is a good way to ensure that thread is started. It is not reliable on the slow host / VM under stress and just waste of time on fast host. Is it possible just to add any explicit synchronization to ensure that NamedThread is started? Leonid On 05.04.2016 13:23, Cheleswer Sahu wrote: > Hi, > > > > Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. > > > > Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ > > > > > > Bug Brief: Test is failing on some platforms. > > > > Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. > > > > Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. > > > > > > Regards, > > Cheleswer > > > > From Leonid.Mesnik at oracle.com Thu Apr 7 13:53:56 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 7 Apr 2016 16:53:56 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: <5703BDD1.5090108@oracle.com> Message-ID: <57066674.9080502@oracle.com> Hi Thank you for improving test stability. I am fine with fix. I am not 'R'eviewer so you still need to get official review. Leonid On 07.04.2016 16:50, Cheleswer Sahu wrote: > Hi , > Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below link > > http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ > > > Regards, > Cheleswer > -----Original Message----- > From: Leonid Mesnik > Sent: Tuesday, April 05, 2016 7:00 PM > To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails > > Hi > > I don't think that sleep is a good way to ensure that thread is started. > It is not reliable on the slow host / VM under stress and just waste of time on fast host. > Is it possible just to add any explicit synchronization to ensure that NamedThread is started? > > Leonid > > On 05.04.2016 13:23, Cheleswer Sahu wrote: >> Hi, >> >> >> >> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. >> >> >> >> Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ >> >> >> >> >> >> Bug Brief: Test is failing on some platforms. >> >> >> >> Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. >> >> >> >> Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. >> >> >> >> >> >> Regards, >> >> Cheleswer >> >> >> >> From coleen.phillimore at oracle.com Thu Apr 7 14:02:00 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 7 Apr 2016 10:02:00 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5705632B.9090006@oracle.com> References: <5703FD3B.10307@oracle.com> <570530F9.8000901@oracle.com> <57055EE8.1020209@oracle.com> <5705632B.9090006@oracle.com> Message-ID: <57066858.3020709@oracle.com> I think this looks really good! Coleen On 4/6/16 3:27 PM, Rachel Protacio wrote: > Ok, I've gone ahead and added the 'coops' tag, making this conversion > PrintCompressedOopsMode -> -Xlog:gc+heap+coops > > New webrev: http://cr.openjdk.java.net/~rprotacio/8152896.01 > > Also deleted ending periods in log messages, removed > "UnlockDiagnosticVMOptions" from tests where it is now unnecessary, > and @require'd 64 bit in the new test. > > Thanks, > Rachel > > On 4/6/2016 3:09 PM, Coleen Phillimore wrote: >> >> I think adding the coops tag to isolate this logging from all the >> other GC logging is a good idea. The name "coops" to mean >> "compressed oops" for the tag has meaning for us in the vm so it's >> not a bad abbreviation. >> >> Coleen >> >> On 4/6/16 11:53 AM, Rachel Protacio wrote: >>> Hi, >>> >>> Thanks for the response. Yes, there is other gc+heap logging already >>> present. As you can see from the grep below, there are a number of >>> other messages, especially in the trace level (which is to be >>> expected as verbose anyway). Additionally, there's the question of >>> which level should be aliased to. Right now, I have it at the info >>> level, which just prints the "Heap address" line but I could make it >>> debug level to print the other ones from virtualspace.cpp. >>> >>> I'm fine with adding another tag, but I want to make sure we have a >>> consensus before I do so. Does anyone else want to weigh in? >>> >>> Thanks, >>> Rachel >>> >>> >>> >>> src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS >>> ergo set MaxNewSize: " SIZE_FORMAT, MaxNewSize); >>> src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, heap)("CMS >>> set min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT >>> " max_heap: " SIZE_FORMAT, >>> src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, >>> heap)("CMS ergo set NewSize: " SIZE_FORMAT, NewSize); >>> src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, >>> heap)("CMS ergo set OldSize: " SIZE_FORMAT, OldSize); >>> src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, >>> heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT >>> src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" >>> Maximum heap size " SIZE_FORMAT, (size_t) reasonable_max); >>> src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, >>> heap)(" Initial heap size " SIZE_FORMAT, >>> (size_t)reasonable_initial); >>> src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, >>> heap)(" Minimum heap size " SIZE_FORMAT, min_heap_size()); >>> src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, >>> heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " >>> Maximum heap " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, >>> heap)("1: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT >>> " Maximum young " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, >>> heap)("2: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT >>> " Maximum young " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, >>> heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " >>> Maximum old " SIZE_FORMAT, >>> src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, >>> heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " >>> SIZE_FORMAT "K", >>> src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, >>> heap)("Garbage collection disabled, expanded heap instead"); >>> src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, >>> heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", >>> src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, >>> heap)("TenuredGeneration::compute_new_size:"); >>> src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, >>> heap)(" minimum_free_percentage: %6.2f maximum_used_percentage: >>> %6.2f", >>> src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, >>> heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK >>> capacity_after_gc : %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, >>> heap)(" free_percentage: %6.2f", free_percentage); >>> src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, >>> heap)(" expanding: minimum_desired_capacity: %6.1fK >>> expand_bytes: %6.1fK _min_heap_delta_bytes: %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, >>> heap)(" maximum_free_percentage: %6.2f minimum_used_percentage: >>> %6.2f", >>> src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, >>> heap)(" _capacity_at_prologue: %6.1fK minimum_desired_capacity: >>> %6.1fK maximum_desired_capacity: %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, >>> heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: >>> %.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, >>> heap)(" shrink_bytes: %.1fK current_shrink_factor: " SIZE_FORMAT >>> " new shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: %.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, >>> heap)(" aggressive shrinking: _capacity_at_prologue: %.1fK >>> capacity_after_gc: %.1fK expansion_for_promotion: %.1fK >>> shrink_bytes: %.1fK", >>> src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: >>> " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, >>> heap) log; >>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: >>> log_info(gc, heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" >>> SIZE_FORMAT "K)", >>> src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap >>> region size: " SIZE_FORMAT "M", GrainBytes / M); >>> src/share/vm/gc/g1/g1HeapTransition.cpp:89: if >>> (log_is_enabled(Trace, gc, heap)) { >>> src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, >>> heap)("Eden regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>> SIZE_FORMAT ")", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" >>> Used: 0K, Waste: 0K"); >>> src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, >>> heap)("Survivor regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>> SIZE_FORMAT ")", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, >>> heap)("Old regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>> src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, >>> heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>> src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, >>> heap)("Reserved memory not at requested address: " PTR_FORMAT " vs " >>> PTR_FORMAT, p2i(base), p2i(requested_address)); >>> src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, >>> heap)("Reserve regular memory without large pages"); >>> src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, >>> heap)("Protected page at the reserved heap base: " >>> src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, >>> heap)("Trying to allocate at address " PTR_FORMAT >>> src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, >>> heap)("Reserve regular memory without large pages"); >>> src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, >>> heap)("Trying to allocate at address NULL heap of size " >>> SIZE_FORMAT_HEX, size + noaccess_prefix); >>> src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, >>> gc, heap)) { >>> src/share/vm/memory/universe.cpp:752: outputStream* logst = >>> Log(gc, heap)::info_stream(); >>> src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; >>> src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; >>> >>> >>> On 4/6/2016 8:26 AM, Thomas St?fe wrote: >>>> Hi Rachel, >>>> >>>> one question, does this change the output for >>>> -XX:PrintCompressedOopsMode much? It seems to be wired now to >>>> "LOG_TAGS(gc, heap)", which prints much more than just heap >>>> reservation for the compressed oops mode. Would it be possible to >>>> add a "coops" tag or similar to isolate this output? >>>> >>>> The reason I ask is that we used this flag extensively when >>>> optimizing heap reservation on AIX for compressed oops, and may >>>> want to continue using it or an alternative which gives the same >>>> output. >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio >>>> > >>>> wrote: >>>> >>>> Hello, >>>> >>>> Please review this change, converting -XX:+PrintCompressedOopsMode >>>> to -Xlog:gc+heap. The existing diagnostic flag has been aliased to >>>> the info level of this tagset (for the "Heap address" message that >>>> for example appears in the hs_err file), and there are both debug >>>> and trace levels of logging available as well, as per our >>>> established schema for assigning levels. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>>> >>>> >>>> Passes JPRT and RBT quick/non-colo tests. >>>> >>>> Thanks! >>>> Rachel >>>> >>>> >>> >> > From dmitry.samersoff at oracle.com Thu Apr 7 14:12:08 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 7 Apr 2016 17:12:08 +0300 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: References: <5703BDD1.5090108@oracle.com> Message-ID: <57066AB8.4000808@oracle.com> Cheleswer, Looks good for me. Reviewed. -Dmitry On 2016-04-07 16:50, Cheleswer Sahu wrote: > Hi , > Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below link > > http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ > > > Regards, > Cheleswer > -----Original Message----- > From: Leonid Mesnik > Sent: Tuesday, April 05, 2016 7:00 PM > To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net > Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails > > Hi > > I don't think that sleep is a good way to ensure that thread is started. > It is not reliable on the slow host / VM under stress and just waste of time on fast host. > Is it possible just to add any explicit synchronization to ensure that NamedThread is started? > > Leonid > > On 05.04.2016 13:23, Cheleswer Sahu wrote: >> Hi, >> >> >> >> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. >> >> >> >> Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ >> >> >> >> >> >> Bug Brief: Test is failing on some platforms. >> >> >> >> Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. >> >> >> >> Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. >> >> >> >> >> >> Regards, >> >> Cheleswer >> >> >> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Thu Apr 7 14:13:25 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 7 Apr 2016 23:13:25 +0900 Subject: RFR: JDK-8153743: AllocateHeap() and ReallocateHeap() should use ALWAYSINLINE macro Message-ID: <57066B05.3030906@gmail.com> For force inlining, JDK-8076212 uses always_inline attribute to them. JDK-8151593 added ALWAYSINLINE macro for force inlining. For consistency, and for other compiler support, AllocateHeap() and ReallocateHeap() should use ALWAYSINLINE. I used ALWAYSINLINE to them, but I got error message as below; ------------------------------ Building target 'images' in configuration 'linux-x86_64-normal-server-release' In file included from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/utilities/array.hpp:29:0, from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/memory/universe.hpp:29, from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/code/oopRecorder.hpp:28, from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/asm/codeBuffer.hpp:28, from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/asm/assembler.hpp:28, from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/precompiled/precompiled.hpp:29: /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/memory/allocation.inline.hpp:72:20: ???: always_inline function might not be inlinable [-Werror=attributes] ALWAYSINLINE char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, ^ ------------------------------ * This message includes Japanese because my environment is Japanese locale :-) According to GCC manual [1], non-static inline function is always compiled on its own in the usual fashion. However, we can compile as inline function with "inline" and "always_inline". always_inline attribute does not imply inlining [2]. GCC testcase [3] uses both "inline" and "always_inline" actually. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8153743/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html [2] https://chromiumcodereview.appspot.com/14820003/ [3] https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/vmx/gcc-bug-i.c?view=markup&pathrev=178730 From daniel.daugherty at oracle.com Thu Apr 7 14:22:27 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Apr 2016 08:22:27 -0600 Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: <57066AB8.4000808@oracle.com> References: <5703BDD1.5090108@oracle.com> <57066AB8.4000808@oracle.com> Message-ID: <57066D23.4090505@oracle.com> Cheleswer, When you re-sync with the current JDK9-hs-rt, you'll have to re-enable this test. It was quarantined yesterday with this fix: JDK-8153671 Quarantine serviceability/tmtools/jstack/JstackThreadTest.java until JDK-8153319 is fixed https://bugs.openjdk.java.net/browse/JDK-8153671 You just need to remove the @ignore line. Dan On 4/7/16 8:12 AM, Dmitry Samersoff wrote: > Cheleswer, > > Looks good for me. Reviewed. > > -Dmitry > > On 2016-04-07 16:50, Cheleswer Sahu wrote: >> Hi , >> Thanks for your review and suggestion. I agree that sleep is not the best and reliable way to achieve the objective of test case. I also found the idea of using j.u.c.CountDownLatch very easy and effective. I have made some changes in the code. Please review the code changes in the below link >> >> http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ >> >> >> Regards, >> Cheleswer >> -----Original Message----- >> From: Leonid Mesnik >> Sent: Tuesday, April 05, 2016 7:00 PM >> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails >> >> Hi >> >> I don't think that sleep is a good way to ensure that thread is started. >> It is not reliable on the slow host / VM under stress and just waste of time on fast host. >> Is it possible just to add any explicit synchronization to ensure that NamedThread is started? >> >> Leonid >> >> On 05.04.2016 13:23, Cheleswer Sahu wrote: >>> Hi, >>> >>> >>> >>> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. >>> >>> >>> >>> Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ >>> >>> >>> >>> >>> >>> Bug Brief: Test is failing on some platforms. >>> >>> >>> >>> Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. >>> >>> >>> >>> Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Cheleswer >>> >>> >>> >>> > From rachel.protacio at oracle.com Thu Apr 7 15:02:49 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 7 Apr 2016 11:02:49 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <57066858.3020709@oracle.com> References: <5703FD3B.10307@oracle.com> <570530F9.8000901@oracle.com> <57055EE8.1020209@oracle.com> <5705632B.9090006@oracle.com> <57066858.3020709@oracle.com> Message-ID: <57067699.1050302@oracle.com> Thanks, Coleen! Rachel On 4/7/2016 10:02 AM, Coleen Phillimore wrote: > > I think this looks really good! > Coleen > > > On 4/6/16 3:27 PM, Rachel Protacio wrote: >> Ok, I've gone ahead and added the 'coops' tag, making this conversion >> PrintCompressedOopsMode -> -Xlog:gc+heap+coops >> >> New webrev: http://cr.openjdk.java.net/~rprotacio/8152896.01 >> >> Also deleted ending periods in log messages, removed >> "UnlockDiagnosticVMOptions" from tests where it is now unnecessary, >> and @require'd 64 bit in the new test. >> >> Thanks, >> Rachel >> >> On 4/6/2016 3:09 PM, Coleen Phillimore wrote: >>> >>> I think adding the coops tag to isolate this logging from all the >>> other GC logging is a good idea. The name "coops" to mean >>> "compressed oops" for the tag has meaning for us in the vm so it's >>> not a bad abbreviation. >>> >>> Coleen >>> >>> On 4/6/16 11:53 AM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> Thanks for the response. Yes, there is other gc+heap logging >>>> already present. As you can see from the grep below, there are a >>>> number of other messages, especially in the trace level (which is >>>> to be expected as verbose anyway). Additionally, there's the >>>> question of which level should be aliased to. Right now, I have it >>>> at the info level, which just prints the "Heap address" line but I >>>> could make it debug level to print the other ones from >>>> virtualspace.cpp. >>>> >>>> I'm fine with adding another tag, but I want to make sure we have a >>>> consensus before I do so. Does anyone else want to weigh in? >>>> >>>> Thanks, >>>> Rachel >>>> >>>> >>>> >>>> src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS >>>> ergo set MaxNewSize: " SIZE_FORMAT, MaxNewSize); >>>> src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, >>>> heap)("CMS >>>> set min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT >>>> " max_heap: " SIZE_FORMAT, >>>> src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, >>>> heap)("CMS ergo set NewSize: " SIZE_FORMAT, NewSize); >>>> src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, >>>> heap)("CMS ergo set OldSize: " SIZE_FORMAT, OldSize); >>>> src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, >>>> heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT >>>> src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" >>>> Maximum heap size " SIZE_FORMAT, (size_t) reasonable_max); >>>> src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, >>>> heap)(" Initial heap size " SIZE_FORMAT, >>>> (size_t)reasonable_initial); >>>> src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, >>>> heap)(" Minimum heap size " SIZE_FORMAT, min_heap_size()); >>>> src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, >>>> heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " >>>> Maximum heap " SIZE_FORMAT, >>>> src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, >>>> heap)("1: Minimum young " SIZE_FORMAT " Initial young " >>>> SIZE_FORMAT >>>> " Maximum young " SIZE_FORMAT, >>>> src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, >>>> heap)("2: Minimum young " SIZE_FORMAT " Initial young " >>>> SIZE_FORMAT >>>> " Maximum young " SIZE_FORMAT, >>>> src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, >>>> heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " >>>> Maximum old " SIZE_FORMAT, >>>> src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, >>>> heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " >>>> SIZE_FORMAT "K", >>>> src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, >>>> heap)("Garbage collection disabled, expanded heap instead"); >>>> src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, >>>> heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", >>>> src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, >>>> heap)("TenuredGeneration::compute_new_size:"); >>>> src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, >>>> heap)(" minimum_free_percentage: %6.2f maximum_used_percentage: >>>> %6.2f", >>>> src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, >>>> heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK >>>> capacity_after_gc : %6.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, >>>> heap)(" free_percentage: %6.2f", free_percentage); >>>> src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, >>>> heap)(" expanding: minimum_desired_capacity: %6.1fK >>>> expand_bytes: %6.1fK _min_heap_delta_bytes: %6.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, >>>> heap)(" maximum_free_percentage: %6.2f minimum_used_percentage: >>>> %6.2f", >>>> src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, >>>> heap)(" _capacity_at_prologue: %6.1fK minimum_desired_capacity: >>>> %6.1fK maximum_desired_capacity: %6.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, >>>> heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: >>>> %.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, >>>> heap)(" shrink_bytes: %.1fK current_shrink_factor: " >>>> SIZE_FORMAT >>>> " new shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: >>>> %.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, >>>> heap)(" aggressive shrinking: _capacity_at_prologue: %.1fK >>>> capacity_after_gc: %.1fK expansion_for_promotion: %.1fK >>>> shrink_bytes: %.1fK", >>>> src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, >>>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>>> src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, >>>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>>> src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: >>>> " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>>> src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, >>>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, >>>> heap) log; >>>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: >>>> log_info(gc, heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" >>>> SIZE_FORMAT "K)", >>>> src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap >>>> region size: " SIZE_FORMAT "M", GrainBytes / M); >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:89: if >>>> (log_is_enabled(Trace, gc, heap)) { >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, >>>> heap)("Eden regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>>> SIZE_FORMAT ")", >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" >>>> Used: 0K, Waste: 0K"); >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, >>>> heap)("Survivor regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>>> SIZE_FORMAT ")", >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" >>>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, >>>> heap)("Old regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" >>>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, >>>> heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" >>>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>>> src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, >>>> heap)("Reserved memory not at requested address: " PTR_FORMAT " >>>> vs " >>>> PTR_FORMAT, p2i(base), p2i(requested_address)); >>>> src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, >>>> heap)("Reserve regular memory without large pages"); >>>> src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, >>>> heap)("Protected page at the reserved heap base: " >>>> src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, >>>> heap)("Trying to allocate at address " PTR_FORMAT >>>> src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, >>>> heap)("Reserve regular memory without large pages"); >>>> src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, >>>> heap)("Trying to allocate at address NULL heap of size " >>>> SIZE_FORMAT_HEX, size + noaccess_prefix); >>>> src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, >>>> gc, heap)) { >>>> src/share/vm/memory/universe.cpp:752: outputStream* logst = >>>> Log(gc, heap)::info_stream(); >>>> src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; >>>> src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; >>>> >>>> >>>> On 4/6/2016 8:26 AM, Thomas St?fe wrote: >>>>> Hi Rachel, >>>>> >>>>> one question, does this change the output for >>>>> -XX:PrintCompressedOopsMode much? It seems to be wired now to >>>>> "LOG_TAGS(gc, heap)", which prints much more than just heap >>>>> reservation for the compressed oops mode. Would it be possible to >>>>> add a "coops" tag or similar to isolate this output? >>>>> >>>>> The reason I ask is that we used this flag extensively when >>>>> optimizing heap reservation on AIX for compressed oops, and may >>>>> want to continue using it or an alternative which gives the same >>>>> output. >>>>> >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>> On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio >>>>> > >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review this change, converting >>>>> -XX:+PrintCompressedOopsMode >>>>> to -Xlog:gc+heap. The existing diagnostic flag has been >>>>> aliased to >>>>> the info level of this tagset (for the "Heap address" message >>>>> that >>>>> for example appears in the hs_err file), and there are both debug >>>>> and trace levels of logging available as well, as per our >>>>> established schema for assigning levels. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>>>> >>>>> >>>>> Passes JPRT and RBT quick/non-colo tests. >>>>> >>>>> Thanks! >>>>> Rachel >>>>> >>>>> >>>> >>> >> > From harold.seigel at oracle.com Thu Apr 7 15:04:27 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 7 Apr 2016 11:04:27 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5705632B.9090006@oracle.com> References: <5703FD3B.10307@oracle.com> <570530F9.8000901@oracle.com> <57055EE8.1020209@oracle.com> <5705632B.9090006@oracle.com> Message-ID: <570676FB.3050604@oracle.com> Looks good! Thanks, Harold On 4/6/2016 3:27 PM, Rachel Protacio wrote: > Ok, I've gone ahead and added the 'coops' tag, making this conversion > PrintCompressedOopsMode -> -Xlog:gc+heap+coops > > New webrev: http://cr.openjdk.java.net/~rprotacio/8152896.01 > > Also deleted ending periods in log messages, removed > "UnlockDiagnosticVMOptions" from tests where it is now unnecessary, > and @require'd 64 bit in the new test. > > Thanks, > Rachel > > On 4/6/2016 3:09 PM, Coleen Phillimore wrote: >> >> I think adding the coops tag to isolate this logging from all the >> other GC logging is a good idea. The name "coops" to mean >> "compressed oops" for the tag has meaning for us in the vm so it's >> not a bad abbreviation. >> >> Coleen >> >> On 4/6/16 11:53 AM, Rachel Protacio wrote: >>> Hi, >>> >>> Thanks for the response. Yes, there is other gc+heap logging already >>> present. As you can see from the grep below, there are a number of >>> other messages, especially in the trace level (which is to be >>> expected as verbose anyway). Additionally, there's the question of >>> which level should be aliased to. Right now, I have it at the info >>> level, which just prints the "Heap address" line but I could make it >>> debug level to print the other ones from virtualspace.cpp. >>> >>> I'm fine with adding another tag, but I want to make sure we have a >>> consensus before I do so. Does anyone else want to weigh in? >>> >>> Thanks, >>> Rachel >>> >>> >>> >>> src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS >>> ergo set MaxNewSize: " SIZE_FORMAT, MaxNewSize); >>> src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, heap)("CMS >>> set min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT >>> " max_heap: " SIZE_FORMAT, >>> src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, >>> heap)("CMS ergo set NewSize: " SIZE_FORMAT, NewSize); >>> src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, >>> heap)("CMS ergo set OldSize: " SIZE_FORMAT, OldSize); >>> src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, >>> heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT >>> src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" >>> Maximum heap size " SIZE_FORMAT, (size_t) reasonable_max); >>> src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, >>> heap)(" Initial heap size " SIZE_FORMAT, >>> (size_t)reasonable_initial); >>> src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, >>> heap)(" Minimum heap size " SIZE_FORMAT, min_heap_size()); >>> src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, >>> heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " >>> Maximum heap " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, >>> heap)("1: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT >>> " Maximum young " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, >>> heap)("2: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT >>> " Maximum young " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, >>> heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " >>> Maximum old " SIZE_FORMAT, >>> src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, >>> heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " >>> SIZE_FORMAT "K", >>> src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, >>> heap)("Garbage collection disabled, expanded heap instead"); >>> src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, >>> heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", >>> src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, >>> heap)("TenuredGeneration::compute_new_size:"); >>> src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, >>> heap)(" minimum_free_percentage: %6.2f maximum_used_percentage: >>> %6.2f", >>> src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, >>> heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK >>> capacity_after_gc : %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, >>> heap)(" free_percentage: %6.2f", free_percentage); >>> src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, >>> heap)(" expanding: minimum_desired_capacity: %6.1fK >>> expand_bytes: %6.1fK _min_heap_delta_bytes: %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, >>> heap)(" maximum_free_percentage: %6.2f minimum_used_percentage: >>> %6.2f", >>> src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, >>> heap)(" _capacity_at_prologue: %6.1fK minimum_desired_capacity: >>> %6.1fK maximum_desired_capacity: %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, >>> heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: >>> %.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, >>> heap)(" shrink_bytes: %.1fK current_shrink_factor: " SIZE_FORMAT >>> " new shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: %.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, >>> heap)(" aggressive shrinking: _capacity_at_prologue: %.1fK >>> capacity_after_gc: %.1fK expansion_for_promotion: %.1fK >>> shrink_bytes: %.1fK", >>> src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: >>> " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, >>> heap) log; >>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: >>> log_info(gc, heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" >>> SIZE_FORMAT "K)", >>> src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap >>> region size: " SIZE_FORMAT "M", GrainBytes / M); >>> src/share/vm/gc/g1/g1HeapTransition.cpp:89: if >>> (log_is_enabled(Trace, gc, heap)) { >>> src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, >>> heap)("Eden regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>> SIZE_FORMAT ")", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" >>> Used: 0K, Waste: 0K"); >>> src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, >>> heap)("Survivor regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>> SIZE_FORMAT ")", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, >>> heap)("Old regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>> src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, >>> heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>> src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, >>> heap)("Reserved memory not at requested address: " PTR_FORMAT " vs " >>> PTR_FORMAT, p2i(base), p2i(requested_address)); >>> src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, >>> heap)("Reserve regular memory without large pages"); >>> src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, >>> heap)("Protected page at the reserved heap base: " >>> src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, >>> heap)("Trying to allocate at address " PTR_FORMAT >>> src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, >>> heap)("Reserve regular memory without large pages"); >>> src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, >>> heap)("Trying to allocate at address NULL heap of size " >>> SIZE_FORMAT_HEX, size + noaccess_prefix); >>> src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, >>> gc, heap)) { >>> src/share/vm/memory/universe.cpp:752: outputStream* logst = >>> Log(gc, heap)::info_stream(); >>> src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; >>> src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; >>> >>> >>> On 4/6/2016 8:26 AM, Thomas St?fe wrote: >>>> Hi Rachel, >>>> >>>> one question, does this change the output for >>>> -XX:PrintCompressedOopsMode much? It seems to be wired now to >>>> "LOG_TAGS(gc, heap)", which prints much more than just heap >>>> reservation for the compressed oops mode. Would it be possible to >>>> add a "coops" tag or similar to isolate this output? >>>> >>>> The reason I ask is that we used this flag extensively when >>>> optimizing heap reservation on AIX for compressed oops, and may >>>> want to continue using it or an alternative which gives the same >>>> output. >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio >>>> > >>>> wrote: >>>> >>>> Hello, >>>> >>>> Please review this change, converting -XX:+PrintCompressedOopsMode >>>> to -Xlog:gc+heap. The existing diagnostic flag has been aliased to >>>> the info level of this tagset (for the "Heap address" message that >>>> for example appears in the hs_err file), and there are both debug >>>> and trace levels of logging available as well, as per our >>>> established schema for assigning levels. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>>> >>>> >>>> Passes JPRT and RBT quick/non-colo tests. >>>> >>>> Thanks! >>>> Rachel >>>> >>>> >>> >> > From stefan.johansson at oracle.com Thu Apr 7 15:06:38 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 7 Apr 2016 17:06:38 +0200 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <5705632B.9090006@oracle.com> References: <5703FD3B.10307@oracle.com> <570530F9.8000901@oracle.com> <57055EE8.1020209@oracle.com> <5705632B.9090006@oracle.com> Message-ID: <5706777E.6030009@oracle.com> Looks good. Thanks for fixing the periods, Stefan On 2016-04-06 21:27, Rachel Protacio wrote: > Ok, I've gone ahead and added the 'coops' tag, making this conversion > PrintCompressedOopsMode -> -Xlog:gc+heap+coops > > New webrev: http://cr.openjdk.java.net/~rprotacio/8152896.01 > > Also deleted ending periods in log messages, removed > "UnlockDiagnosticVMOptions" from tests where it is now unnecessary, > and @require'd 64 bit in the new test. > > Thanks, > Rachel > > On 4/6/2016 3:09 PM, Coleen Phillimore wrote: >> >> I think adding the coops tag to isolate this logging from all the >> other GC logging is a good idea. The name "coops" to mean >> "compressed oops" for the tag has meaning for us in the vm so it's >> not a bad abbreviation. >> >> Coleen >> >> On 4/6/16 11:53 AM, Rachel Protacio wrote: >>> Hi, >>> >>> Thanks for the response. Yes, there is other gc+heap logging already >>> present. As you can see from the grep below, there are a number of >>> other messages, especially in the trace level (which is to be >>> expected as verbose anyway). Additionally, there's the question of >>> which level should be aliased to. Right now, I have it at the info >>> level, which just prints the "Heap address" line but I could make it >>> debug level to print the other ones from virtualspace.cpp. >>> >>> I'm fine with adding another tag, but I want to make sure we have a >>> consensus before I do so. Does anyone else want to weigh in? >>> >>> Thanks, >>> Rachel >>> >>> >>> >>> src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS >>> ergo set MaxNewSize: " SIZE_FORMAT, MaxNewSize); >>> src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, heap)("CMS >>> set min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT >>> " max_heap: " SIZE_FORMAT, >>> src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, >>> heap)("CMS ergo set NewSize: " SIZE_FORMAT, NewSize); >>> src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, >>> heap)("CMS ergo set OldSize: " SIZE_FORMAT, OldSize); >>> src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, >>> heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT >>> src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" >>> Maximum heap size " SIZE_FORMAT, (size_t) reasonable_max); >>> src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, >>> heap)(" Initial heap size " SIZE_FORMAT, >>> (size_t)reasonable_initial); >>> src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, >>> heap)(" Minimum heap size " SIZE_FORMAT, min_heap_size()); >>> src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, >>> heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " >>> Maximum heap " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, >>> heap)("1: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT >>> " Maximum young " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, >>> heap)("2: Minimum young " SIZE_FORMAT " Initial young " SIZE_FORMAT >>> " Maximum young " SIZE_FORMAT, >>> src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, >>> heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " >>> Maximum old " SIZE_FORMAT, >>> src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, >>> heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " >>> SIZE_FORMAT "K", >>> src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, >>> heap)("Garbage collection disabled, expanded heap instead"); >>> src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, >>> heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", >>> src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, >>> heap)("TenuredGeneration::compute_new_size:"); >>> src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, >>> heap)(" minimum_free_percentage: %6.2f maximum_used_percentage: >>> %6.2f", >>> src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, >>> heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK >>> capacity_after_gc : %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, >>> heap)(" free_percentage: %6.2f", free_percentage); >>> src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, >>> heap)(" expanding: minimum_desired_capacity: %6.1fK >>> expand_bytes: %6.1fK _min_heap_delta_bytes: %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, >>> heap)(" maximum_free_percentage: %6.2f minimum_used_percentage: >>> %6.2f", >>> src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, >>> heap)(" _capacity_at_prologue: %6.1fK minimum_desired_capacity: >>> %6.1fK maximum_desired_capacity: %6.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, >>> heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: >>> %.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, >>> heap)(" shrink_bytes: %.1fK current_shrink_factor: " SIZE_FORMAT >>> " new shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: %.1fK", >>> src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, >>> heap)(" aggressive shrinking: _capacity_at_prologue: %.1fK >>> capacity_after_gc: %.1fK expansion_for_promotion: %.1fK >>> shrink_bytes: %.1fK", >>> src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: >>> " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, >>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, >>> heap) log; >>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: >>> log_info(gc, heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" >>> SIZE_FORMAT "K)", >>> src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap >>> region size: " SIZE_FORMAT "M", GrainBytes / M); >>> src/share/vm/gc/g1/g1HeapTransition.cpp:89: if >>> (log_is_enabled(Trace, gc, heap)) { >>> src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, >>> heap)("Eden regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>> SIZE_FORMAT ")", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" >>> Used: 0K, Waste: 0K"); >>> src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, >>> heap)("Survivor regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>> SIZE_FORMAT ")", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, >>> heap)("Old regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>> src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, >>> heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>> src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" >>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>> src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, >>> heap)("Reserved memory not at requested address: " PTR_FORMAT " vs " >>> PTR_FORMAT, p2i(base), p2i(requested_address)); >>> src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, >>> heap)("Reserve regular memory without large pages"); >>> src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, >>> heap)("Protected page at the reserved heap base: " >>> src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, >>> heap)("Trying to allocate at address " PTR_FORMAT >>> src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, >>> heap)("Reserve regular memory without large pages"); >>> src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, >>> heap)("Trying to allocate at address NULL heap of size " >>> SIZE_FORMAT_HEX, size + noaccess_prefix); >>> src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, >>> gc, heap)) { >>> src/share/vm/memory/universe.cpp:752: outputStream* logst = >>> Log(gc, heap)::info_stream(); >>> src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; >>> src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; >>> >>> >>> On 4/6/2016 8:26 AM, Thomas St?fe wrote: >>>> Hi Rachel, >>>> >>>> one question, does this change the output for >>>> -XX:PrintCompressedOopsMode much? It seems to be wired now to >>>> "LOG_TAGS(gc, heap)", which prints much more than just heap >>>> reservation for the compressed oops mode. Would it be possible to >>>> add a "coops" tag or similar to isolate this output? >>>> >>>> The reason I ask is that we used this flag extensively when >>>> optimizing heap reservation on AIX for compressed oops, and may >>>> want to continue using it or an alternative which gives the same >>>> output. >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio >>>> > >>>> wrote: >>>> >>>> Hello, >>>> >>>> Please review this change, converting -XX:+PrintCompressedOopsMode >>>> to -Xlog:gc+heap. The existing diagnostic flag has been aliased to >>>> the info level of this tagset (for the "Heap address" message that >>>> for example appears in the hs_err file), and there are both debug >>>> and trace levels of logging available as well, as per our >>>> established schema for assigning levels. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>>> >>>> >>>> Passes JPRT and RBT quick/non-colo tests. >>>> >>>> Thanks! >>>> Rachel >>>> >>>> >>> >> > From cheleswer.sahu at oracle.com Thu Apr 7 15:23:28 2016 From: cheleswer.sahu at oracle.com (Cheleswer Sahu) Date: Thu, 7 Apr 2016 08:23:28 -0700 (PDT) Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails In-Reply-To: <57066D23.4090505@oracle.com> References: <5703BDD1.5090108@oracle.com> <57066AB8.4000808@oracle.com> <57066D23.4090505@oracle.com> Message-ID: <6a053489-2529-44a3-9385-876df6957a42@default> Thanks Dmitry and Leonid for review. Thanks Dan for information, I will do the needful before pushing this fix. Regards, Cheleswer -----Original Message----- From: Daniel D. Daugherty Sent: Thursday, April 07, 2016 7:52 PM To: Dmitry Samersoff; Cheleswer Sahu; Leonid Mesnik; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; Filipp Zhinkin Subject: Re: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Cheleswer, When you re-sync with the current JDK9-hs-rt, you'll have to re-enable this test. It was quarantined yesterday with this fix: JDK-8153671 Quarantine serviceability/tmtools/jstack/JstackThreadTest.java until JDK-8153319 is fixed https://bugs.openjdk.java.net/browse/JDK-8153671 You just need to remove the @ignore line. Dan On 4/7/16 8:12 AM, Dmitry Samersoff wrote: > Cheleswer, > > Looks good for me. Reviewed. > > -Dmitry > > On 2016-04-07 16:50, Cheleswer Sahu wrote: >> Hi , >> Thanks for your review and suggestion. I agree that sleep is not the >> best and reliable way to achieve the objective of test case. I also >> found the idea of using j.u.c.CountDownLatch very easy and >> effective. I have made some changes in the code. Please review the >> code changes in the below link >> >> http://cr.openjdk.java.net/~csahu/8153319/webrev.01/ >> >> >> Regards, >> Cheleswer >> -----Original Message----- >> From: Leonid Mesnik >> Sent: Tuesday, April 05, 2016 7:00 PM >> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR[9u-dev]: 8153319: new test >> serviceability/tmtools/jstack/JstackThreadTest.java fails >> >> Hi >> >> I don't think that sleep is a good way to ensure that thread is started. >> It is not reliable on the slow host / VM under stress and just waste of time on fast host. >> Is it possible just to add any explicit synchronization to ensure that NamedThread is started? >> >> Leonid >> >> On 05.04.2016 13:23, Cheleswer Sahu wrote: >>> Hi, >>> >>> >>> >>> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319. >>> >>> >>> >>> Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ >>> >>> >>> >>> >>> >>> Bug Brief: Test is failing on some platforms. >>> >>> >>> >>> Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls "jstack", which result in test failure. >>> >>> >>> >>> Solution Proposed: Set the child thread in sleep state for forever and make sure that "jstack " tool always gets executed after " NamedThread" is started. >>> >>> >>> >>> >>> >>> Regards, >>> >>> Cheleswer >>> >>> >>> >>> > From rachel.protacio at oracle.com Thu Apr 7 16:09:21 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 7 Apr 2016 12:09:21 -0400 Subject: RFR: 8152896: Convert PrintCompressedOopsMode to Unified Logging In-Reply-To: <570676FB.3050604@oracle.com> References: <5703FD3B.10307@oracle.com> <570530F9.8000901@oracle.com> <57055EE8.1020209@oracle.com> <5705632B.9090006@oracle.com> <570676FB.3050604@oracle.com> Message-ID: <57068631.8000408@oracle.com> Thank you, Harold and Stefan! Will commit. Rachel On 4/7/2016 11:04 AM, harold seigel wrote: > Looks good! > > Thanks, Harold > > On 4/6/2016 3:27 PM, Rachel Protacio wrote: >> Ok, I've gone ahead and added the 'coops' tag, making this conversion >> PrintCompressedOopsMode -> -Xlog:gc+heap+coops >> >> New webrev: http://cr.openjdk.java.net/~rprotacio/8152896.01 >> >> Also deleted ending periods in log messages, removed >> "UnlockDiagnosticVMOptions" from tests where it is now unnecessary, >> and @require'd 64 bit in the new test. >> >> Thanks, >> Rachel >> >> On 4/6/2016 3:09 PM, Coleen Phillimore wrote: >>> >>> I think adding the coops tag to isolate this logging from all the >>> other GC logging is a good idea. The name "coops" to mean >>> "compressed oops" for the tag has meaning for us in the vm so it's >>> not a bad abbreviation. >>> >>> Coleen >>> >>> On 4/6/16 11:53 AM, Rachel Protacio wrote: >>>> Hi, >>>> >>>> Thanks for the response. Yes, there is other gc+heap logging >>>> already present. As you can see from the grep below, there are a >>>> number of other messages, especially in the trace level (which is >>>> to be expected as verbose anyway). Additionally, there's the >>>> question of which level should be aliased to. Right now, I have it >>>> at the info level, which just prints the "Heap address" line but I >>>> could make it debug level to print the other ones from >>>> virtualspace.cpp. >>>> >>>> I'm fine with adding another tag, but I want to make sure we have a >>>> consensus before I do so. Does anyone else want to weigh in? >>>> >>>> Thanks, >>>> Rachel >>>> >>>> >>>> >>>> src/share/vm/runtime/arguments.cpp:1766: log_trace(gc, heap)("CMS >>>> ergo set MaxNewSize: " SIZE_FORMAT, MaxNewSize); >>>> src/share/vm/runtime/arguments.cpp:1769: log_trace(gc, >>>> heap)("CMS >>>> set min_heap_size: " SIZE_FORMAT " initial_heap_size: " SIZE_FORMAT >>>> " max_heap: " SIZE_FORMAT, >>>> src/share/vm/runtime/arguments.cpp:1781: log_trace(gc, >>>> heap)("CMS ergo set NewSize: " SIZE_FORMAT, NewSize); >>>> src/share/vm/runtime/arguments.cpp:1788: log_trace(gc, >>>> heap)("CMS ergo set OldSize: " SIZE_FORMAT, OldSize); >>>> src/share/vm/runtime/arguments.cpp:2189: log_debug(gc, >>>> heap)("HeapBaseMinAddress must be at least " SIZE_FORMAT >>>> src/share/vm/runtime/arguments.cpp:2215: log_trace(gc, heap)(" >>>> Maximum heap size " SIZE_FORMAT, (size_t) reasonable_max); >>>> src/share/vm/runtime/arguments.cpp:2236: log_trace(gc, >>>> heap)(" Initial heap size " SIZE_FORMAT, >>>> (size_t)reasonable_initial); >>>> src/share/vm/runtime/arguments.cpp:2243: log_trace(gc, >>>> heap)(" Minimum heap size " SIZE_FORMAT, min_heap_size()); >>>> src/share/vm/gc/shared/collectorPolicy.cpp:144: log_debug(gc, >>>> heap)("Minimum heap " SIZE_FORMAT " Initial heap " SIZE_FORMAT " >>>> Maximum heap " SIZE_FORMAT, >>>> src/share/vm/gc/shared/collectorPolicy.cpp:492: log_trace(gc, >>>> heap)("1: Minimum young " SIZE_FORMAT " Initial young " >>>> SIZE_FORMAT >>>> " Maximum young " SIZE_FORMAT, >>>> src/share/vm/gc/shared/collectorPolicy.cpp:559: log_trace(gc, >>>> heap)("2: Minimum young " SIZE_FORMAT " Initial young " >>>> SIZE_FORMAT >>>> " Maximum young " SIZE_FORMAT, >>>> src/share/vm/gc/shared/collectorPolicy.cpp:576: log_trace(gc, >>>> heap)("Minimum old " SIZE_FORMAT " Initial old " SIZE_FORMAT " >>>> Maximum old " SIZE_FORMAT, >>>> src/share/vm/gc/shared/cardGeneration.cpp:102: log_trace(gc, >>>> heap)("Expanding %s from " SIZE_FORMAT "K by " SIZE_FORMAT "K to " >>>> SIZE_FORMAT "K", >>>> src/share/vm/gc/shared/cardGeneration.cpp:135: log_trace(gc, >>>> heap)("Garbage collection disabled, expanded heap instead"); >>>> src/share/vm/gc/shared/cardGeneration.cpp:173: log_trace(gc, >>>> heap)("Shrinking %s from " SIZE_FORMAT "K to " SIZE_FORMAT "K", >>>> src/share/vm/gc/shared/cardGeneration.cpp:210: log_trace(gc, >>>> heap)("TenuredGeneration::compute_new_size:"); >>>> src/share/vm/gc/shared/cardGeneration.cpp:211: log_trace(gc, >>>> heap)(" minimum_free_percentage: %6.2f maximum_used_percentage: >>>> %6.2f", >>>> src/share/vm/gc/shared/cardGeneration.cpp:214: log_trace(gc, >>>> heap)(" free_after_gc : %6.1fK used_after_gc : %6.1fK >>>> capacity_after_gc : %6.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:218: log_trace(gc, >>>> heap)(" free_percentage: %6.2f", free_percentage); >>>> src/share/vm/gc/shared/cardGeneration.cpp:227: log_trace(gc, >>>> heap)(" expanding: minimum_desired_capacity: %6.1fK >>>> expand_bytes: %6.1fK _min_heap_delta_bytes: %6.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:245: log_trace(gc, >>>> heap)(" maximum_free_percentage: %6.2f minimum_used_percentage: >>>> %6.2f", >>>> src/share/vm/gc/shared/cardGeneration.cpp:247: log_trace(gc, >>>> heap)(" _capacity_at_prologue: %6.1fK minimum_desired_capacity: >>>> %6.1fK maximum_desired_capacity: %6.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:273: log_trace(gc, >>>> heap)(" shrinking: initSize: %.1fK maximum_desired_capacity: >>>> %.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:275: log_trace(gc, >>>> heap)(" shrink_bytes: %.1fK current_shrink_factor: " >>>> SIZE_FORMAT >>>> " new shrink factor: " SIZE_FORMAT " _min_heap_delta_bytes: >>>> %.1fK", >>>> src/share/vm/gc/shared/cardGeneration.cpp:292: log_trace(gc, >>>> heap)(" aggressive shrinking: _capacity_at_prologue: %.1fK >>>> capacity_after_gc: %.1fK expansion_for_promotion: %.1fK >>>> shrink_bytes: %.1fK", >>>> src/share/vm/gc/shared/genCollectedHeap.cpp:1134: log_info(gc, >>>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>>> src/share/vm/gc/shared/genCollectedHeap.cpp:1136: log_info(gc, >>>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>>> src/share/vm/gc/parallel/psOldGen.cpp:432: log_info(gc, heap)("%s: >>>> " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>>> src/share/vm/gc/parallel/psYoungGen.cpp:764: log_info(gc, >>>> heap)("%s: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" SIZE_FORMAT "K)", >>>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1608: Log(gc, >>>> heap) log; >>>> src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp:1893: >>>> log_info(gc, heap)("Old: " SIZE_FORMAT "K->" SIZE_FORMAT "K(" >>>> SIZE_FORMAT "K)", >>>> src/share/vm/gc/g1/heapRegion.cpp:148: log_info(gc, heap)("Heap >>>> region size: " SIZE_FORMAT "M", GrainBytes / M); >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:89: if >>>> (log_is_enabled(Trace, gc, heap)) { >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:102: log_info(gc, >>>> heap)("Eden regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>>> SIZE_FORMAT ")", >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:104: log_trace(gc, heap)(" >>>> Used: 0K, Waste: 0K"); >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:106: log_info(gc, >>>> heap)("Survivor regions: " SIZE_FORMAT "->" SIZE_FORMAT "(" >>>> SIZE_FORMAT ")", >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:108: log_trace(gc, heap)(" >>>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:111: log_info(gc, >>>> heap)("Old regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:113: log_trace(gc, heap)(" >>>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:116: log_info(gc, >>>> heap)("Humongous regions: " SIZE_FORMAT "->" SIZE_FORMAT, >>>> src/share/vm/gc/g1/g1HeapTransition.cpp:118: log_trace(gc, heap)(" >>>> Used: " SIZE_FORMAT "K, Waste: " SIZE_FORMAT "K", >>>> src/share/vm/memory/virtualspace.cpp:83: log_debug(gc, >>>> heap)("Reserved memory not at requested address: " PTR_FORMAT " >>>> vs " >>>> PTR_FORMAT, p2i(base), p2i(requested_address)); >>>> src/share/vm/memory/virtualspace.cpp:145: log_debug(gc, >>>> heap)("Reserve regular memory without large pages"); >>>> src/share/vm/memory/virtualspace.cpp:285: log_debug(gc, >>>> heap)("Protected page at the reserved heap base: " >>>> src/share/vm/memory/virtualspace.cpp:319: log_trace(gc, >>>> heap)("Trying to allocate at address " PTR_FORMAT >>>> src/share/vm/memory/virtualspace.cpp:341: log_debug(gc, >>>> heap)("Reserve regular memory without large pages"); >>>> src/share/vm/memory/virtualspace.cpp:553: log_trace(gc, >>>> heap)("Trying to allocate at address NULL heap of size " >>>> SIZE_FORMAT_HEX, size + noaccess_prefix); >>>> src/share/vm/memory/universe.cpp:750: if (log_is_enabled(Info, >>>> gc, heap)) { >>>> src/share/vm/memory/universe.cpp:752: outputStream* logst = >>>> Log(gc, heap)::info_stream(); >>>> src/share/vm/memory/universe.cpp:1088: Log(gc, heap) log; >>>> src/share/vm/memory/universe.cpp:1097: Log(gc, heap) log; >>>> >>>> >>>> On 4/6/2016 8:26 AM, Thomas St?fe wrote: >>>>> Hi Rachel, >>>>> >>>>> one question, does this change the output for >>>>> -XX:PrintCompressedOopsMode much? It seems to be wired now to >>>>> "LOG_TAGS(gc, heap)", which prints much more than just heap >>>>> reservation for the compressed oops mode. Would it be possible to >>>>> add a "coops" tag or similar to isolate this output? >>>>> >>>>> The reason I ask is that we used this flag extensively when >>>>> optimizing heap reservation on AIX for compressed oops, and may >>>>> want to continue using it or an alternative which gives the same >>>>> output. >>>>> >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>> On Tue, Apr 5, 2016 at 8:00 PM, Rachel Protacio >>>>> > >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review this change, converting >>>>> -XX:+PrintCompressedOopsMode >>>>> to -Xlog:gc+heap. The existing diagnostic flag has been >>>>> aliased to >>>>> the info level of this tagset (for the "Heap address" message >>>>> that >>>>> for example appears in the hs_err file), and there are both debug >>>>> and trace levels of logging available as well, as per our >>>>> established schema for assigning levels. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152896 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152896.00/ >>>>> >>>>> >>>>> Passes JPRT and RBT quick/non-colo tests. >>>>> >>>>> Thanks! >>>>> Rachel >>>>> >>>>> >>>> >>> >> > From chris.hegarty at oracle.com Thu Apr 7 17:14:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 7 Apr 2016 18:14:56 +0100 Subject: RFR [9] 8153737: Unsupported Module Message-ID: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Enough technical debt has been paid down that we can now create the new JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. This module will initially contain, and export, the sun.misc package, and will eventually export the sun.reflect package too ( once it has been sanitized ). The jdk.unsupported module will be present in full JRE and JDK images. http://cr.openjdk.java.net/~chegar/8153737/ https://bugs.openjdk.java.net/browse/JDK-8153737 Summary of the changes: - Restructure, what remains of, the sources in sun/misc to reflect the new modular layout. There are still a few non-Critical APIs in sun.misc that will be addressed later. - Add dependencies from several JDK modules to jdk.unsupported. All dependencies have issues tracking them, and should be removed in 9. - The test library in the top-level repo provides a convenience to tests to retrieve Unsafe. This has been updated to the "real" internal Unsafe, so there are many many tests that require to be updated, mostly the @modules tags. ( The Unsafe dependency in the library should probably be revisited at some point, as it requires many tests, not wishing to use Unsafe, to require an explicit dependency on it ) Note: with recent work from Mikael [2], sun.misc.Unsafe is now just a delegate for the "real" internal Unsafe, so it is time to move the tests to use it directly. - Cleanup any tests unnecessarily/incorrectly declaring a dependency on sun.misc ( this could have been unnecessarily added, been refactored out at one point, or the library upon which the tests depends refactored, that the dependency is no longer required ). I'm sure further cleanup could be done, but this is sufficient for now. - A small number of test in hotspot/test/compiler/unsafe, which are generated, have been updated, along with the generation script, to depend on jdk.unsupported/sun.misc ( they explicitly test the sun.misc version ) All 'core', 'pit', and 'hotspot' testsets have been successfully run on Mac, Linux, Windows, and Solaris. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8132928 [2] https://bugs.openjdk.java.net/browse/JDK-8149159 From max.ockner at oracle.com Thu Apr 7 17:59:34 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 07 Apr 2016 13:59:34 -0400 Subject: RFR: 8152468: PrintMiscellaneous in constantPool should use classresolve logging. In-Reply-To: <57053D4D.7060501@oracle.com> References: <57052C48.6070906@oracle.com> <57053D4D.7060501@oracle.com> Message-ID: <5706A006.3080006@oracle.com> New webrev. http://cr.openjdk.java.net/~mockner/8151526.02 On 4/6/2016 12:46 PM, Coleen Phillimore wrote: > > Hi Max, Thanks for doing this. > > // FIXME: should be an assert > *if (PrintMiscellaneous && (Verbose||WizardMode)) {* > *tty->print_cr("bad operand %d in:", which); cpool->print();* > *}* > *+log_trace(classresolve)("bad operand %d in:", which); cpool->print();* > > > Can you make this log_debug() since it seems to be trying to catch a bug? > Yes. fixed. > For the other two changes, I don't see a ResourceMark. Can you add > one to both with ResourceMark rm(THREAD); The THREAD parameter makes > the ResourceMark inexpensive in terms of code generated. > Yes. fixed. > Also I just noticed that trace_class_resolution does a bit of work > even when logging is disabled. Can you add a > if (log_is_enabled(Debug, classresolve)) { > before the trace_class_resolution call? > Fixed. > > Lastly, I think we should point out that we agreed that the > classresolve tag is going to become the tag set class,resolve, with an > RFE that you're going to file. > > Thanks, > Coleen > > > On 4/6/16 11:33 AM, Max Ockner wrote: >> Hello hello everyone, >> >> Please review this addition to classresolve logging. >> >> Bug https://bugs.openjdk.java.net/browse/JDK-8152468 >> Webrev http://cr.openjdk.java.net/~mockner/8152468.01/ >> >> There were a few bits of classresolve logging that was guarded by >> PrintMiscellaneous instead of TraceClassResolution, and were missed >> in the initial conversion. This has been fixed and the classresolve >> test has been updated to check or new output. >> >> Tested with jtreg runtime. >> >> Thanks, >> Max >> > > From rachel.protacio at oracle.com Thu Apr 7 18:34:16 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 7 Apr 2016 14:34:16 -0400 Subject: RFR: 8152468: PrintMiscellaneous in constantPool should use classresolve logging. In-Reply-To: <5706A006.3080006@oracle.com> References: <57052C48.6070906@oracle.com> <57053D4D.7060501@oracle.com> <5706A006.3080006@oracle.com> Message-ID: <5706A828.7040504@oracle.com> Looks good to me. Rachel On 4/7/2016 1:59 PM, Max Ockner wrote: > New webrev. http://cr.openjdk.java.net/~mockner/8151526.02 > On 4/6/2016 12:46 PM, Coleen Phillimore wrote: >> >> Hi Max, Thanks for doing this. >> >> // FIXME: should be an assert >> *if (PrintMiscellaneous && (Verbose||WizardMode)) {* >> *tty->print_cr("bad operand %d in:", which); cpool->print();* >> *}* >> *+log_trace(classresolve)("bad operand %d in:", which); cpool->print();* >> >> >> Can you make this log_debug() since it seems to be trying to catch a >> bug? >> > Yes. fixed. >> For the other two changes, I don't see a ResourceMark. Can you add >> one to both with ResourceMark rm(THREAD); The THREAD parameter makes >> the ResourceMark inexpensive in terms of code generated. >> > Yes. fixed. >> Also I just noticed that trace_class_resolution does a bit of work >> even when logging is disabled. Can you add a >> if (log_is_enabled(Debug, classresolve)) { >> before the trace_class_resolution call? >> > Fixed. >> >> Lastly, I think we should point out that we agreed that the >> classresolve tag is going to become the tag set class,resolve, with >> an RFE that you're going to file. >> >> Thanks, >> Coleen >> >> >> On 4/6/16 11:33 AM, Max Ockner wrote: >>> Hello hello everyone, >>> >>> Please review this addition to classresolve logging. >>> >>> Bug https://bugs.openjdk.java.net/browse/JDK-8152468 >>> Webrev http://cr.openjdk.java.net/~mockner/8152468.01/ >>> >>> There were a few bits of classresolve logging that was guarded by >>> PrintMiscellaneous instead of TraceClassResolution, and were missed >>> in the initial conversion. This has been fixed and the classresolve >>> test has been updated to check or new output. >>> >>> Tested with jtreg runtime. >>> >>> Thanks, >>> Max >>> >> >> > From Alan.Bateman at oracle.com Thu Apr 7 18:57:24 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Apr 2016 19:57:24 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: <5706AD94.8030701@oracle.com> On 07/04/2016 18:14, Chris Hegarty wrote: > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > > http://cr.openjdk.java.net/~chegar/8153737/ It's great to get to this milestone. I looked over the webrev and I don't see any issues. I'm surprised by the number of tests that had @modules java.base/sun.misc even though they aren't using anything in sun.misc. I see Phil has pushed JDK-8147544 to jdk9/client rather than jdk9/dev so it means that the module-info.java for java.desktop will need to be fixed up when it gets to jdk9/dev. I think we should bump the priority of all the issues that cause you to add `requires jdk.unsupported`we should at least get all of them resolved by FC as we shouldn't have any standard modules with this dependence. -Alan. From coleen.phillimore at oracle.com Thu Apr 7 19:12:25 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 7 Apr 2016 15:12:25 -0400 Subject: RFR: 8152468: PrintMiscellaneous in constantPool should use classresolve logging. In-Reply-To: <5706A006.3080006@oracle.com> References: <57052C48.6070906@oracle.com> <57053D4D.7060501@oracle.com> <5706A006.3080006@oracle.com> Message-ID: <5706B119.1030304@oracle.com> Thank you for fixing these issues. Coleen On 4/7/16 1:59 PM, Max Ockner wrote: > New webrev. http://cr.openjdk.java.net/~mockner/8151526.02 > On 4/6/2016 12:46 PM, Coleen Phillimore wrote: >> >> Hi Max, Thanks for doing this. >> >> // FIXME: should be an assert >> *if (PrintMiscellaneous && (Verbose||WizardMode)) {* >> *tty->print_cr("bad operand %d in:", which); cpool->print();* >> *}* >> *+log_trace(classresolve)("bad operand %d in:", which); cpool->print();* >> >> >> Can you make this log_debug() since it seems to be trying to catch a >> bug? >> > Yes. fixed. >> For the other two changes, I don't see a ResourceMark. Can you add >> one to both with ResourceMark rm(THREAD); The THREAD parameter makes >> the ResourceMark inexpensive in terms of code generated. >> > Yes. fixed. >> Also I just noticed that trace_class_resolution does a bit of work >> even when logging is disabled. Can you add a >> if (log_is_enabled(Debug, classresolve)) { >> before the trace_class_resolution call? >> > Fixed. >> >> Lastly, I think we should point out that we agreed that the >> classresolve tag is going to become the tag set class,resolve, with >> an RFE that you're going to file. >> >> Thanks, >> Coleen >> >> >> On 4/6/16 11:33 AM, Max Ockner wrote: >>> Hello hello everyone, >>> >>> Please review this addition to classresolve logging. >>> >>> Bug https://bugs.openjdk.java.net/browse/JDK-8152468 >>> Webrev http://cr.openjdk.java.net/~mockner/8152468.01/ >>> >>> There were a few bits of classresolve logging that was guarded by >>> PrintMiscellaneous instead of TraceClassResolution, and were missed >>> in the initial conversion. This has been fixed and the classresolve >>> test has been updated to check or new output. >>> >>> Tested with jtreg runtime. >>> >>> Thanks, >>> Max >>> >> >> > From gerard.ziemski at oracle.com Thu Apr 7 19:16:15 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 7 Apr 2016 14:16:15 -0500 Subject: RFR (S): 8153039: Command line processing should use mtCommand or mtArguments rather than mtInternal for NMT Message-ID: <494C0978-5A45-4EAD-922D-80D9F4A51622@oracle.com> hi all, Please review this small cleanup fix, which introduces a new NMT (Native Memory Tracking) flag (ie. mtArguments) and replaces any existing, but incorrect, usages of mtInternal in argument processing related code with that new flag. bug: https://bugs.openjdk.java.net/browse/JDK-8153039 webrev: http://cr.openjdk.java.net/~gziemski/8153039_rev1 Passes local ?hotspot/test/runtime/NMT? jtreg tests. cheers From coleen.phillimore at oracle.com Thu Apr 7 19:34:18 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 7 Apr 2016 15:34:18 -0400 Subject: RFR (S): 8153039: Command line processing should use mtCommand or mtArguments rather than mtInternal for NMT In-Reply-To: <494C0978-5A45-4EAD-922D-80D9F4A51622@oracle.com> References: <494C0978-5A45-4EAD-922D-80D9F4A51622@oracle.com> Message-ID: <5706B63A.6030800@oracle.com> Looks awesome! Thanks! Coleen On 4/7/16 3:16 PM, Gerard Ziemski wrote: > hi all, > > Please review this small cleanup fix, which introduces a new NMT (Native Memory Tracking) flag (ie. mtArguments) and replaces any existing, but incorrect, usages of mtInternal in argument processing related code with that new flag. > > bug: https://bugs.openjdk.java.net/browse/JDK-8153039 > webrev: http://cr.openjdk.java.net/~gziemski/8153039_rev1 > > Passes local ?hotspot/test/runtime/NMT? jtreg tests. > > > cheers > From george.triantafillou at oracle.com Thu Apr 7 19:48:10 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 7 Apr 2016 15:48:10 -0400 Subject: RFR (S): 8153039: Command line processing should use mtCommand or mtArguments rather than mtInternal for NMT In-Reply-To: <494C0978-5A45-4EAD-922D-80D9F4A51622@oracle.com> References: <494C0978-5A45-4EAD-922D-80D9F4A51622@oracle.com> Message-ID: <5706B97A.9000008@oracle.com> Hi Gerard, Looks good. -George On 4/7/2016 3:16 PM, Gerard Ziemski wrote: > hi all, > > Please review this small cleanup fix, which introduces a new NMT (Native Memory Tracking) flag (ie. mtArguments) and replaces any existing, but incorrect, usages of mtInternal in argument processing related code with that new flag. > > bug: https://bugs.openjdk.java.net/browse/JDK-8153039 > webrev: http://cr.openjdk.java.net/~gziemski/8153039_rev1 > > Passes local ?hotspot/test/runtime/NMT? jtreg tests. > > > cheers > From max.ockner at oracle.com Thu Apr 7 20:56:24 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 07 Apr 2016 16:56:24 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570415ED.1090808@oracle.com> References: <56FAD0E3.5090508@oracle.com> <570415ED.1090808@oracle.com> Message-ID: <5706C978.8040907@oracle.com> OK I tested with jcmd and I needed to add one line above the log configuration to make both sets of code match. webrev: http://cr.openjdk.java.net/~mockner/8151526.03/ Thanks, Max On 4/5/2016 3:45 PM, Coleen Phillimore wrote: > > This change looks good. You found the duplicated code for jcmd. > > To test this before you check this in to verify, start a JVM running > some java program in an infinite loop, and do jcmd VM.info > > Thanks, > Coleen > > On 3/29/16 3:00 PM, Max Ockner wrote: >> Hello, >> Please review another Unified Logging change. They are almost done, >> and we are serious this time. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >> >> The logging configuration is now printed in each hs_err file. The >> output is the same as you would see from -Xlog:logging=trace and it >> is obtained from LogConfiguration::describe(). >> >> Below is a sample of the hs_err contents. The Logging info is printed >> after VM Arguments and Whitebox, and before Environment Variables. >> >> VM Arguments: >> java_command: Kaboom >> java_class_path (initial): . >> Launcher Type: SUN_STANDARD >> >> Logging: >> Available log levels: off, trace, debug, info, warning, error >> Available log decorators: time (t), uptime (u), timemillis (tm), >> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), >> pid (p), tid (ti), level (l), tags (tg) >> Available log tags: alloc, age, barrier, biasedlocking, bot, census, >> classhisto, classresolve, classinit, classload, classloaderdata, >> classunload, classpath, compaction, cpu, cset, defaultmethods, ergo, >> exceptions, exit, freelist, gc, heap, humongous, ihop, itables, jni, >> liveness, logging, marking, metaspace, modules, monitorinflation, os, >> phases, plab, promotion, preorder, protectiondomain, ref, refine, >> region, remset, safepoint, safepointcleanup, scavenge, scrub, >> stacktrace, start, startuptime, state, stats, stringdedup, >> stringtable, survivor, sweep, task, thread, tlab, time, >> verboseverification, verify, vmoperation, vtables >> Log output configuration: >> #0: stdout all=off uptime,level,tags, >> #1: stderr all=warning uptime,level,tags, >> >> Environment Variables: >> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >> >> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >> >> SHELL=/bin/bash >> OS=Linux >> > From gerard.ziemski at oracle.com Thu Apr 7 21:09:11 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 7 Apr 2016 16:09:11 -0500 Subject: RFR (S): 8153039: Command line processing should use mtCommand or mtArguments rather than mtInternal for NMT In-Reply-To: <5706B63A.6030800@oracle.com> References: <494C0978-5A45-4EAD-922D-80D9F4A51622@oracle.com> <5706B63A.6030800@oracle.com> Message-ID: Thank you for the review! > On Apr 7, 2016, at 2:34 PM, Coleen Phillimore wrote: > > Looks awesome! > Thanks! > Coleen > > On 4/7/16 3:16 PM, Gerard Ziemski wrote: >> hi all, >> >> Please review this small cleanup fix, which introduces a new NMT (Native Memory Tracking) flag (ie. mtArguments) and replaces any existing, but incorrect, usages of mtInternal in argument processing related code with that new flag. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8153039 >> webrev: http://cr.openjdk.java.net/~gziemski/8153039_rev1 >> >> Passes local ?hotspot/test/runtime/NMT? jtreg tests. >> >> >> cheers >> > From mandy.chung at oracle.com Fri Apr 8 02:52:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Apr 2016 19:52:03 -0700 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> > On Apr 7, 2016, at 10:14 AM, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > > http://cr.openjdk.java.net/~chegar/8153737/ > https://bugs.openjdk.java.net/browse/JDK-8153737 I?m glad to see jdk.unsupported module be created. jdeps tests are intended to test references to sun.misc and flagged as internal API. The jdeps test changes should be reverted. It?s exported to allow existing applications to continue to run on JDK 9 while sun.misc and other critical internal APIs remains to be internal APIs. jdeps -jdkinternals should flag them and get developers? attention to prepare to migrate when the replacements are available. Other than that, looks good. There are so many tests that have @modules java.base sun/misc but unused. It?s good that you clean that up. I agree with Alan that JDK modules depending on jdk.unsupported should get the priority to get eliminated by FC. thanks Mandy From jiangli.zhou at oracle.com Fri Apr 8 02:54:30 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 7 Apr 2016 19:54:30 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <56FDFC10.2000202@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56FDFC10.2000202@oracle.com> Message-ID: <239BB5FD-3DC2-4E6B-8DCF-A8D722835357@oracle.com> Hi Calvin, Sorry for the delay. Thank you for updating the changes. The update looks good. The following comment and code in sharedRuntime.cpp are a little confusing. Could you please clarify that? 2563 // handle the case when compiler is disabled during dump time 2564 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { Thanks, Jiangli > On Mar 31, 2016, at 9:41 PM, Calvin Cheung wrote: > > Hi Jiangli, > > I've updated the fix which should address all your comments. > webrev: > http://cr.openjdk.java.net/~ccheung/8145221/webrev.02/ > changes between v.02 and v.01: > http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/ > > The trampoline code buffer is now put into the 'md' region which is made executable. > I've file the following RFE to have a separate region for the code buffer: > JDK-8153241: Add a read-write-executable shared region for runtime generated code > > thanks, > Calvin > > On 3/17/16, 9:37 PM, Jiangli Zhou wrote: >> >> Hi Calvin, >> >> The changes look good overall. Following are my comments and questions. >> >> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >> Please place the new CDS-only code under #if INCLUDE_CDS. >> >> It would be a good idea to assert the address (current pc) is within the generated trampoline entry buffer. >> >> - src/share/vm/interpreter/abstractInterpreter.cpp >> It?s not necessary to put '#include for memory/metaspaceShared.hpp' under #if INCLUDE_CDS. >> >> - src/share/vm/memory/metaspaceShared.cpp >> I see you changed ?read_only? to false for ?mc? region. Is it possible to place the trampoline code buffer in the ?md? region, so the ?mc? region does not need to be writable? It?s good to keep the ?mc? as read only so it would be easier to detect any ?accidental? writes to the region due to future changes. The ?md? can be made executable. >> >> - src/share/vm/oops/method.cpp >> Method::unlink_method() is only called from Method::remove_unshareable_info(), which happens at dump time only. Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? >> >> - src/share/vm/oops/method.hpp >> In set_interpreter_entry(), when _i2i_entry and _from_interpreted_entry are not the same as ?entry? for shared method? >> >> - src/share/vm/runtime/sharedRuntime.cpp >> Please add a comment for the change at line 2537 >> 2537 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { >> - src/share/vm/oops/constMethod.hpp >> >> ConstMethod does not seem to be the right place for ?_adapter_trampoline? since it?s set at runtime. >> >> Do you have estimate about the size increase with the generated trampolines for the shared methods? >> >> Thanks, >> Jiangli >> >>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung > wrote: >>> >>> Dean, Ioi, >>> >>> Thanks for the review and discussions. >>> >>> Here's an updated webrev: >>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>> >>> Changes in this webrev: >>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). Return if it is in the middle of a trampoline call. >>> - moved the guarantee from metaspaceShared_sparc.cpp to the common metaspaceShared.cpp; >>> - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>> >>> The last 2 changes are required due to the test failure with the hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >>> >>> Testing: >>> JPRT with testset hotspot >>> jtreg tests under hotspot/runtime on all platforms >>> >>> thanks, >>> Calvin >>> >>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>> >>> >>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>> >>>> >>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>> Hi Ioi, comments inlined below. >>>>> >>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>> Hi Dean, >>>>>> >>>>>> Thanks for raising this issue. >>>>>> >>>>>> My first impression is this probably shouldn't matter (or somehow we can get away with this). >>>>>> >>>>>> Today, the CDS archive already contains executable code in the "misc code" section. On Linux/x64, this is typically in the address range 0x802400000-0x802409000. The code is used to dynamically patch the C++ vtables of Metadata types that are stored in the CDS archive. So even today, there's a chance that the suspended PC lands in this section. >>>>>> >>>>> >>>>> OK, so you're saying that the trampolines don't make things any worse :-) >>>> >>>> Well, theoretically the i2i and c2i entries would be executed more frequently than the vtable patching code, so if there was a problem, it could be aggravated. >>>>> >>>>>> The code is generated inside MetaspaceShared::generate_vtable_methods and looks like this when you run with -Xshare:on: >>>>>> >>>>>> (gdb) x/5i 0x802400000 >>>>>> 0x802400000: mov $0x0,%eax >>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>> 0x80240000a: mov $0x1,%eax >>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>> 0x802400014: mov $0x2,%eax >>>>>> .... >>>>>> (gdb) x/16i 0x8024084d0 >>>>>> 0x8024084d0: push %rsi >>>>>> 0x8024084d1: push %rdi >>>>>> 0x8024084d2: mov %rax,%rdi >>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>> 0x8024084e7: add %rdi,%rsi >>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>> 0x8024084ed: pop %rdi >>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>> 0x8024084f1: and $0xff,%rax >>>>>> 0x8024084f8: shl $0x3,%rax >>>>>> 0x8024084fc: add %rsi,%rax >>>>>> 0x8024084ff: pop %rsi >>>>>> 0x802408500: mov (%rax),%rax >>>>>> 0x802408503: jmpq *%rax >>>>>> >>>>>> In JDK9, the profiler takes a sample by first calling into JavaThread::pd_get_top_frame_for_profiling: >>>>>> >>>>>> (gdb) where >>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, thread=0x7ffff08ce000) >>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, isInJava=true) >>>>>> #2 0x00007ffff69d70be in JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>> isInJava=true) >>>>>> >>>>>> I tried manually setting frame::_pc to 0x802400000, and it would cause frame::safe_for_sender() to return false, and thus would prevent the profiler from doing any stack walking. >>>>>> >>>>> >>>>> Was the reason safe_for_sender() failed something that we can rely on 100%? I looked at safe_for_sender, and it's not obvious why it would fail, unless the frame pointer was invalid, and I think that depends on the platform and flags like PreserveFramePointer. How about filing a separate bug to track this issue? >>>>> >>>> >>>> OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> dl >>>>> >>>>>> Also, both the CDS vtable patching code and the i2i trampolines are tail calls, so you will never find a PC in them except for the top-most frame. This means the check in JavaThread::pd_get_top_frame is enough. There's no need to do additional checks after we have started stack walking. >>>>>> >>>>>> I think the chance of landing in the CDS vtable patching methods, or in the trampolines, is pretty small, so that shouldn't bother the sampling profiler too much. >>>>>> >>>>>> Anyway, as part of this bug, we should add a regression test with the profiler enabled, and keep calling a method in the CDS archive in a tight loop (and manually disable compilation of that method using command-line options). The test should never crash, and if possible, it should also check that we don't have too many "unknown" samples. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>> >>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>> We have profiling code that will suspend a thread at random points and try to walk the stack. >>>>>>> I think frame::sender() will get confused if you happen to catch a thread in the trampoline, >>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>> >>>>>>>> This optimization reduces the size of the RW region of the CDS archive. It also reduces the amount of pages in the RW region that are actually written into during runtime. >>>>>>>> >>>>>>>> The original prototype on the x86_64 platform was done by Ioi (ioi.lam at oracle.com ). >>>>>>>> I helped porting it to other platforms. >>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com ) who provided the changes to the ppc platform. >>>>>>>> >>>>>>>> Testing: >>>>>>>> JPRT with testset hotspot >>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>> built on the Zero platform >>>>>>>> tested on the openjdk aarch64 platform >>>>>>>> refworkload on various platform (please refer to bug report for data) >>>>>>>> >>>>>>>> thanks, >>>>>>>> Calvin >>>>>>> >>>>>> >>>>> >>>> >> From robbin.ehn at oracle.com Fri Apr 8 08:08:36 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 10:08:36 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) Message-ID: <57076704.6020700@oracle.com> Hi all, Please review, Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 Tested with internal vm test (inc a new test for just this). Thanks! /Robbin From goetz.lindenmaier at sap.com Fri Apr 8 08:53:23 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 8 Apr 2016 08:53:23 +0000 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. Message-ID: Hi, The upper limit of the range for flag MaxDirectMemorySize is MAX_SIZE_T. The flag is used to set a property that is parsed into a long. Thus, the max value on 64-bit platforms is too large. Fix: Limit the range to max_jlong, too. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/wr16/8153835-MaxDMSz/webrev.01/ Best regards, Goetz. From erik.osterlund at oracle.com Fri Apr 8 09:00:18 2016 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 8 Apr 2016 11:00:18 +0200 Subject: RFR (S): 8153751: Windows Atomic and OrderAccess are not emitting explicit compiler barriers Message-ID: <57077322.3000009@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8153751 Webrev: http://cr.openjdk.java.net/~eosterlund/8153751/webrev.00/ It turns out that on Windows, compiler barriers are not used for Atomic:: code and some code in OrderAccess. It is assumed that the non-volatile accesses will not be reordered across __asm statements, as the current memory model should prevent. But I have not found any guarantees that this is the case for __asm. The closest source I could find is the documentation for the MemoryBarrier macro that uses an __asm statement to produce a hardware membar. The documentation says the following: "Creates a hardware memory barrier (fence) that prevents the CPU from re-ordering read and write operations. It may also prevent the compiler from re-ordering read and write operations." Note the "MAY" prevent compiler reordering. (*facepalm*) This sounds to me like __asm really does not guarantee compiler reordering across __asm at all. A suspected victim of this reordering is here: https://bugs.openjdk.java.net/browse/JDK-8033545 To make the use of these classes more safe, I propose to simply add explicit compiler barriers in this windows code. It should not make any difference, as I am only enforcing compiler reordering rules that should already hold. This small patch fixes this. The only thing to note is that the __asm statements that put things in %eax and avoid returning anything. Testing: JPRT Thanks, /Erik From paul.sandoz at oracle.com Fri Apr 8 10:24:08 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Apr 2016 12:24:08 +0200 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: > On 7 Apr 2016, at 19:14, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > And in the modular world it?s necessary to explicitly declare a requirement on idk.unsupported. > http://cr.openjdk.java.net/~chegar/8153737/ > https://bugs.openjdk.java.net/browse/JDK-8153737 > +1 An important milestone. Paul. From erik.osterlund at oracle.com Fri Apr 8 11:52:35 2016 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 8 Apr 2016 13:52:35 +0200 Subject: RFR(M): 8153076: Atomic::* on Solaris should use inline assembly instead of .il files Message-ID: <57079B83.5040906@oracle.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8153076 Webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.00/ On Solaris, the Atomic class puts its assembly in a separate .il file, then the code blobs are declared as extern "C" and called from Atomic. More modern GCC-style inline assembly is now supported, and we should use that instead. It works fine the way it is, but making calls just to get an instruction that could be inlined, seems suboptimal. There are two important things to note: 1) I have removed all the 32 bit code from solaris Atomic, and weird combinations with GCC and compiler1. JDK9 is only supported on 64 bit SPARC and x86, building using Solaris Studio. Since it is using GCC-style inline assembly, the code should work with GCC too, but I have not tested that as it is not a supported way of building OpenJDK. I personally do not think we should spend too much time on supporting unsupported code. 2) There appears to be a bug in Solaris Studio for emitting memory accesses on x86. The following code: inline void Atomic::inc (volatile jint* dest) { __asm__ volatile ("lock; addl $1,(%0)" : : "r" (dest) : "cc", "memory"); } generated the following in HandleMark::initialize(Thread* thread) on Solaris, x64, using SS12.4: lock addl $1, (%eax) Note the %eax instead of %rax. It is wrong and caused SIGSEGV as the address was truncated, and libraries are not put within the first 4 GB of VA. I worked around the issue by assigning the address operands to a fixed register, rdx. Being awkward with the choice of registers is still better than having to make calls. This will have to be fixed, once the solaris studio bug is fixed. Note that for SPARC there were no issues like this and the generated code is fine. Testing: JPRT I need a sponsor to push this. Thanks, /Erik From robbin.ehn at oracle.com Fri Apr 8 11:54:16 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 13:54:16 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert Message-ID: <57079BE8.5000507@oracle.com> Hi all, Please review, Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 Tested with jprt. diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 +0200 @@ -98,6 +98,7 @@ const size_t vwrite_buffer_size = 512; void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list args) { + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level is incorrect"); char buf[vwrite_buffer_size]; va_list saved_args; // For re-format on buf overflow. va_copy(saved_args, args); Thanks! /Robbin From stefan.karlsson at oracle.com Fri Apr 8 12:02:40 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 8 Apr 2016 14:02:40 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) In-Reply-To: <57076704.6020700@oracle.com> References: <57076704.6020700@oracle.com> Message-ID: <57079DE0.2080103@oracle.com> Looks good. StefanK On 2016-04-08 10:08, Robbin Ehn wrote: > Hi all, > > Please review, > > Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 > > Tested with internal vm test (inc a new test for just this). > > Thanks! > > /Robbin From robbin.ehn at oracle.com Fri Apr 8 12:11:51 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:11:51 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) In-Reply-To: <57079DE0.2080103@oracle.com> References: <57076704.6020700@oracle.com> <57079DE0.2080103@oracle.com> Message-ID: <5707A007.8000602@oracle.com> Thanks Stefan! /Robbin On 04/08/2016 02:02 PM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2016-04-08 10:08, Robbin Ehn wrote: >> Hi all, >> >> Please review, >> >> Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 >> >> Tested with internal vm test (inc a new test for just this). >> >> Thanks! >> >> /Robbin > From marcus.larsson at oracle.com Fri Apr 8 12:19:59 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 8 Apr 2016 14:19:59 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <57079BE8.5000507@oracle.com> References: <57079BE8.5000507@oracle.com> Message-ID: <5707A1EF.6080306@oracle.com> Hi Robbin, On 04/08/2016 01:54 PM, Robbin Ehn wrote: > > Hi all, > > Please review, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 > > Tested with jprt. > > diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp > --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 > +0200 > +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 > +0200 > @@ -98,6 +98,7 @@ > const size_t vwrite_buffer_size = 512; > > void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list > args) { > + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log > level is incorrect"); > char buf[vwrite_buffer_size]; > va_list saved_args; // For re-format on buf overflow. > va_copy(saved_args, args); > > Can we make the assert check "level >= LogLevel::First && level <= LogLevel::Last" instead? Thanks, Marcus > > Thanks! > > /Robbin From bengt.rutisson at oracle.com Fri Apr 8 12:16:45 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 8 Apr 2016 14:16:45 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A1EF.6080306@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A1EF.6080306@oracle.com> Message-ID: <5707A12D.50903@oracle.com> Hi Robbin, On 2016-04-08 14:19, Marcus Larsson wrote: > Hi Robbin, > > On 04/08/2016 01:54 PM, Robbin Ehn wrote: >> >> Hi all, >> >> Please review, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >> >> Tested with jprt. >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >> level is incorrect"); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); >> >> > > Can we make the assert check "level >= LogLevel::First && level <= > LogLevel::Last" instead? And can we make the error message include the actual value of "level" so we know why the assert failed? Thanks, Bengt > > Thanks, > Marcus > >> >> Thanks! >> >> /Robbin > From robbin.ehn at oracle.com Fri Apr 8 12:22:10 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:22:10 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A1EF.6080306@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A1EF.6080306@oracle.com> Message-ID: <5707A272.90207@oracle.com> Hi Marcus On 04/08/2016 02:19 PM, Marcus Larsson wrote: > Hi Robbin, > > On 04/08/2016 01:54 PM, Robbin Ehn wrote: >> >> Hi all, >> >> Please review, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >> >> Tested with jprt. >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >> level is incorrect"); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); >> >> > > Can we make the assert check "level >= LogLevel::First && level <= > LogLevel::Last" instead? Yes, I have no issues with that. /Robbin > > Thanks, > Marcus > >> >> Thanks! >> >> /Robbin > From robbin.ehn at oracle.com Fri Apr 8 12:24:15 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:24:15 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A12D.50903@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A1EF.6080306@oracle.com> <5707A12D.50903@oracle.com> Message-ID: <5707A2EF.3090201@oracle.com> Hi Bengt, On 04/08/2016 02:16 PM, Bengt Rutisson wrote: > > Hi Robbin, > > On 2016-04-08 14:19, Marcus Larsson wrote: >> Hi Robbin, >> >> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>> >>> Hi all, >>> >>> Please review, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>> >>> Tested with jprt. >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >>> level is incorrect"); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >>> >>> >> >> Can we make the assert check "level >= LogLevel::First && level <= >> LogLevel::Last" instead? > > And can we make the error message include the actual value of "level" so > we know why the assert failed? > Yes, no problem. Thanks! /Robbin > Thanks, > Bengt > >> >> Thanks, >> Marcus >> >>> >>> Thanks! >>> >>> /Robbin >> > From robbin.ehn at oracle.com Fri Apr 8 12:28:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:28:00 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <57079BE8.5000507@oracle.com> References: <57079BE8.5000507@oracle.com> Message-ID: <5707A3D0.8010207@oracle.com> Hi all, Updated after reviews: diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 +0200 @@ -98,6 +98,7 @@ const size_t vwrite_buffer_size = 512; void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list args) { + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log level:%d is incorrect", level); char buf[vwrite_buffer_size]; va_list saved_args; // For re-format on buf overflow. va_copy(saved_args, args); Thanks! /Robbin On 04/08/2016 01:54 PM, Robbin Ehn wrote: > > Hi all, > > Please review, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 > > Tested with jprt. > > diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp > --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 > +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 +0200 > @@ -98,6 +98,7 @@ > const size_t vwrite_buffer_size = 512; > > void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list > args) { > + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level > is incorrect"); > char buf[vwrite_buffer_size]; > va_list saved_args; // For re-format on buf overflow. > va_copy(saved_args, args); > > > > Thanks! > > /Robbin From erik.osterlund at oracle.com Fri Apr 8 12:36:53 2016 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 8 Apr 2016 14:36:53 +0200 Subject: RFR(M): 8152995: Solaris os::available_memory() doesn't do what we think it does In-Reply-To: <570539FE.3060406@oracle.com> References: <5705187E.3020000@oracle.com> <570539FE.3060406@oracle.com> Message-ID: <5707A5E5.8020409@oracle.com> Hi Daniel, Thanks for having a look at this. On 2016-04-06 18:31, Daniel D. Daugherty wrote: > Erik, > > Thanks for adding Runtime to this discussion. The topic is definitely > of interest to Runtime folks... > > More below... > > > On 2016-04-06 16:09, Erik ?sterlund wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152995 >> CR: http://cr.openjdk.java.net/~eosterlund/8152995/webrev.00/ >> >> On Solaris, the os::available_memory() function is currently >> calculated with sysconf(_SC_AVPHYS_PAGES). > > The Solaris man page for sysconf(_SC_AVPHYS_PAGES): > > _SC_AVPHYS_PAGES Number of physical memory pages not > currently in use by system Yes. After drilling down the details, it returns the amount of physical memory not used by the virtual memory system. But when you mmap without NORESERVE, no physical memory is actually paged in until memory starts to be touched. Therefore this metric corresponds to how much memory is available *for the kernel* to satisfy page faults, rather than how much memory is available *for applications* to satisfy allocations. These two interpretations are completely orthogonal: the amount of memory available for the kernel has no relation to the amount of memory available for applications, and the amount of memory available for applications has no relation to the amount of memory available in the kernel. It is safe to say that what is being asked for, is available memory to satisfy allocations, and not how much memory the kernel has at its disposal for internal use. > >> Unfortunately this does not match intended semantics. The intended >> semantics is to return how much memory can be allocated by mmap into >> physical memory. But, what _SC_AVPHYS_PAGES does is to return how many >> physical pages are available to be used by virtual memory as backing >> storage on-demand once it is touched, without any connection >> whatsoever to virtual memory. > > This part has me curious: > > > The intended semantics is to return how much memory can be allocated > > by mmap into physical memory. > > since I don't understand where you found the "intended semantics". Unfortunately I can't tell you this in the open list. > Only one of the platforms has any comments about available_memory: > > src/os/bsd/vm/os_bsd.cpp: > > // available here means free > julong os::Bsd::available_memory() { > > the rest just don't say... > > Personally, I've always interpreted available_memory() to mean > available physical pages, as in pages that are not in use now. > This matches the definition of _SC_AVPHYS_PAGES above... So your version of available memory depends on how much memory is "in use". In use by who? As you can see, this also leaves room for interpretations - use by the kernel to satisfy page faults or use by applications to satisfy allocations. You just flipped it. And yes, interpretations have indeed been personal and not very well defined, which is obvious from the code. Let me summarize the current situation: Windows: Returns the amount of physical memory (RAM) that is available and can be used to satisfy allocations. Linux: Returns the amount of physical memory in the freelist that can be used to satisfy allocations. But there is in fact a lot more memory available. The freelist can be seen as memory wasted by the OS. It tries to use physical memory for things like file caches to boost performance, but that memory is in fact available if anyone starts allocating. So it will return less memory than is in fact available, contrary to the name of the function. This is also misleading and arguably wrong. BSD: Seems to also return the amount of free rather than available memory, to satisfy allocations, contrary to the name of the function. Solaris: Returns the amount of physical memory not paged in, to satisfy page faults, invariantly of the amount of memory available to satisfy allocations. In summary: *All OS implementations seem to consistently disregard swap page and not consider it available memory. * The meaning is mixed between available memory to satisfy application allocations, available memory for the kernel to use to satisfy page faults, and immediately free memory (rather than available memory) to satisfy allocations. I think that due to the lack of a clear definition, people have used any preferred interpretation. > >> Even if we mmap to commit heap memory without NORESERVE, the >> _SC_AVPHYS_PAGES metric does not change its value - at least not until >> somebody actually touches the mmaped memory and it starts becoming >> backed by actual physical memory. So the JVM can in theory commit the >> whole physical memory, and _SC_AVPHYS_PAGES will still reply that all >> that memory is still available given that it has not been touched yet. > > Yes, I believe that is exactly how things work and I think > that available_memory() is returning that information > correctly. Solaris is AFAIK the only OS to make this interpretation, and it is arguably not useful for the users as it does not correspond to memory that applications can use to satisfy allocations. But due to the lack of a definition, I can't say you are wrong, just have opinions about it and point out Solaris is the only OS with this interpretation, and that people have been very confused about it. > >> It is likely that this is related to random swap-related test >> failures, where too many JVMs are created based on this metric. > > Please explain further. What do you mean by "too many JVMs are > created based on this metric"? Well I guess the problem is that people run many JVMs at the same time and then some JVM crashes complaining that it is out of swap memory and hence can't run any longer, while available_memory says there are multiple gigabytes of available memory. This is very confusing for users. The reason is, as I said, that the memory has not been paged in yet, and therefore there appears to be lots of memory available, but none of it can be used to satisfy allocations, leading to failures. > >> Even >> if it is not, the os::available_memory() call is still broken in its >> current state and should be fixed regardless. > > I'm not yet convinced that available_memory() is broken > and needs to be fixed. I don't see available_memory() being > used in a lot of places and those uses that I do see are > mostly just reports of the value... > > So what am I missing about how os::available_memory() is > being used? The reports are very problematic though. It's better to not report anything than to report misleading, incorrect numbers. If we report a number, then that number should be correct and useful. I also think that whether available_memory() is broken or not has nothing to do with how often it is being used. It reports misleading numbers, and that leads to unnecessary confusion. People are very confused about Solaris swap issues. A contributing reason is that reported values are not what people think they are. Therefore it needs a fix. Thanks, /Erik > Dan > > > >> My proposed fix uses kstat to get the available memory that can be >> mmapped (which actually relates to virtual memory). It then uses >> swapctl() to find out the amount of free swap, subtracting that from >> the kstat value, to make sure we do not count swap memory as being >> available for grabbing, to mimick the current behaviour of other >> platforms. The code iterates over the potentially many swap resources >> and adds up the free swap memory. >> >> kstat gives us all memory that can be made available, including memory >> already used by the OS for things like file caches, and swap memory. >> When this value is 0, mmap will fail. That's why I calculate the >> amount of swap and remove that, assuming it is okay to use memory that >> isn't immediately available but can be made available, as long as it >> does not involve paging to the swap memory. >> >> Testing: >> * JPRT >> * Made my own test program that can be found in the comments of the >> BUG to report on memory values, so I could verify what is going on and >> that when the new os::available_memory() becomes 0, is indeed when >> paging to swap starts happening using vmstat. >> >> I need a sponsor to push this if anyone is interested. >> >> Thanks, >> /Erik > From robbin.ehn at oracle.com Fri Apr 8 12:44:21 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:44:21 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <5704B0B0.4010404@oracle.com> References: <5704B0B0.4010404@oracle.com> Message-ID: <5707A7A5.5010302@oracle.com> Hi Marcus Your change looks good. Thanks! /Robbin On 04/06/2016 08:46 AM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add a warning for when tag > selections in -Xlog or VM.log don't match any tag sets used in the VM. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8150894 > > Testing: > Internal VM tests with RBT > > Thanks, > Marcus From robbin.ehn at oracle.com Fri Apr 8 12:45:45 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 14:45:45 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A3D0.8010207@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> Message-ID: <5707A7F9.70701@oracle.com> Hi again, I missed LogLevel:Off, it should be: diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 +0200 @@ -98,6 +98,7 @@ const size_t vwrite_buffer_size = 512; void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list args) { + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log level:%d is incorrect", level); char buf[vwrite_buffer_size]; va_list saved_args; // For re-format on buf overflow. va_copy(saved_args, args); Thanks ! /Robbin On 04/08/2016 02:28 PM, Robbin Ehn wrote: > Hi all, > > Updated after reviews: > > diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp > --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 +0200 > +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 +0200 > @@ -98,6 +98,7 @@ > const size_t vwrite_buffer_size = 512; > > void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list > args) { > + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log > level:%d is incorrect", level); > char buf[vwrite_buffer_size]; > va_list saved_args; // For re-format on buf overflow. > va_copy(saved_args, args); > > Thanks! > > /Robbin > > On 04/08/2016 01:54 PM, Robbin Ehn wrote: >> >> Hi all, >> >> Please review, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >> >> Tested with jprt. >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level >> is incorrect"); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); >> >> >> >> Thanks! >> >> /Robbin From marcus.larsson at oracle.com Fri Apr 8 12:48:02 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 8 Apr 2016 14:48:02 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) In-Reply-To: <57076704.6020700@oracle.com> References: <57076704.6020700@oracle.com> Message-ID: <5707A882.6040900@oracle.com> Hi Robbin, On 04/08/2016 10:08 AM, Robbin Ehn wrote: > Hi all, > > Please review, > > Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ I just have one suggestion for a slightly better assert message: "Combination limit (" SIZE_FORMAT ") not sufficient for configuring all available tag sets (" SIZE_FORMAT ")" Other than that, this looks good. Thanks for fixing this! I don't need to see another webrev. Thanks, Marcus > Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 > > Tested with internal vm test (inc a new test for just this). > > Thanks! > > /Robbin From robbin.ehn at oracle.com Fri Apr 8 13:23:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 15:23:17 +0200 Subject: RFR(s): 8153731: Increase max tag combinations for UL expression (config) In-Reply-To: <5707A882.6040900@oracle.com> References: <57076704.6020700@oracle.com> <5707A882.6040900@oracle.com> Message-ID: <5707B0C5.1080108@oracle.com> Hi Marcus On 04/08/2016 02:48 PM, Marcus Larsson wrote: > Hi Robbin, > > On 04/08/2016 10:08 AM, Robbin Ehn wrote: >> Hi all, >> >> Please review, >> >> Webrev: http://cr.openjdk.java.net/~rehn/8153731/webrev/ > > I just have one suggestion for a slightly better assert message: > "Combination limit (" SIZE_FORMAT ") not sufficient for configuring all > available tag sets (" SIZE_FORMAT ")" > I'll change the message, thanks! /Robbin > Other than that, this looks good. Thanks for fixing this! I don't need > to see another webrev. > > Thanks, > Marcus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153731 >> >> Tested with internal vm test (inc a new test for just this). >> >> Thanks! >> >> /Robbin > From bengt.rutisson at oracle.com Fri Apr 8 13:26:50 2016 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Fri, 8 Apr 2016 15:26:50 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707A7F9.70701@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> <5707A7F9.70701@oracle.com> Message-ID: <5707B19A.1070005@oracle.com> Hi Robbin, On 2016-04-08 14:45, Robbin Ehn wrote: > Hi again, > > I missed LogLevel:Off, it should be: > > diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp > --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 > +0200 > +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 > +0200 > @@ -98,6 +98,7 @@ > const size_t vwrite_buffer_size = 512; > > void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list > args) { > + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log > level:%d is incorrect", level); > char buf[vwrite_buffer_size]; > va_list saved_args; // For re-format on buf overflow. > va_copy(saved_args, args); Looks good. Bengt > > > Thanks ! > > /Robbin > > On 04/08/2016 02:28 PM, Robbin Ehn wrote: >> Hi all, >> >> Updated after reviews: >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log >> level:%d is incorrect", level); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); >> >> Thanks! >> >> /Robbin >> >> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>> >>> Hi all, >>> >>> Please review, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>> >>> Tested with jprt. >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level >>> is incorrect"); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >>> >>> >>> >>> Thanks! >>> >>> /Robbin From robbin.ehn at oracle.com Fri Apr 8 13:38:20 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 15:38:20 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707B19A.1070005@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> <5707A7F9.70701@oracle.com> <5707B19A.1070005@oracle.com> Message-ID: <5707B44C.8060007@oracle.com> Thanks Bengt! /Robbin On 04/08/2016 03:26 PM, Bengt Rutisson wrote: > > Hi Robbin, > > On 2016-04-08 14:45, Robbin Ehn wrote: >> Hi again, >> >> I missed LogLevel:Off, it should be: >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log >> level:%d is incorrect", level); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); > > Looks good. > > Bengt > >> >> >> Thanks ! >> >> /Robbin >> >> On 04/08/2016 02:28 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Updated after reviews: >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log >>> level:%d is incorrect", level); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >>> >>> Thanks! >>> >>> /Robbin >>> >>> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>>> >>>> Hi all, >>>> >>>> Please review, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>>> >>>> Tested with jprt. >>>> >>>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>>> +0200 >>>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>>> +0200 >>>> @@ -98,6 +98,7 @@ >>>> const size_t vwrite_buffer_size = 512; >>>> >>>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>>> args) { >>>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log level >>>> is incorrect"); >>>> char buf[vwrite_buffer_size]; >>>> va_list saved_args; // For re-format on buf overflow. >>>> va_copy(saved_args, args); >>>> >>>> >>>> >>>> Thanks! >>>> >>>> /Robbin > From marcus.larsson at oracle.com Fri Apr 8 13:41:25 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 8 Apr 2016 15:41:25 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707B19A.1070005@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> <5707A7F9.70701@oracle.com> <5707B19A.1070005@oracle.com> Message-ID: <5707B505.1090506@oracle.com> On 04/08/2016 03:26 PM, Bengt Rutisson wrote: > > Hi Robbin, > > On 2016-04-08 14:45, Robbin Ehn wrote: >> Hi again, >> >> I missed LogLevel:Off, it should be: >> >> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >> +0200 >> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 >> +0200 >> @@ -98,6 +98,7 @@ >> const size_t vwrite_buffer_size = 512; >> >> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >> args) { >> + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log >> level:%d is incorrect", level); >> char buf[vwrite_buffer_size]; >> va_list saved_args; // For re-format on buf overflow. >> va_copy(saved_args, args); > > Looks good. +1 Marcus > > Bengt > >> >> >> Thanks ! >> >> /Robbin >> >> On 04/08/2016 02:28 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Updated after reviews: >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log >>> level:%d is incorrect", level); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >>> >>> Thanks! >>> >>> /Robbin >>> >>> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>>> >>>> Hi all, >>>> >>>> Please review, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>>> >>>> Tested with jprt. >>>> >>>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>>> +0200 >>>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>>> +0200 >>>> @@ -98,6 +98,7 @@ >>>> const size_t vwrite_buffer_size = 512; >>>> >>>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>>> args) { >>>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >>>> level >>>> is incorrect"); >>>> char buf[vwrite_buffer_size]; >>>> va_list saved_args; // For re-format on buf overflow. >>>> va_copy(saved_args, args); >>>> >>>> >>>> >>>> Thanks! >>>> >>>> /Robbin > From robbin.ehn at oracle.com Fri Apr 8 13:40:57 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 8 Apr 2016 15:40:57 +0200 Subject: RFR(xs): 8153845: UL log write method missing essential assert In-Reply-To: <5707B505.1090506@oracle.com> References: <57079BE8.5000507@oracle.com> <5707A3D0.8010207@oracle.com> <5707A7F9.70701@oracle.com> <5707B19A.1070005@oracle.com> <5707B505.1090506@oracle.com> Message-ID: <5707B4E9.3070502@oracle.com> Thanks Marcus! /Robbin On 04/08/2016 03:41 PM, Marcus Larsson wrote: > > > On 04/08/2016 03:26 PM, Bengt Rutisson wrote: >> >> Hi Robbin, >> >> On 2016-04-08 14:45, Robbin Ehn wrote: >>> Hi again, >>> >>> I missed LogLevel:Off, it should be: >>> >>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>> +0200 >>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:44:33 2016 >>> +0200 >>> @@ -98,6 +98,7 @@ >>> const size_t vwrite_buffer_size = 512; >>> >>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>> args) { >>> + assert(level >= LogLevel::First && level <= LogLevel::Last, "Log >>> level:%d is incorrect", level); >>> char buf[vwrite_buffer_size]; >>> va_list saved_args; // For re-format on buf overflow. >>> va_copy(saved_args, args); >> >> Looks good. > > +1 > > Marcus > >> >> Bengt >> >>> >>> >>> Thanks ! >>> >>> /Robbin >>> >>> On 04/08/2016 02:28 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Updated after reviews: >>>> >>>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>>> +0200 >>>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 14:26:44 2016 >>>> +0200 >>>> @@ -98,6 +98,7 @@ >>>> const size_t vwrite_buffer_size = 512; >>>> >>>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>>> args) { >>>> + assert(level >= LogLevel::Off && level <= LogLevel::Last, "Log >>>> level:%d is incorrect", level); >>>> char buf[vwrite_buffer_size]; >>>> va_list saved_args; // For re-format on buf overflow. >>>> va_copy(saved_args, args); >>>> >>>> Thanks! >>>> >>>> /Robbin >>>> >>>> On 04/08/2016 01:54 PM, Robbin Ehn wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please review, >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153845 >>>>> >>>>> Tested with jprt. >>>>> >>>>> diff -r 35cb720769c5 src/share/vm/logging/logTagSet.cpp >>>>> --- a/src/share/vm/logging/logTagSet.cpp Fri Apr 08 08:51:45 2016 >>>>> +0200 >>>>> +++ b/src/share/vm/logging/logTagSet.cpp Fri Apr 08 13:39:12 2016 >>>>> +0200 >>>>> @@ -98,6 +98,7 @@ >>>>> const size_t vwrite_buffer_size = 512; >>>>> >>>>> void LogTagSet::vwrite(LogLevelType level, const char* fmt, va_list >>>>> args) { >>>>> + assert(level >= LogLevel::Off && level < LogLevel::Count, "Log >>>>> level >>>>> is incorrect"); >>>>> char buf[vwrite_buffer_size]; >>>>> va_list saved_args; // For re-format on buf overflow. >>>>> va_copy(saved_args, args); >>>>> >>>>> >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin >> > From marcus.larsson at oracle.com Fri Apr 8 14:24:15 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 8 Apr 2016 16:24:15 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <5707A7A5.5010302@oracle.com> References: <5704B0B0.4010404@oracle.com> <5707A7A5.5010302@oracle.com> Message-ID: <5707BF0F.9020603@oracle.com> Thanks Robbin! Marcus On 04/08/2016 02:44 PM, Robbin Ehn wrote: > Hi Marcus > > Your change looks good. > > Thanks! > > /Robbin > > On 04/06/2016 08:46 AM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add a warning for when tag >> selections in -Xlog or VM.log don't match any tag sets used in the VM. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8150894 >> >> Testing: >> Internal VM tests with RBT >> >> Thanks, >> Marcus From peter.levart at gmail.com Fri Apr 8 14:31:32 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 8 Apr 2016 16:31:32 +0200 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: <5707C0C4.1070209@gmail.com> On 04/08/2016 12:24 PM, Paul Sandoz wrote: >> On 7 Apr 2016, at 19:14, Chris Hegarty wrote: >> >> Enough technical debt has been paid down that we can now create the new >> JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. >> This module will initially contain, and export, the sun.misc package, >> and will eventually export the sun.reflect package too ( once it has >> been sanitized ). The jdk.unsupported module will be present in full JRE >> and JDK images. >> > And in the modular world it?s necessary to explicitly declare a requirement on idk.unsupported. Will jdk.unsupported be "required public" by java.se? Will you have to explicitly -addmodule jdk.unsupported for class-path programs too? Regards, Peter > >> http://cr.openjdk.java.net/~chegar/8153737/ >> https://bugs.openjdk.java.net/browse/JDK-8153737 >> > +1 > > An important milestone. > > Paul. From chris.hegarty at oracle.com Fri Apr 8 14:37:39 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Apr 2016 15:37:39 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5707C0C4.1070209@gmail.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <5707C0C4.1070209@gmail.com> Message-ID: <5707C233.6010509@oracle.com> On 08/04/16 15:31, Peter Levart wrote: > > > On 04/08/2016 12:24 PM, Paul Sandoz wrote: >>> On 7 Apr 2016, at 19:14, Chris Hegarty wrote: >>> >>> Enough technical debt has been paid down that we can now create the new >>> JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. >>> This module will initially contain, and export, the sun.misc package, >>> and will eventually export the sun.reflect package too ( once it has >>> been sanitized ). The jdk.unsupported module will be present in full JRE >>> and JDK images. >>> >> And in the modular world it?s necessary to explicitly declare a >> requirement on idk.unsupported. > > Will jdk.unsupported be "required public" by java.se? No. Since jdk.unsupported will be in the JDK and JRE images, and it exports sun.misc, then it will be available ( see below ). > Will you have to > explicitly -addmodule jdk.unsupported for class-path programs too? Applications running on the class path will be able to access sun.misc without any command line flags, since it is exported. Modular applications, if they wish to use sun.misc, will have to 'require jdk.unsupported'. -Chris. > Regards, Peter > >> >>> http://cr.openjdk.java.net/~chegar/8153737/ >>> https://bugs.openjdk.java.net/browse/JDK-8153737 >>> >> +1 >> >> An important milestone. >> >> Paul. > From Alan.Bateman at oracle.com Fri Apr 8 14:42:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Apr 2016 15:42:27 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5707C0C4.1070209@gmail.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <5707C0C4.1070209@gmail.com> Message-ID: <5707C353.8030902@oracle.com> On 08/04/2016 15:31, Peter Levart wrote: > > Will jdk.unsupported be "required public" by java.se? No because jdk.* are JDK-specific and should never be required by standard modules. > Will you have to explicitly -addmodule jdk.unsupported for class-path > programs too? It exports an API and therefore will be treated as a root module, so no -addmods. If you develop your own module that uses sun.misc.Unsafe then it will of course need to declare its dependency on jdk.unsupported. -Alan. From daniel.daugherty at oracle.com Fri Apr 8 15:18:15 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Apr 2016 09:18:15 -0600 Subject: RFR(M): 8152995: Solaris os::available_memory() doesn't do what we think it does In-Reply-To: <5707A5E5.8020409@oracle.com> References: <5705187E.3020000@oracle.com> <570539FE.3060406@oracle.com> <5707A5E5.8020409@oracle.com> Message-ID: <5707CBB7.8040606@oracle.com> Hi Erik, Lots of info here. Thanks! Just a few embedded replies below... On 4/8/16 6:36 AM, Erik ?sterlund wrote: > Hi Daniel, > > Thanks for having a look at this. > > On 2016-04-06 18:31, Daniel D. Daugherty wrote: >> Erik, >> >> Thanks for adding Runtime to this discussion. The topic is definitely >> of interest to Runtime folks... >> >> More below... >> >> >> On 2016-04-06 16:09, Erik ?sterlund wrote: >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152995 >>> CR: http://cr.openjdk.java.net/~eosterlund/8152995/webrev.00/ >>> >>> On Solaris, the os::available_memory() function is currently >>> calculated with sysconf(_SC_AVPHYS_PAGES). >> >> The Solaris man page for sysconf(_SC_AVPHYS_PAGES): >> >> _SC_AVPHYS_PAGES Number of physical memory pages not >> currently in use by system > > Yes. After drilling down the details, it returns the amount of > physical memory not used by the virtual memory system. But when you > mmap without NORESERVE, no physical memory is actually paged in until > memory starts to be touched. Therefore this metric corresponds to how > much memory is available *for the kernel* to satisfy page faults, > rather than how much memory is available *for applications* to satisfy > allocations. These two interpretations are completely orthogonal: the > amount of memory available for the kernel has no relation to the > amount of memory available for applications, and the amount of memory > available for applications has no relation to the amount of memory > available in the kernel. It is safe to say that what is being asked > for, is available memory to satisfy allocations, and not how much > memory the kernel has at its disposal for internal use. These are two interesting distinctions: - how much memory is available *for the kernel* to satisfy page faults - how much memory is available *for applications* to satisfy allocations and I'm having difficulty understanding why you are splitting the hair this way. Yes, I'm saying there's not much difference here. If the kernel has a page available to satisfy a page fault, then an application has that page available for use to satisfy an allocation. In my mind, an allocation is a use of the page and not a reservation of a page. Let's take a couple of steps back... The JVM does advanced memory allocation. By that I mean that the JVM does not simply use malloc()/free() to allocate and deallocate memory. The malloc()/free() world is simple and you won't run into swap space issues. OK, you can run into swap space issues, but not the same swap space issues we're talking about. So the JVM's use of advanced memory allocation means that we have to be prepared for more complicated memory allocation failures. We also have to be run in a system that is properly configured for applications that use advance memory allocation. The JVM's use of a reserve, commit and touch model means that we have to be prepared for things to go wrong at each stage of the advanced memory allocation model. When the JVM reserves a page: - if the reservation works, then all that means is that the kernel _thinks_ that it can satisfy a _future_ use of that page - if the reservation doesn't work, then the JVM dies (and it should) When the JVM commits a page: - if the commit works, then all that means is that the kernel has been able to allocate a backing page (swap) for the reserved page. Note: the RAM page may not have been touched yet, all the application did so far is change the mapping on the page that it had reserved - On Solaris, if a backing page (swap) cannot be allocated at this time, then the commit attempt fails and we get: #define EAGAIN 11 /* Resource temporarily unavailable */ On Solaris and Linux, if the attempt to change a reserved page to a committed page fails, then we have to kill the JVM because we may have lost the reservation. MacOS X is clear that the reservation is not lost and I think Windows is the same as MacOS X. - Note that just because we have a reserved a page, that does not mean we'll be able to convert it to a committed page in the future. When the kernel allowed us to reserve the page, that was its best guess at the time of the reservation. When the JVM touches a page: - At this point, the reserved RAM page is finally used and the Solaris kernel won't count it in sysconf(_SC_AVPHYS_PAGES). So how does the above relate to these two statements: - how much memory is available *for the kernel* to satisfy page faults - how much memory is available *for applications* to satisfy allocations My point is that if the kernel tells you it has a page available, then the application can presume that it has a page available to satisfy an allocation. However, the application has to be prepared for the case where that available page is taken by another process and react accordingly. > >> >>> Unfortunately this does not match intended semantics. The intended >>> semantics is to return how much memory can be allocated by mmap into >>> physical memory. But, what _SC_AVPHYS_PAGES does is to return how many >>> physical pages are available to be used by virtual memory as backing >>> storage on-demand once it is touched, without any connection >>> whatsoever to virtual memory. >> >> This part has me curious: >> >> > The intended semantics is to return how much memory can be allocated >> > by mmap into physical memory. >> >> since I don't understand where you found the "intended semantics". > > Unfortunately I can't tell you this in the open list. Please add a confidential note to the bug report. :-) > >> Only one of the platforms has any comments about available_memory: >> >> src/os/bsd/vm/os_bsd.cpp: >> >> // available here means free >> julong os::Bsd::available_memory() { >> >> the rest just don't say... >> >> Personally, I've always interpreted available_memory() to mean >> available physical pages, as in pages that are not in use now. >> This matches the definition of _SC_AVPHYS_PAGES above... > > So your version of available memory depends on how much memory is "in > use". In use by who? As you can see, this also leaves room for > interpretations - use by the kernel to satisfy page faults or use by > applications to satisfy allocations. You just flipped it. > > And yes, interpretations have indeed been personal and not very well > defined, which is obvious from the code. Let me summarize the current > situation: > > Windows: Returns the amount of physical memory (RAM) that is available > and can be used to satisfy allocations. > > Linux: Returns the amount of physical memory in the freelist that can > be used to satisfy allocations. But there is in fact a lot more memory > available. The freelist can be seen as memory wasted by the OS. It > tries to use physical memory for things like file caches to boost > performance, but that memory is in fact available if anyone starts > allocating. So it will return less memory than is in fact available, > contrary to the name of the function. This is also misleading and > arguably wrong. > > BSD: Seems to also return the amount of free rather than available > memory, to satisfy allocations, contrary to the name of the function. > > Solaris: Returns the amount of physical memory not paged in, to > satisfy page faults, invariantly of the amount of memory available to > satisfy allocations. I'm not quite sure why you are describing Solaris this way. Based on the man page 1-liner: _SC_AVPHYS_PAGES Number of physical memory pages not currently in use by system Solaris sounds the same as Windows above. > > In summary: > *All OS implementations seem to consistently disregard swap page and > not consider it available memory. > * The meaning is mixed between available memory to satisfy application > allocations, available memory for the kernel to use to satisfy page > faults, and immediately free memory (rather than available memory) to > satisfy allocations. > > I think that due to the lack of a clear definition, people have used > any preferred interpretation. The fact that the different platforms have different implied meanings for os::available_memory() is the real bug here. This kind of inconsistency is "not a good thing" (TM). :-) > >> >>> Even if we mmap to commit heap memory without NORESERVE, the >>> _SC_AVPHYS_PAGES metric does not change its value - at least not until >>> somebody actually touches the mmaped memory and it starts becoming >>> backed by actual physical memory. So the JVM can in theory commit the >>> whole physical memory, and _SC_AVPHYS_PAGES will still reply that all >>> that memory is still available given that it has not been touched yet. >> >> Yes, I believe that is exactly how things work and I think >> that available_memory() is returning that information >> correctly. > > Solaris is AFAIK the only OS to make this interpretation, and it is > arguably not useful for the users as it does not correspond to memory > that applications can use to satisfy allocations. I'll have to wait for your next reply to understand your distinction between an available physical page and a page that can be used to satisfy an applications page allocation request. I'm just not seeing it yet... > But due to the lack of a definition, I can't say you are wrong, just > have opinions about it and point out Solaris is the only OS with this > interpretation, and that people have been very confused about it. Based on what you've written here, it looks to me like Solaris and Windows have the same interpretation, but, again, I'll wait for your reply... > >> >>> It is likely that this is related to random swap-related test >>> failures, where too many JVMs are created based on this metric. >> >> Please explain further. What do you mean by "too many JVMs are >> created based on this metric"? > > Well I guess the problem is that people run many JVMs at the same time > and then some JVM crashes complaining that it is out of swap memory > and hence can't run any longer, while available_memory says there are > multiple gigabytes of available memory. This is very confusing for > users. The reason is, as I said, that the memory has not been paged in > yet, and therefore there appears to be lots of memory available, but > none of it can be used to satisfy allocations, leading to failures. Hmmm... there might be the beginnings of something here that will help the two of us reach the same place... I'll have to come back to this paragraph after I see your next reply... > >> >>> Even >>> if it is not, the os::available_memory() call is still broken in its >>> current state and should be fixed regardless. >> >> I'm not yet convinced that available_memory() is broken >> and needs to be fixed. I don't see available_memory() being >> used in a lot of places and those uses that I do see are >> mostly just reports of the value... >> >> So what am I missing about how os::available_memory() is >> being used? > > The reports are very problematic though. It's better to not report > anything than to report misleading, incorrect numbers. If we report a > number, then that number should be correct and useful. Well... we haven't yet reached agreement on what correct means here. Hopefully we will soon... > I also think that whether available_memory() is broken or not has > nothing to do with how often it is being used. My point here was two fold: 1) The two of us don't yet agree that it is broken. 2) Even if it was broken, I didn't and still don't see how the broken information is leading to an issue. The JVM is not using the value of os::available_memory() for any allocation policy what so ever. > It reports misleading numbers, and that leads to unnecessary confusion. Again, we don't (yet) agree that the numbers are misleading. At this point, I'll agree that the different platforms give different answers and that's a problem. > People are very confused about Solaris swap issues. Yes, they are. I've written about how advanced memory allocation algorithms require smart swap space management several times now. > A contributing reason is that reported values are not what people > think they are. Therefore it needs a fix. I agree that we need to do something about making what os::available_memory() reports consistent and documented. I agree that there is confusion. It will be difficult to get agreement on what os::available_memory() _should_ report. There will be differing opinions... :-) I think I've made my preference clear. I want the lowest level answer (free pages of memory from the kernel's POV). I want the system to trust me to know that the answer to my query can and will change right after I receive that answer. And the system should trust me to code my application accordingly. Erik, this is a wonderful thread. I'll leave it up to you as for how much should be copied to the bug report. Dan > > Thanks, > /Erik > >> Dan >> >> >> >>> My proposed fix uses kstat to get the available memory that can be >>> mmapped (which actually relates to virtual memory). It then uses >>> swapctl() to find out the amount of free swap, subtracting that from >>> the kstat value, to make sure we do not count swap memory as being >>> available for grabbing, to mimick the current behaviour of other >>> platforms. The code iterates over the potentially many swap resources >>> and adds up the free swap memory. >>> >>> kstat gives us all memory that can be made available, including memory >>> already used by the OS for things like file caches, and swap memory. >>> When this value is 0, mmap will fail. That's why I calculate the >>> amount of swap and remove that, assuming it is okay to use memory that >>> isn't immediately available but can be made available, as long as it >>> does not involve paging to the swap memory. >>> >>> Testing: >>> * JPRT >>> * Made my own test program that can be found in the comments of the >>> BUG to report on memory values, so I could verify what is going on and >>> that when the new os::available_memory() becomes 0, is indeed when >>> paging to swap starts happening using vmstat. >>> >>> I need a sponsor to push this if anyone is interested. >>> >>> Thanks, >>> /Erik >> > From chris.hegarty at oracle.com Fri Apr 8 15:22:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Apr 2016 16:22:56 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5706AD94.8030701@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <5706AD94.8030701@oracle.com> Message-ID: <5707CCD0.30005@oracle.com> On 07/04/16 19:57, Alan Bateman wrote: > On 07/04/2016 18:14, Chris Hegarty wrote: >> Enough technical debt has been paid down that we can now create the new >> JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. >> This module will initially contain, and export, the sun.misc package, >> and will eventually export the sun.reflect package too ( once it has >> been sanitized ). The jdk.unsupported module will be present in full JRE >> and JDK images. >> >> http://cr.openjdk.java.net/~chegar/8153737/ > It's great to get to this milestone. > > I looked over the webrev and I don't see any issues. Thanks for the Review. > I'm surprised by > the number of tests that had @modules java.base/sun.misc even though > they aren't using anything in sun.misc. It was surprising to me too. > I see Phil has pushed JDK-8147544 to jdk9/client rather than jdk9/dev so > it means that the module-info.java for java.desktop will need to be > fixed up when it gets to jdk9/dev. Right. I have my eye on that, and will fix it once in jdk9/dev. > I think we should bump the priority of all the issues that cause you to > add `requires jdk.unsupported`we should at least get all of them > resolved by FC as we shouldn't have any standard modules with this > dependence. I bumped the priority, and targeted the issues to 9. -Chris. From chris.hegarty at oracle.com Fri Apr 8 15:35:23 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 8 Apr 2016 16:35:23 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> Message-ID: <5707CFBB.8020809@oracle.com> On 08/04/16 03:52, Mandy Chung wrote: > >> On Apr 7, 2016, at 10:14 AM, Chris Hegarty wrote: >> >> Enough technical debt has been paid down that we can now create the new >> JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. >> This module will initially contain, and export, the sun.misc package, >> and will eventually export the sun.reflect package too ( once it has >> been sanitized ). The jdk.unsupported module will be present in full JRE >> and JDK images. >> >> http://cr.openjdk.java.net/~chegar/8153737/ >> https://bugs.openjdk.java.net/browse/JDK-8153737 > > I?m glad to see jdk.unsupported module be created. > > jdeps tests are intended to test references to sun.misc and flagged as internal API. The jdeps test changes should be reverted. > > It?s exported to allow existing applications to continue to run on JDK 9 while sun.misc and other critical internal APIs remains to be internal APIs. jdeps -jdkinternals should flag them and get developers? attention to prepare to migrate when the replacements are available. I moved the tests from a directory named 'jdk.unsupported' to unsupported', as other tests, in test/tools/jdeps/module, use test/tools/jdeps as a test library, and the directory/test lib name is conflicting with the module name. jtreg fails immediately. The updates I made check that jdeps identifies both jdk.internal.misc and sun.misc Unsafe as internal APIs. > Other than that, looks good. Thanks for the Review. > There are so many tests that have @modules java.base sun/misc but unused. It?s good that you clean that up. I agree with Alan that JDK modules depending on jdk.unsupported should get the priority to get eliminated by FC. I bumped the priority, and target the issues to 9. -Chris. From mandy.chung at oracle.com Fri Apr 8 15:48:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Apr 2016 08:48:30 -0700 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <5707CFBB.8020809@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> <13C89E01-3396-4EFE-BC35-C289E59DBEED@oracle.com> <5707CFBB.8020809@oracle.com> Message-ID: > On Apr 8, 2016, at 8:35 AM, Chris Hegarty wrote: > > > I moved the tests from a directory named 'jdk.unsupported' to > unsupported', as other tests, in test/tools/jdeps/module, use > test/tools/jdeps as a test library, and the directory/test lib > name is conflicting with the module name. jtreg fails immediately. > The updates I made check that jdeps identifies both jdk.internal.misc > and sun.misc Unsafe as internal APIs. Thanks for explaining why you did the rename. Your change now makes sense to me. I may reorganize the jdeps tests to avoid the module name you ran into in the future. All looks good. Mandy From erik.osterlund at oracle.com Fri Apr 8 16:52:57 2016 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 8 Apr 2016 18:52:57 +0200 Subject: RFR(M): 8152995: Solaris os::available_memory() doesn't do what we think it does In-Reply-To: <5707CBB7.8040606@oracle.com> References: <5705187E.3020000@oracle.com> <570539FE.3060406@oracle.com> <5707A5E5.8020409@oracle.com> <5707CBB7.8040606@oracle.com> Message-ID: <8376C593-DC4A-448C-AEAE-5CC0828B19F1@oracle.com> Hi Daniel, Thanks for the long reply. > On 8 apr. 2016, at 17:18, Daniel D. Daugherty wrote: > > Hi Erik, > > Lots of info here. Thanks! > > Just a few embedded replies below... > > >> On 4/8/16 6:36 AM, Erik ?sterlund wrote: >> Hi Daniel, >> >> Thanks for having a look at this. >> >>> On 2016-04-06 18:31, Daniel D. Daugherty wrote: >>> Erik, >>> >>> Thanks for adding Runtime to this discussion. The topic is definitely >>> of interest to Runtime folks... >>> >>> More below... >>> >>> >>>> On 2016-04-06 16:09, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152995 >>>> CR: http://cr.openjdk.java.net/~eosterlund/8152995/webrev.00/ >>>> >>>> On Solaris, the os::available_memory() function is currently >>>> calculated with sysconf(_SC_AVPHYS_PAGES). >>> >>> The Solaris man page for sysconf(_SC_AVPHYS_PAGES): >>> >>> _SC_AVPHYS_PAGES Number of physical memory pages not >>> currently in use by system >> >> Yes. After drilling down the details, it returns the amount of physical memory not used by the virtual memory system. But when you mmap without NORESERVE, no physical memory is actually paged in until memory starts to be touched. Therefore this metric corresponds to how much memory is available *for the kernel* to satisfy page faults, rather than how much memory is available *for applications* to satisfy allocations. These two interpretations are completely orthogonal: the amount of memory available for the kernel has no relation to the amount of memory available for applications, and the amount of memory available for applications has no relation to the amount of memory available in the kernel. It is safe to say that what is being asked for, is available memory to satisfy allocations, and not how much memory the kernel has at its disposal for internal use. > > These are two interesting distinctions: > > - how much memory is available *for the kernel* to satisfy page faults > - how much memory is available *for applications* to satisfy allocations > > and I'm having difficulty understanding why you are splitting the hair > this way. Yes, I'm saying there's not much difference here. > > If the kernel has a page available to satisfy a page fault, then an > application has that page available for use to satisfy an allocation. > In my mind, an allocation is a use of the page and not a reservation > of a page. Let's take a couple of steps back... > > The JVM does advanced memory allocation. By that I mean that the JVM > does not simply use malloc()/free() to allocate and deallocate memory. > The malloc()/free() world is simple and you won't run into swap space > issues. OK, you can run into swap space issues, but not the same swap > space issues we're talking about. > > So the JVM's use of advanced memory allocation means that we have to > be prepared for more complicated memory allocation failures. We also > have to be run in a system that is properly configured for applications > that use advance memory allocation. The JVM's use of a reserve, commit > and touch model means that we have to be prepared for things to go > wrong at each stage of the advanced memory allocation model. > > When the JVM reserves a page: > - if the reservation works, then all that means is that the kernel > _thinks_ that it can satisfy a _future_ use of that page > - if the reservation doesn't work, then the JVM dies (and it should) > > When the JVM commits a page: > - if the commit works, then all that means is that the kernel has > been able to allocate a backing page (swap) for the reserved page. > Note: the RAM page may not have been touched yet, all the application > did so far is change the mapping on the page that it had reserved > - On Solaris, if a backing page (swap) cannot be allocated at this > time, then the commit attempt fails and we get: > > #define EAGAIN 11 /* Resource temporarily unavailable */ > > On Solaris and Linux, if the attempt to change a reserved page to > a committed page fails, then we have to kill the JVM because we may > have lost the reservation. MacOS X is clear that the reservation is > not lost and I think Windows is the same as MacOS X. > - Note that just because we have a reserved a page, that does not mean > we'll be able to convert it to a committed page in the future. When > the kernel allowed us to reserve the page, that was its best guess > at the time of the reservation. > > When the JVM touches a page: > - At this point, the reserved RAM page is finally used and the Solaris > kernel won't count it in sysconf(_SC_AVPHYS_PAGES). > > > So how does the above relate to these two statements: > > - how much memory is available *for the kernel* to satisfy page faults > - how much memory is available *for applications* to satisfy allocations By allocations I mean malloc/sbrk/mmap without NORESERVE - which is used when committing memory. When the JVM commits memory, the kernel "reserves" backing storage of some sort (not to be confused with JVM notion of reserve, which means hogging virtual address space rather than actual memory), so that this memory may safely be touched without running out of memory. The current number does *not* correspond or have any relation to how much memory can be committed by the Java heap or malloc as it has no connection to how much more memory can be reserved in the keenel with backing storage. That is what I meant with satisfying allocations. A useful example how it works now: 1) There is 100G "available". 2) The JVM expands its heap by committing in JVM terminology (mmap without NORESERVE), let's say 50G memory which is promised backing storage 3) There is still 100G "available". And what is actually reported is that there are 100G worth of pages that can be paged into the kernel reserved memory that was committed. One would expect to instead see 50G being available, as the kernel can only reserve backing storage for another 50G. You can run my little program to verify this. > My point is that if the kernel tells you it has a page available, > then the application can presume that it has a page available to > satisfy an allocation. However, the application has to be prepared > for the case where that available page is taken by another process > and react accordingly. No it can't - that's the problem. It only means the kernel can page that much in to virtual memory, but it doesn't have that much memory to reserve backing storage for commits etc. Again, my little program demonstrates this. I hope we understand eachother better now. I will reply to the rest once we reach mutual understanding. Thanks, /Erik > >> >>> >>>> Unfortunately this does not match intended semantics. The intended >>>> semantics is to return how much memory can be allocated by mmap into >>>> physical memory. But, what _SC_AVPHYS_PAGES does is to return how many >>>> physical pages are available to be used by virtual memory as backing >>>> storage on-demand once it is touched, without any connection >>>> whatsoever to virtual memory. >>> >>> This part has me curious: >>> >>> > The intended semantics is to return how much memory can be allocated >>> > by mmap into physical memory. >>> >>> since I don't understand where you found the "intended semantics". >> >> Unfortunately I can't tell you this in the open list. > > Please add a confidential note to the bug report. :-) > > >> >>> Only one of the platforms has any comments about available_memory: >>> >>> src/os/bsd/vm/os_bsd.cpp: >>> >>> // available here means free >>> julong os::Bsd::available_memory() { >>> >>> the rest just don't say... >>> >>> Personally, I've always interpreted available_memory() to mean >>> available physical pages, as in pages that are not in use now. >>> This matches the definition of _SC_AVPHYS_PAGES above... >> >> So your version of available memory depends on how much memory is "in use". In use by who? As you can see, this also leaves room for interpretations - use by the kernel to satisfy page faults or use by applications to satisfy allocations. You just flipped it. >> >> And yes, interpretations have indeed been personal and not very well defined, which is obvious from the code. Let me summarize the current situation: >> >> Windows: Returns the amount of physical memory (RAM) that is available and can be used to satisfy allocations. >> >> Linux: Returns the amount of physical memory in the freelist that can be used to satisfy allocations. But there is in fact a lot more memory available. The freelist can be seen as memory wasted by the OS. It tries to use physical memory for things like file caches to boost performance, but that memory is in fact available if anyone starts allocating. So it will return less memory than is in fact available, contrary to the name of the function. This is also misleading and arguably wrong. >> >> BSD: Seems to also return the amount of free rather than available memory, to satisfy allocations, contrary to the name of the function. >> >> Solaris: Returns the amount of physical memory not paged in, to satisfy page faults, invariantly of the amount of memory available to satisfy allocations. > > I'm not quite sure why you are describing Solaris this way. Based on > the man page 1-liner: > > _SC_AVPHYS_PAGES Number of physical memory pages not > currently in use by system > > Solaris sounds the same as Windows above. > > >> >> In summary: >> *All OS implementations seem to consistently disregard swap page and not consider it available memory. >> * The meaning is mixed between available memory to satisfy application allocations, available memory for the kernel to use to satisfy page faults, and immediately free memory (rather than available memory) to satisfy allocations. >> >> I think that due to the lack of a clear definition, people have used any preferred interpretation. > > The fact that the different platforms have different implied > meanings for os::available_memory() is the real bug here. This > kind of inconsistency is "not a good thing" (TM). :-) > > >> >>> >>>> Even if we mmap to commit heap memory without NORESERVE, the >>>> _SC_AVPHYS_PAGES metric does not change its value - at least not until >>>> somebody actually touches the mmaped memory and it starts becoming >>>> backed by actual physical memory. So the JVM can in theory commit the >>>> whole physical memory, and _SC_AVPHYS_PAGES will still reply that all >>>> that memory is still available given that it has not been touched yet. >>> >>> Yes, I believe that is exactly how things work and I think >>> that available_memory() is returning that information >>> correctly. >> >> Solaris is AFAIK the only OS to make this interpretation, and it is arguably not useful for the users as it does not correspond to memory that applications can use to satisfy allocations. > > I'll have to wait for your next reply to understand your distinction > between an available physical page and a page that can be used to > satisfy an applications page allocation request. I'm just not seeing > it yet... > > >> But due to the lack of a definition, I can't say you are wrong, just have opinions about it and point out Solaris is the only OS with this interpretation, and that people have been very confused about it. > > Based on what you've written here, it looks to me like Solaris and > Windows have the same interpretation, but, again, I'll wait for your > reply... > > >> >>> >>>> It is likely that this is related to random swap-related test >>>> failures, where too many JVMs are created based on this metric. >>> >>> Please explain further. What do you mean by "too many JVMs are >>> created based on this metric"? >> >> Well I guess the problem is that people run many JVMs at the same time and then some JVM crashes complaining that it is out of swap memory and hence can't run any longer, while available_memory says there are multiple gigabytes of available memory. This is very confusing for users. The reason is, as I said, that the memory has not been paged in yet, and therefore there appears to be lots of memory available, but none of it can be used to satisfy allocations, leading to failures. > > Hmmm... there might be the beginnings of something here that will > help the two of us reach the same place... I'll have to come back > to this paragraph after I see your next reply... > > >> >>> >>>> Even >>>> if it is not, the os::available_memory() call is still broken in its >>>> current state and should be fixed regardless. >>> >>> I'm not yet convinced that available_memory() is broken >>> and needs to be fixed. I don't see available_memory() being >>> used in a lot of places and those uses that I do see are >>> mostly just reports of the value... >>> >>> So what am I missing about how os::available_memory() is >>> being used? >> >> The reports are very problematic though. It's better to not report anything than to report misleading, incorrect numbers. If we report a number, then that number should be correct and useful. > > Well... we haven't yet reached agreement on what correct means here. > Hopefully we will soon... > > >> I also think that whether available_memory() is broken or not has nothing to do with how often it is being used. > > My point here was two fold: > > 1) The two of us don't yet agree that it is broken. > 2) Even if it was broken, I didn't and still don't see how the broken > information is leading to an issue. The JVM is not using the value > of os::available_memory() for any allocation policy what so ever. > > >> It reports misleading numbers, and that leads to unnecessary confusion. > > Again, we don't (yet) agree that the numbers are misleading. At this > point, I'll agree that the different platforms give different answers > and that's a problem. > > >> People are very confused about Solaris swap issues. > > Yes, they are. I've written about how advanced memory allocation > algorithms require smart swap space management several times now. > > >> A contributing reason is that reported values are not what people think they are. Therefore it needs a fix. > > I agree that we need to do something about making what > os::available_memory() reports consistent and documented. > I agree that there is confusion. It will be difficult to > get agreement on what os::available_memory() _should_ > report. There will be differing opinions... :-) > > I think I've made my preference clear. I want the lowest level > answer (free pages of memory from the kernel's POV). I want the > system to trust me to know that the answer to my query can and > will change right after I receive that answer. And the system > should trust me to code my application accordingly. > > Erik, this is a wonderful thread. I'll leave it up to you as > for how much should be copied to the bug report. > > Dan > >> >> Thanks, >> /Erik >> >>> Dan >>> >>> >>> >>>> My proposed fix uses kstat to get the available memory that can be >>>> mmapped (which actually relates to virtual memory). It then uses >>>> swapctl() to find out the amount of free swap, subtracting that from >>>> the kstat value, to make sure we do not count swap memory as being >>>> available for grabbing, to mimick the current behaviour of other >>>> platforms. The code iterates over the potentially many swap resources >>>> and adds up the free swap memory. >>>> >>>> kstat gives us all memory that can be made available, including memory >>>> already used by the OS for things like file caches, and swap memory. >>>> When this value is 0, mmap will fail. That's why I calculate the >>>> amount of swap and remove that, assuming it is okay to use memory that >>>> isn't immediately available but can be made available, as long as it >>>> does not involve paging to the swap memory. >>>> >>>> Testing: >>>> * JPRT >>>> * Made my own test program that can be found in the comments of the >>>> BUG to report on memory values, so I could verify what is going on and >>>> that when the new os::available_memory() becomes 0, is indeed when >>>> paging to swap starts happening using vmstat. >>>> >>>> I need a sponsor to push this if anyone is interested. >>>> >>>> Thanks, >>>> /Erik > From calvin.cheung at oracle.com Fri Apr 8 17:29:09 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 08 Apr 2016 10:29:09 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <239BB5FD-3DC2-4E6B-8DCF-A8D722835357@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56FDFC10.2000202@oracle.com> <239BB5FD-3DC2-4E6B-8DCF-A8D722835357@oracle.com> Message-ID: <5707EA65.5070001@oracle.com> On 4/7/16, 7:54 PM, Jiangli Zhou wrote: > Hi Calvin, > > Sorry for the delay. Thank you for updating the changes. The update > looks good. Thanks! > > The following comment and code in sharedRuntime.cpp are a little > confusing. Could you please clarify that? > 2563 // handle the case when compiler is disabled during dump time > 2564 if (!DumpSharedSpaces&& CodeCacheExtensions::skip_compiler_support()) { I will update the comment to the following: - // handle the case when compiler is disabled during dump time + // during dump time, always generate adapters, even if the + // compiler has been turned off. Calvin > Thanks, > Jiangli >> On Mar 31, 2016, at 9:41 PM, Calvin Cheung > > wrote: >> >> Hi Jiangli, >> >> I've updated the fix which should address all your comments. >> webrev: >> http://cr.openjdk.java.net/~ccheung/8145221/webrev.02/ >> changes between v.02 and v.01: >> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/ >> >> The trampoline code buffer is now put into the 'md' region which is >> made executable. >> I've file the following RFE to have a separate region for the code >> buffer: >> JDK-8153241: Add a read-write-executable shared region for runtime >> generated code >> >> thanks, >> Calvin >> >> On 3/17/16, 9:37 PM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>> The changes look good overall. Following are my comments and questions. >>> >>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>> Please place the new CDS-only code under #if INCLUDE_CDS. >>> >>> It would be a good idea to assert the address (current pc) is >>> within the generated trampoline entry buffer. >>> >>> - src/share/vm/interpreter/abstractInterpreter.cpp >>> It?s not necessary to put '#include for >>> memory/metaspaceShared.hpp' under #if INCLUDE_CDS. >>> >>> - src/share/vm/memory/metaspaceShared.cpp >>> I see you changed ?read_only? to false for ?mc? region. Is it >>> possible to place the trampoline code buffer in the ?md? region, so >>> the ?mc? region does not need to be writable? It?s good to keep >>> the ?mc? as read only so it would be easier to detect >>> any ?accidental? writes to the region due to future changes. >>> The ?md? can be made executable. >>> >>> - src/share/vm/oops/method.cpp >>> Method::unlink_method() is only called >>> from Method::remove_unshareable_info(), which happens at dump time >>> only. Why is ?if (!DumpSharedSpaces)? check needed in >>> Method::unlink_method()? >>> >>> - src/share/vm/oops/method.hpp >>> In set_interpreter_entry(), when _i2i_entry and >>> _from_interpreted_entry are not the same as ?entry? for shared method? >>> >>> - src/share/vm/runtime/sharedRuntime.cpp >>> Please add a comment for the change at line 2537 >>> 2537 if (!DumpSharedSpaces&& CodeCacheExtensions::skip_compiler_support()) { >>> - src/share/vm/oops/constMethod.hpp >>> >>> ConstMethod does not seem to be the right place for >>> ?_adapter_trampoline? since it?s set at runtime. >>> >>> Do you have estimate about the size increase with the generated >>> trampolines for the shared methods? >>> >>> Thanks, >>> Jiangli >>> >>>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung >>>> > wrote: >>>> >>>> Dean, Ioi, >>>> >>>> Thanks for the review and discussions. >>>> >>>> Here's an updated webrev: >>>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>>> >>>> >>>> Changes in this webrev: >>>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). >>>> Return if it is in the middle of a trampoline call. >>>> - moved the guarantee from metaspaceShared_sparc.cpp to the common >>>> metaspaceShared.cpp; >>>> - changed the MIN_SHARED_MISC_DATA_SIZE and >>>> MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>>> >>>> The last 2 changes are required due to the test failure with the >>>> hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>> test. >>>> >>>> Testing: >>>> JPRT with testset hotspot >>>> jtreg tests under hotspot/runtime on all platforms >>>> >>>> thanks, >>>> Calvin >>>> >>>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>>> >>>> >>>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>>> >>>>> >>>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>>> Hi Ioi, comments inlined below. >>>>>> >>>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>>> Hi Dean, >>>>>>> >>>>>>> Thanks for raising this issue. >>>>>>> >>>>>>> My first impression is this probably shouldn't matter (or >>>>>>> somehow we can get away with this). >>>>>>> >>>>>>> Today, the CDS archive already contains executable code in the >>>>>>> "misc code" section. On Linux/x64, this is typically in the >>>>>>> address range 0x802400000-0x802409000. The code is used to >>>>>>> dynamically patch the C++ vtables of Metadata types that are >>>>>>> stored in the CDS archive. So even today, there's a chance that >>>>>>> the suspended PC lands in this section. >>>>>>> >>>>>> >>>>>> OK, so you're saying that the trampolines don't make things any >>>>>> worse :-) >>>>> >>>>> Well, theoretically the i2i and c2i entries would be executed more >>>>> frequently than the vtable patching code, so if there was a >>>>> problem, it could be aggravated. >>>>>> >>>>>>> The code is generated inside >>>>>>> MetaspaceShared::generate_vtable_methods and looks like this >>>>>>> when you run with -Xshare:on: >>>>>>> >>>>>>> (gdb) x/5i 0x802400000 >>>>>>> 0x802400000: mov $0x0,%eax >>>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>>> 0x80240000a: mov $0x1,%eax >>>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>>> 0x802400014: mov $0x2,%eax >>>>>>> .... >>>>>>> (gdb) x/16i 0x8024084d0 >>>>>>> 0x8024084d0: push %rsi >>>>>>> 0x8024084d1: push %rdi >>>>>>> 0x8024084d2: mov %rax,%rdi >>>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>>> 0x8024084e7: add %rdi,%rsi >>>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>>> 0x8024084ed: pop %rdi >>>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>>> 0x8024084f1: and $0xff,%rax >>>>>>> 0x8024084f8: shl $0x3,%rax >>>>>>> 0x8024084fc: add %rsi,%rax >>>>>>> 0x8024084ff: pop %rsi >>>>>>> 0x802408500: mov (%rax),%rax >>>>>>> 0x802408503: jmpq *%rax >>>>>>> >>>>>>> In JDK9, the profiler takes a sample by first calling into >>>>>>> JavaThread::pd_get_top_frame_for_profiling: >>>>>>> >>>>>>> (gdb) where >>>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, >>>>>>> thread=0x7ffff08ce000) >>>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame >>>>>>> (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, >>>>>>> ucontext=0x7ffec6287d00, isInJava=true) >>>>>>> #2 0x00007ffff69d70be in >>>>>>> JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, >>>>>>> fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>>> isInJava=true) >>>>>>> >>>>>>> I tried manually setting frame::_pc to 0x802400000, and it would >>>>>>> cause frame::safe_for_sender() to return false, and thus would >>>>>>> prevent the profiler from doing any stack walking. >>>>>>> >>>>>> >>>>>> Was the reason safe_for_sender() failed something that we can >>>>>> rely on 100%? I looked at safe_for_sender, and it's not obvious >>>>>> why it would fail, unless the frame pointer was invalid, and I >>>>>> think that depends on the platform and flags like >>>>>> PreserveFramePointer. How about filing a separate bug to track >>>>>> this issue? >>>>>> >>>>> >>>>> OK, I fill a new bug >>>>> https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>>> dl >>>>>> >>>>>>> Also, both the CDS vtable patching code and the i2i trampolines >>>>>>> are tail calls, so you will never find a PC in them except for >>>>>>> the top-most frame. This means the check in >>>>>>> JavaThread::pd_get_top_frame is enough. There's no need to do >>>>>>> additional checks after we have started stack walking. >>>>>>> >>>>>>> I think the chance of landing in the CDS vtable patching >>>>>>> methods, or in the trampolines, is pretty small, so that >>>>>>> shouldn't bother the sampling profiler too much. >>>>>>> >>>>>>> Anyway, as part of this bug, we should add a regression test >>>>>>> with the profiler enabled, and keep calling a method in the CDS >>>>>>> archive in a tight loop (and manually disable compilation of >>>>>>> that method using command-line options). The test should never >>>>>>> crash, and if possible, it should also check that we don't have >>>>>>> too many "unknown" samples. >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>>>> >>>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>>> We have profiling code that will suspend a thread at random >>>>>>>> points and try to walk the stack. >>>>>>>> I think frame::sender() will get confused if you happen to >>>>>>>> catch a thread in the trampoline, >>>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>>> >>>>>>>> dl >>>>>>>> >>>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>>> >>>>>>>>> This optimization reduces the size of the RW region of the CDS >>>>>>>>> archive. It also reduces the amount of pages in the RW region >>>>>>>>> that are actually written into during runtime. >>>>>>>>> >>>>>>>>> The original prototype on the x86_64 platform was done by Ioi >>>>>>>>> (ioi.lam at oracle.com). >>>>>>>>> I helped porting it to other platforms. >>>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com) who >>>>>>>>> provided the changes to the ppc platform. >>>>>>>>> >>>>>>>>> Testing: >>>>>>>>> JPRT with testset hotspot >>>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with >>>>>>>>> -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>>> built on the Zero platform >>>>>>>>> tested on the openjdk aarch64 platform >>>>>>>>> refworkload on various platform (please refer to bug report >>>>>>>>> for data) >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> Calvin >>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From jiangli.zhou at oracle.com Fri Apr 8 17:55:43 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Apr 2016 10:55:43 -0700 Subject: RFR(M): 8145221: Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive In-Reply-To: <5707EA65.5070001@oracle.com> References: <56C794E3.8050007@oracle.com> <56C7B5DF.1080306@oracle.com> <56C9115F.8090305@oracle.com> <56CB747E.7010501@oracle.com> <56CF41F5.7010206@oracle.com> <56EA426A.4010608@oracle.com> <3D43E30C-AD7D-4E38-8FDE-D8F01A1FDBE2@oracle.com> <56FDFC10.2000202@oracle.com> <239BB5FD-3DC2-4E6B-8DCF-A8D722835357@oracle.com> <5707EA65.5070001@oracle.com> Message-ID: > On Apr 8, 2016, at 10:29 AM, Calvin Cheung wrote: > > > > On 4/7/16, 7:54 PM, Jiangli Zhou wrote: >> >> Hi Calvin, >> >> Sorry for the delay. Thank you for updating the changes. The update looks good. > Thanks! >> >> The following comment and code in sharedRuntime.cpp are a little confusing. Could you please clarify that? >> 2563 // handle the case when compiler is disabled during dump time >> 2564 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { > I will update the comment to the following: > - // handle the case when compiler is disabled during dump time > + // during dump time, always generate adapters, even if the > + // compiler has been turned off. Looks good. Thanks, Jiangli > > Calvin >> Thanks, >> Jiangli >>> On Mar 31, 2016, at 9:41 PM, Calvin Cheung > wrote: >>> >>> Hi Jiangli, >>> >>> I've updated the fix which should address all your comments. >>> webrev: >>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.02/ >>> changes between v.02 and v.01: >>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01-02/ >>> >>> The trampoline code buffer is now put into the 'md' region which is made executable. >>> I've file the following RFE to have a separate region for the code buffer: >>> JDK-8153241: Add a read-write-executable shared region for runtime generated code >>> >>> thanks, >>> Calvin >>> >>> On 3/17/16, 9:37 PM, Jiangli Zhou wrote: >>>> >>>> Hi Calvin, >>>> >>>> The changes look good overall. Following are my comments and questions. >>>> >>>> - src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp >>>> - src/os_cpu/linux_aarch64/vm/thread_linux_aarch64.cpp >>>> - src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp >>>> - src/os_cpu/linux_x86/vm/thread_linux_x86.cpp >>>> - src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp >>>> - src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp >>>> - src/os_cpu/windows_x86/vm/thread_windows_x86.cpp >>>> Please place the new CDS-only code under #if INCLUDE_CDS. >>>> >>>> It would be a good idea to assert the address (current pc) is within the generated trampoline entry buffer. >>>> >>>> - src/share/vm/interpreter/abstractInterpreter.cpp >>>> It?s not necessary to put '#include for memory/metaspaceShared.hpp' under #if INCLUDE_CDS. >>>> >>>> - src/share/vm/memory/metaspaceShared.cpp >>>> I see you changed ?read_only? to false for ?mc? region. Is it possible to place the trampoline code buffer in the ?md? region, so the ?mc? region does not need to be writable? It?s good to keep the ?mc? as read only so it would be easier to detect any ?accidental? writes to the region due to future changes. The ?md? can be made executable. >>>> >>>> - src/share/vm/oops/method.cpp >>>> Method::unlink_method() is only called from Method::remove_unshareable_info(), which happens at dump time only. Why is ?if (!DumpSharedSpaces)? check needed in Method::unlink_method()? >>>> >>>> - src/share/vm/oops/method.hpp >>>> In set_interpreter_entry(), when _i2i_entry and _from_interpreted_entry are not the same as ?entry? for shared method? >>>> >>>> - src/share/vm/runtime/sharedRuntime.cpp >>>> Please add a comment for the change at line 2537 >>>> 2537 if (!DumpSharedSpaces && CodeCacheExtensions::skip_compiler_support()) { >>>> - src/share/vm/oops/constMethod.hpp >>>> >>>> ConstMethod does not seem to be the right place for ?_adapter_trampoline? since it?s set at runtime. >>>> >>>> Do you have estimate about the size increase with the generated trampolines for the shared methods? >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On Mar 16, 2016, at 10:36 PM, Calvin Cheung > wrote: >>>>> >>>>> Dean, Ioi, >>>>> >>>>> Thanks for the review and discussions. >>>>> >>>>> Here's an updated webrev: >>>>> http://cr.openjdk.java.net/~ccheung/8145221/webrev.01/ >>>>> >>>>> Changes in this webrev: >>>>> - in thread_*.cpp, added check in JavaThread::pd_get_top_frame(). Return if it is in the middle of a trampoline call. >>>>> - moved the guarantee from metaspaceShared_sparc.cpp to the common metaspaceShared.cpp; >>>>> - changed the MIN_SHARED_MISC_DATA_SIZE and MIN_SHARED_MISC_CODE_SIZE and related comment in metaspaceShared.hpp >>>>> >>>>> The last 2 changes are required due to the test failure with the hotspot/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test. >>>>> >>>>> Testing: >>>>> JPRT with testset hotspot >>>>> jtreg tests under hotspot/runtime on all platforms >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>> p.s. I corrected the bug id in the subject line from 8145521 to 8145221 >>>>> >>>>> >>>>> On 2/25/16, 10:03 AM, Ioi Lam wrote: >>>>>> >>>>>> >>>>>> On 2/22/16 12:50 PM, Dean Long wrote: >>>>>>> Hi Ioi, comments inlined below. >>>>>>> >>>>>>> On 2/20/2016 5:22 PM, Ioi Lam wrote: >>>>>>>> Hi Dean, >>>>>>>> >>>>>>>> Thanks for raising this issue. >>>>>>>> >>>>>>>> My first impression is this probably shouldn't matter (or somehow we can get away with this). >>>>>>>> >>>>>>>> Today, the CDS archive already contains executable code in the "misc code" section. On Linux/x64, this is typically in the address range 0x802400000-0x802409000. The code is used to dynamically patch the C++ vtables of Metadata types that are stored in the CDS archive. So even today, there's a chance that the suspended PC lands in this section. >>>>>>>> >>>>>>> >>>>>>> OK, so you're saying that the trampolines don't make things any worse :-) >>>>>> >>>>>> Well, theoretically the i2i and c2i entries would be executed more frequently than the vtable patching code, so if there was a problem, it could be aggravated. >>>>>>> >>>>>>>> The code is generated inside MetaspaceShared::generate_vtable_methods and looks like this when you run with -Xshare:on: >>>>>>>> >>>>>>>> (gdb) x/5i 0x802400000 >>>>>>>> 0x802400000: mov $0x0,%eax >>>>>>>> 0x802400005: jmpq 0x8024084d0 >>>>>>>> 0x80240000a: mov $0x1,%eax >>>>>>>> 0x80240000f: jmpq 0x8024084d0 >>>>>>>> 0x802400014: mov $0x2,%eax >>>>>>>> .... >>>>>>>> (gdb) x/16i 0x8024084d0 >>>>>>>> 0x8024084d0: push %rsi >>>>>>>> 0x8024084d1: push %rdi >>>>>>>> 0x8024084d2: mov %rax,%rdi >>>>>>>> 0x8024084d5: shr $0x8,%rdi >>>>>>>> 0x8024084d9: shl $0x3,%rdi >>>>>>>> 0x8024084dd: movabs $0x802000000,%rsi >>>>>>>> 0x8024084e7: add %rdi,%rsi >>>>>>>> 0x8024084ea: mov (%rsi),%rsi >>>>>>>> 0x8024084ed: pop %rdi >>>>>>>> 0x8024084ee: mov %rsi,(%rdi) >>>>>>>> 0x8024084f1: and $0xff,%rax >>>>>>>> 0x8024084f8: shl $0x3,%rax >>>>>>>> 0x8024084fc: add %rsi,%rax >>>>>>>> 0x8024084ff: pop %rsi >>>>>>>> 0x802408500: mov (%rax),%rax >>>>>>>> 0x802408503: jmpq *%rax >>>>>>>> >>>>>>>> In JDK9, the profiler takes a sample by first calling into JavaThread::pd_get_top_frame_for_profiling: >>>>>>>> >>>>>>>> (gdb) where >>>>>>>> #0 frame::safe_for_sender (this=0x7ffec63895f0, thread=0x7ffff08ce000) >>>>>>>> #1 0x00007ffff69d72a7 in JavaThread::pd_get_top_frame (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, isInJava=true) >>>>>>>> #2 0x00007ffff69d70be in JavaThread::pd_get_top_frame_for_profiling (this=0x7ffff08ce000, fr_addr=0x7ffec63897b0, ucontext=0x7ffec6287d00, >>>>>>>> isInJava=true) >>>>>>>> >>>>>>>> I tried manually setting frame::_pc to 0x802400000, and it would cause frame::safe_for_sender() to return false, and thus would prevent the profiler from doing any stack walking. >>>>>>>> >>>>>>> >>>>>>> Was the reason safe_for_sender() failed something that we can rely on 100%? I looked at safe_for_sender, and it's not obvious why it would fail, unless the frame pointer was invalid, and I think that depends on the platform and flags like PreserveFramePointer. How about filing a separate bug to track this issue? >>>>>>> >>>>>> >>>>>> OK, I fill a new bug https://bugs.openjdk.java.net/browse/JDK-8150663 to track this. >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>>>>> dl >>>>>>> >>>>>>>> Also, both the CDS vtable patching code and the i2i trampolines are tail calls, so you will never find a PC in them except for the top-most frame. This means the check in JavaThread::pd_get_top_frame is enough. There's no need to do additional checks after we have started stack walking. >>>>>>>> >>>>>>>> I think the chance of landing in the CDS vtable patching methods, or in the trampolines, is pretty small, so that shouldn't bother the sampling profiler too much. >>>>>>>> >>>>>>>> Anyway, as part of this bug, we should add a regression test with the profiler enabled, and keep calling a method in the CDS archive in a tight loop (and manually disable compilation of that method using command-line options). The test should never crash, and if possible, it should also check that we don't have too many "unknown" samples. >>>>>>>> >>>>>>>> Thanks >>>>>>>> - Ioi >>>>>>>> >>>>>>>> >>>>>>>> On 2/19/16 4:39 PM, Dean Long wrote: >>>>>>>>> We have profiling code that will suspend a thread at random points and try to walk the stack. >>>>>>>>> I think frame::sender() will get confused if you happen to catch a thread in the trampoline, >>>>>>>>> and frame::_pc is in metadata and not the code cache. >>>>>>>>> >>>>>>>>> dl >>>>>>>>> >>>>>>>>> On 2/19/2016 2:19 PM, Calvin Cheung wrote: >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8145221 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8145221/webrev.00/ >>>>>>>>>> >>>>>>>>>> This optimization reduces the size of the RW region of the CDS archive. It also reduces the amount of pages in the RW region that are actually written into during runtime. >>>>>>>>>> >>>>>>>>>> The original prototype on the x86_64 platform was done by Ioi (ioi.lam at oracle.com ). >>>>>>>>>> I helped porting it to other platforms. >>>>>>>>>> Special thanks to Goetz (goetz.lindenmaier at sap.com ) who provided the changes to the ppc platform. >>>>>>>>>> >>>>>>>>>> Testing: >>>>>>>>>> JPRT with testset hotspot >>>>>>>>>> maunal testing on X86_64, x86_32 and solaris/sparcv9 with -XX:+PrintAssembly -XX:+PrintInterpreter >>>>>>>>>> built on the Zero platform >>>>>>>>>> tested on the openjdk aarch64 platform >>>>>>>>>> refworkload on various platform (please refer to bug report for data) >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> Calvin >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >> From max.ockner at oracle.com Fri Apr 8 18:00:20 2016 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 08 Apr 2016 14:00:20 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5706C978.8040907@oracle.com> References: <56FAD0E3.5090508@oracle.com> <570415ED.1090808@oracle.com> <5706C978.8040907@oracle.com> Message-ID: <5707F1B4.2080902@oracle.com> If there are no further objections, I would like to commit this. Thanks, Max On 4/7/2016 4:56 PM, Max Ockner wrote: > OK I tested with jcmd and I needed to add one line above the log > configuration to make both sets of code match. > webrev: http://cr.openjdk.java.net/~mockner/8151526.03/ > > Thanks, > Max > > On 4/5/2016 3:45 PM, Coleen Phillimore wrote: >> >> This change looks good. You found the duplicated code for jcmd. >> >> To test this before you check this in to verify, start a JVM running >> some java program in an infinite loop, and do jcmd VM.info >> >> Thanks, >> Coleen >> >> On 3/29/16 3:00 PM, Max Ockner wrote: >>> Hello, >>> Please review another Unified Logging change. They are almost done, >>> and we are serious this time. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>> >>> The logging configuration is now printed in each hs_err file. The >>> output is the same as you would see from -Xlog:logging=trace and it >>> is obtained from LogConfiguration::describe(). >>> >>> Below is a sample of the hs_err contents. The Logging info is >>> printed after VM Arguments and Whitebox, and before Environment >>> Variables. >>> >>> VM Arguments: >>> java_command: Kaboom >>> java_class_path (initial): . >>> Launcher Type: SUN_STANDARD >>> >>> Logging: >>> Available log levels: off, trace, debug, info, warning, error >>> Available log decorators: time (t), uptime (u), timemillis (tm), >>> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), >>> pid (p), tid (ti), level (l), tags (tg) >>> Available log tags: alloc, age, barrier, biasedlocking, bot, census, >>> classhisto, classresolve, classinit, classload, classloaderdata, >>> classunload, classpath, compaction, cpu, cset, defaultmethods, ergo, >>> exceptions, exit, freelist, gc, heap, humongous, ihop, itables, jni, >>> liveness, logging, marking, metaspace, modules, monitorinflation, >>> os, phases, plab, promotion, preorder, protectiondomain, ref, >>> refine, region, remset, safepoint, safepointcleanup, scavenge, >>> scrub, stacktrace, start, startuptime, state, stats, stringdedup, >>> stringtable, survivor, sweep, task, thread, tlab, time, >>> verboseverification, verify, vmoperation, vtables >>> Log output configuration: >>> #0: stdout all=off uptime,level,tags, >>> #1: stderr all=warning uptime,level,tags, >>> >>> Environment Variables: >>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>> >>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>> >>> SHELL=/bin/bash >>> OS=Linux >>> >> > From coleen.phillimore at oracle.com Fri Apr 8 18:13:29 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 8 Apr 2016 14:13:29 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5707F1B4.2080902@oracle.com> References: <56FAD0E3.5090508@oracle.com> <570415ED.1090808@oracle.com> <5706C978.8040907@oracle.com> <5707F1B4.2080902@oracle.com> Message-ID: <5707F4C9.5010807@oracle.com> Looks good to me. Coleen On 4/8/16 2:00 PM, Max Ockner wrote: > If there are no further objections, I would like to commit this. > Thanks, > Max > > On 4/7/2016 4:56 PM, Max Ockner wrote: >> OK I tested with jcmd and I needed to add one line above the log >> configuration to make both sets of code match. >> webrev: http://cr.openjdk.java.net/~mockner/8151526.03/ >> >> Thanks, >> Max >> >> On 4/5/2016 3:45 PM, Coleen Phillimore wrote: >>> >>> This change looks good. You found the duplicated code for jcmd. >>> >>> To test this before you check this in to verify, start a JVM >>> running some java program in an infinite loop, and do jcmd >>> VM.info >>> >>> Thanks, >>> Coleen >>> >>> On 3/29/16 3:00 PM, Max Ockner wrote: >>>> Hello, >>>> Please review another Unified Logging change. They are almost done, >>>> and we are serious this time. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>> >>>> The logging configuration is now printed in each hs_err file. The >>>> output is the same as you would see from -Xlog:logging=trace and it >>>> is obtained from LogConfiguration::describe(). >>>> >>>> Below is a sample of the hs_err contents. The Logging info is >>>> printed after VM Arguments and Whitebox, and before Environment >>>> Variables. >>>> >>>> VM Arguments: >>>> java_command: Kaboom >>>> java_class_path (initial): . >>>> Launcher Type: SUN_STANDARD >>>> >>>> Logging: >>>> Available log levels: off, trace, debug, info, warning, error >>>> Available log decorators: time (t), uptime (u), timemillis (tm), >>>> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), >>>> pid (p), tid (ti), level (l), tags (tg) >>>> Available log tags: alloc, age, barrier, biasedlocking, bot, >>>> census, classhisto, classresolve, classinit, classload, >>>> classloaderdata, classunload, classpath, compaction, cpu, cset, >>>> defaultmethods, ergo, exceptions, exit, freelist, gc, heap, >>>> humongous, ihop, itables, jni, liveness, logging, marking, >>>> metaspace, modules, monitorinflation, os, phases, plab, promotion, >>>> preorder, protectiondomain, ref, refine, region, remset, safepoint, >>>> safepointcleanup, scavenge, scrub, stacktrace, start, startuptime, >>>> state, stats, stringdedup, stringtable, survivor, sweep, task, >>>> thread, tlab, time, verboseverification, verify, vmoperation, vtables >>>> Log output configuration: >>>> #0: stdout all=off uptime,level,tags, >>>> #1: stderr all=warning uptime,level,tags, >>>> >>>> Environment Variables: >>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>> >>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>> >>>> SHELL=/bin/bash >>>> OS=Linux >>>> >>> >> > From max.ockner at oracle.com Fri Apr 8 19:56:41 2016 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 08 Apr 2016 15:56:41 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <56FE3514.5050104@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> Message-ID: <57080CF9.6010405@oracle.com> I forgot to respond to this: On 4/1/2016 4:45 AM, Marcus Larsson wrote: > Hi, > > On 03/31/2016 08:08 PM, Max Ockner wrote: >> (Replies in line) >> >> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>> Hi Max, >>> >>> Disclaimer: not a (R)eviewer. >>> >>> Do we really need a list of all tags and all decorators? >>> >> Just going by what we currently put in the hs_err file, I think this >> may be the first "Do we really need" we've ever asked for this type >> of change. >> >> All joking aside, I think it is a good idea to direct users toward >> proper UL usage whenever we have a chance. >> >>> Also: I assume what you print is the Log state as it is at the time >>> the hs-err file is printed. If logging was enabled/changed during >>> lifetime of the VM, e.g. with jcmd, would it be possible to see >>> that? At least a warning if logging was not enabled from the start on. >>> >> Would it be possible? Yes, but I think this would require a framework >> change. It does not look like any marks are made when the >> LogConfiguration changes during runtime, and we would need to record >> that in order to know what to print when we dump into hs_err. > > Yes, this would required the framework to keep some sort of log of > configuration changes. Is there value in knowing that the log > configuration changed since startup? I think it is useful along with other information. An example case: Let's say we are logging a message whenever a lock is acquired or released. In a subsystem like this, the action which dooms the vm may not cause an immediate crash. This leaves time for logging to turn on or off in between the bad action and the crash. If you don't know when logging was active and when it was not, then the absence of a particular message does not give you much information. You may not see the message that has the answer for you because it was not logged, though the action may have occurred. However, if we don't have the framework support for this then I believe it should be added later. > >> >> Thanks, >> Max >>> Kind Regards, Thomas >>> >>> >>> >>> >>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >> > wrote: >>> >>> Hello, >>> Please review another Unified Logging change. They are almost >>> done, and we are serious this time. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>> >>> > > LogConfiguration::describe() takes the ConfigurationLock, which might > be problematic for the error handler. I suppose the error handler > could potentially deadlock if its thread already holds the lock. > Unsure how to resolve this, because skipping to take the lock means > that we might crash due to another thread changing the configuration > as we read it. > > Thanks, > Marcus > >>> >>> The logging configuration is now printed in each hs_err file. >>> The output is the same as you would see from -Xlog:logging=trace >>> and it is obtained from LogConfiguration::describe(). >>> >>> Below is a sample of the hs_err contents. The Logging info is >>> printed after VM Arguments and Whitebox, and before Environment >>> Variables. >>> >>> VM Arguments: >>> java_command: Kaboom >>> java_class_path (initial): . >>> Launcher Type: SUN_STANDARD >>> >>> Logging: >>> Available log levels: off, trace, debug, info, warning, error >>> Available log decorators: time (t), uptime (u), timemillis (tm), >>> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname >>> (hn), pid (p), tid (ti), level (l), tags (tg) >>> Available log tags: alloc, age, barrier, biasedlocking, bot, >>> census, classhisto, classresolve, classinit, classload, >>> classloaderdata, classunload, classpath, compaction, cpu, cset, >>> defaultmethods, ergo, exceptions, exit, freelist, gc, heap, >>> humongous, ihop, itables, jni, liveness, logging, marking, >>> metaspace, modules, monitorinflation, os, phases, plab, >>> promotion, preorder, protectiondomain, ref, refine, region, >>> remset, safepoint, safepointcleanup, scavenge, scrub, >>> stacktrace, start, startuptime, state, stats, stringdedup, >>> stringtable, survivor, sweep, task, thread, tlab, time, >>> verboseverification, verify, vmoperation, vtables >>> Log output configuration: >>> #0: stdout all=off uptime,level,tags, >>> #1: stderr all=warning uptime,level,tags, >>> >>> Environment Variables: >>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>> SHELL=/bin/bash >>> OS=Linux >>> >>> >> > From coleen.phillimore at oracle.com Fri Apr 8 20:28:17 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 8 Apr 2016 16:28:17 -0400 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again Message-ID: <57081461.6000201@oracle.com> Summary: removed old hack to workaround an old crash. Tested with given test case and hotspot runtime tests and jdk/test/java/lang/Throwable tests (and selected other jdk tests). open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8033735 Thanks, Coleen From harold.seigel at oracle.com Fri Apr 8 20:36:41 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 8 Apr 2016 16:36:41 -0400 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again In-Reply-To: <57081461.6000201@oracle.com> References: <57081461.6000201@oracle.com> Message-ID: <57081659.2080407@oracle.com> Hi Coleen, Does test ThrowableIntrospectionSegfault.java still pass if you remove: * @modules java.base/sun.misc If so, could you remove the @modules line? Thanks, Harold On 4/8/2016 4:28 PM, Coleen Phillimore wrote: > Summary: removed old hack to workaround an old crash. > > Tested with given test case and hotspot runtime tests and > jdk/test/java/lang/Throwable tests (and selected other jdk tests). > > open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8033735 > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Apr 8 20:43:38 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 8 Apr 2016 16:43:38 -0400 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again In-Reply-To: <57081659.2080407@oracle.com> References: <57081461.6000201@oracle.com> <57081659.2080407@oracle.com> Message-ID: <570817FA.9000605@oracle.com> On 4/8/16 4:36 PM, harold seigel wrote: > Hi Coleen, > > Does test ThrowableIntrospectionSegfault.java still pass if you remove: > > * @modules java.base/sun.misc > > If so, could you remove the @modules line? yes, it does pass. I removed the line. thanks, Coleen > > Thanks, Harold > > On 4/8/2016 4:28 PM, Coleen Phillimore wrote: >> Summary: removed old hack to workaround an old crash. >> >> Tested with given test case and hotspot runtime tests and >> jdk/test/java/lang/Throwable tests (and selected other jdk tests). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8033735 >> >> Thanks, >> Coleen > From harold.seigel at oracle.com Fri Apr 8 20:47:45 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 8 Apr 2016 16:47:45 -0400 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again In-Reply-To: <570817FA.9000605@oracle.com> References: <57081461.6000201@oracle.com> <57081659.2080407@oracle.com> <570817FA.9000605@oracle.com> Message-ID: <570818F1.3080509@oracle.com> The change looks good. Thanks, Harold On 4/8/2016 4:43 PM, Coleen Phillimore wrote: > > > On 4/8/16 4:36 PM, harold seigel wrote: >> Hi Coleen, >> >> Does test ThrowableIntrospectionSegfault.java still pass if you remove: >> >> * @modules java.base/sun.misc >> >> If so, could you remove the @modules line? > > yes, it does pass. I removed the line. > thanks, > Coleen >> >> Thanks, Harold >> >> On 4/8/2016 4:28 PM, Coleen Phillimore wrote: >>> Summary: removed old hack to workaround an old crash. >>> >>> Tested with given test case and hotspot runtime tests and >>> jdk/test/java/lang/Throwable tests (and selected other jdk tests). >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8033735 >>> >>> Thanks, >>> Coleen >> > From coleen.phillimore at oracle.com Fri Apr 8 20:48:46 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 8 Apr 2016 16:48:46 -0400 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again In-Reply-To: <570818F1.3080509@oracle.com> References: <57081461.6000201@oracle.com> <57081659.2080407@oracle.com> <570817FA.9000605@oracle.com> <570818F1.3080509@oracle.com> Message-ID: <5708192E.6060904@oracle.com> Thanks Harold! Coleen On 4/8/16 4:47 PM, harold seigel wrote: > The change looks good. > > Thanks, Harold > > On 4/8/2016 4:43 PM, Coleen Phillimore wrote: >> >> >> On 4/8/16 4:36 PM, harold seigel wrote: >>> Hi Coleen, >>> >>> Does test ThrowableIntrospectionSegfault.java still pass if you remove: >>> >>> * @modules java.base/sun.misc >>> >>> If so, could you remove the @modules line? >> >> yes, it does pass. I removed the line. >> thanks, >> Coleen >>> >>> Thanks, Harold >>> >>> On 4/8/2016 4:28 PM, Coleen Phillimore wrote: >>>> Summary: removed old hack to workaround an old crash. >>>> >>>> Tested with given test case and hotspot runtime tests and >>>> jdk/test/java/lang/Throwable tests (and selected other jdk tests). >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8033735 >>>> >>>> Thanks, >>>> Coleen >>> >> > From christian.thalinger at oracle.com Fri Apr 8 21:07:13 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 8 Apr 2016 11:07:13 -1000 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again In-Reply-To: <57081461.6000201@oracle.com> References: <57081461.6000201@oracle.com> Message-ID: <78901294-30A8-4A0A-ABA6-8E43ACB58ACC@oracle.com> Looks good. Thanks for taking care of this. > On Apr 8, 2016, at 10:28 AM, Coleen Phillimore wrote: > > Summary: removed old hack to workaround an old crash. > > Tested with given test case and hotspot runtime tests and jdk/test/java/lang/Throwable tests (and selected other jdk tests). > > open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8033735 > > Thanks, > Coleen From mandy.chung at oracle.com Fri Apr 8 21:12:30 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 8 Apr 2016 14:12:30 -0700 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again In-Reply-To: <57081461.6000201@oracle.com> References: <57081461.6000201@oracle.com> Message-ID: > On Apr 8, 2016, at 1:28 PM, Coleen Phillimore wrote: > > Summary: removed old hack to workaround an old crash. > > Tested with given test case and hotspot runtime tests and jdk/test/java/lang/Throwable tests (and selected other jdk tests). > > open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8033735 It looks fine except the test with an unused @modules. Removing this old hack is good. I saw Harold already comment on that. Mandy From mikael.vidstedt at oracle.com Fri Apr 8 22:27:33 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 8 Apr 2016 15:27:33 -0700 Subject: RFR(S): 8153890: Handle unsafe access error as an asynchronous exception Message-ID: <57083055.9070802@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8153890 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8153890/webrev.01/hotspot/webrev/ * Note: this is patch 1 in a set of 3 all aiming to clean up and unify the unsafe memory getters/setters, along with the handling of unsafe access errors. The other two issues are: https://bugs.openjdk.java.net/browse/JDK-8153892 - Handle unsafe access error directly in signal handler instead of going through a stub https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe getters/setters to use double-register variants * Summary (copied from the bug description) In certain cases, such as accessing a region of a memory mapped file which has been truncated on unix-style operating systems, a SIGBUS signal will be raised and the VM will process it in the signal handler. Currently, as part of the handling a flag is set on the thread indicating that an error has occurred: _special_runtime_exit_condition = _async_unsafe_access_error; Eventually the VM will check the flag and throw an InternalError. However, the flag is not always checked promptly, which means that the time between the error and the time when the InternalError is thrown can be very long. In parallel with this, there is functionality in the VM to set pending asynchronous exceptions on threads. These asynchronous exceptions are checked/thrown more often. Instead of having two mechanisms for handling these types of asynchronous events the unsafe access errors should be converted to use the normal asynchronous exception mechanism. One of the reasons why this isn't already the case is that when the SIGBUS signal is raised, the thread may not be in a place where it can allocate an exception - there may not be a safepoint on the instruction performing the memory access. The solution to this is to preallocate the InternalError exception at VM start up, and have the handler code simply use that exception instead. The only downside of this is that the exception will not have a stack trace. The flip side of that is that because of the unpredictability in when the async unsafe access error is actually thrown today it is likely that the stack trace in the exception doesn't actually reflect the place where the error actually occurred anyway. * Testing In addition to the JPRT smoke tests a new test has been developed for testing unsafe access errors, in particular accessing data in the truncated portion of a memory mapped file using the Unsafe primitives. The test can be found here: http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java The plan is to push it together with the final patch (JDK-8150921). Note though that the test fails unless the other patches mentioned above are also applied. I am also looking for to run additional testing on this before pushing, but wanted to get some early feedback. Cheers, Mikael From mikael.vidstedt at oracle.com Fri Apr 8 22:33:33 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 8 Apr 2016 15:33:33 -0700 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub Message-ID: <570831BD.7080005@oracle.com> Please review: Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ * Note: this is patch 2 in a set of 3 all aiming to clean up and unify the unsafe memory getters/setters, along with the handling of unsafe access errors. The other two issues are: https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe access error as an asynchronous exception https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe getters/setters to use double-register variants * Summary (copied from the bug description) In certain cases, such as accessing a region of a memory mapped file which has been truncated on unix-style operating systems, a SIGBUS signal will be raised and the VM will process it in the signal handler. How the signal is processed differs depending on the operating system and/or CPU architecture, with two major alternatives: * "stubless" Do the necessary thread state updates directly in the signal handler, and modify the context so that the signal handler returns to the place where the execution should continue * Using a stub Update the context so that when the signal handler returns the thread will continue execution in a generated stub, which in turn will call some native code in the VM to update the thread state and figure out where execution should continue. The stub will then jump to that new place. It should be noted that the work of updating the thread state is very small - it's setting a flag or two in the thread structure, and figures out where the next instruction starts. It should also be noted that the generated stubs today are broken, because they do not preserve all the live registers over the call into the VM. There are two ways to address this: * Preserve all the necessary registers This would mean implementing, in macro assembly, the necessary logic for preserving all the live registers, including, but not limited to, floating point registers, flag registers, etc. It quickly becomes obvious that this platform specific and error prone. * Leverage the fact that the operating system already does this as part of the signal handling Do the necessary work in the signal handler instead, removing the need for the stub alltogether As mentioned, on some platforms the latter model is already in use. It is dramatically easier and all platforms should be updated to do it the same way. * Testing Just as mentioned in the RFR for JDK-8153890, a new test was developed to test this code path: http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java In fact, it was when running this test I found the register preservation issue. JPRT also passes. Much like JDK-8153890 I wanted to get some feedback on this before running additional tests. Cheers, Mikael From coleen.phillimore at oracle.com Fri Apr 8 23:05:24 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 8 Apr 2016 19:05:24 -0400 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again In-Reply-To: References: <57081461.6000201@oracle.com> Message-ID: <57083934.5060105@oracle.com> Thank you, Mandy! Coleen On 4/8/16 5:12 PM, Mandy Chung wrote: >> On Apr 8, 2016, at 1:28 PM, Coleen Phillimore wrote: >> >> Summary: removed old hack to workaround an old crash. >> >> Tested with given test case and hotspot runtime tests and jdk/test/java/lang/Throwable tests (and selected other jdk tests). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8033735 > It looks fine except the test with an unused @modules. Removing this old hack is good. > > I saw Harold already comment on that. > > Mandy > From coleen.phillimore at oracle.com Fri Apr 8 23:05:42 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 8 Apr 2016 19:05:42 -0400 Subject: RFR (s) 8033735: make Throwable.backtrace visible to Class.getDeclaredField again In-Reply-To: <78901294-30A8-4A0A-ABA6-8E43ACB58ACC@oracle.com> References: <57081461.6000201@oracle.com> <78901294-30A8-4A0A-ABA6-8E43ACB58ACC@oracle.com> Message-ID: <57083946.3090807@oracle.com> Thank you, Chris, Coleen On 4/8/16 5:07 PM, Christian Thalinger wrote: > Looks good. Thanks for taking care of this. > >> On Apr 8, 2016, at 10:28 AM, Coleen Phillimore wrote: >> >> Summary: removed old hack to workaround an old crash. >> >> Tested with given test case and hotspot runtime tests and jdk/test/java/lang/Throwable tests (and selected other jdk tests). >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8033735.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8033735 >> >> Thanks, >> Coleen From dean.long at oracle.com Sat Apr 9 00:20:13 2016 From: dean.long at oracle.com (Dean Long) Date: Fri, 8 Apr 2016 17:20:13 -0700 Subject: RFR(M): 8153076: Atomic::* on Solaris should use inline assembly instead of .il files In-Reply-To: <57079B83.5040906@oracle.com> References: <57079B83.5040906@oracle.com> Message-ID: <57084ABD.7080106@oracle.com> Hi Erik. Does this work any better? __asm__ volatile ("lock; addl $1,%0" : "+m" (*dest) : : "cc", "memory"); dl On 4/8/2016 4:52 AM, Erik ?sterlund wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153076 > Webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.00/ > > On Solaris, the Atomic class puts its assembly in a separate .il file, > then the code blobs are declared as extern "C" and called from Atomic. > More modern GCC-style inline assembly is now supported, and we should > use that instead. It works fine the way it is, but making calls just > to get an instruction that could be inlined, seems suboptimal. > > There are two important things to note: > > 1) I have removed all the 32 bit code from solaris Atomic, and weird > combinations with GCC and compiler1. JDK9 is only supported on 64 bit > SPARC and x86, building using Solaris Studio. Since it is using > GCC-style inline assembly, the code should work with GCC too, but I > have not tested that as it is not a supported way of building OpenJDK. > I personally do not think we should spend too much time on supporting > unsupported code. > > 2) There appears to be a bug in Solaris Studio for emitting memory > accesses on x86. > > The following code: > > inline void Atomic::inc (volatile jint* dest) { > __asm__ volatile ("lock; addl $1,(%0)" : > : "r" (dest) : "cc", "memory"); > } > > generated the following in HandleMark::initialize(Thread* thread) on > Solaris, x64, using SS12.4: > > lock addl $1, (%eax) > > Note the %eax instead of %rax. It is wrong and caused SIGSEGV as the > address was truncated, and libraries are not put within the first 4 GB > of VA. > > I worked around the issue by assigning the address operands to a fixed > register, rdx. Being awkward with the choice of registers is still > better than having to make calls. This will have to be fixed, once the > solaris studio bug is fixed. > > Note that for SPARC there were no issues like this and the generated > code is fine. > > Testing: JPRT > > I need a sponsor to push this. > > Thanks, > /Erik From chris.hegarty at oracle.com Sat Apr 9 22:19:37 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 9 Apr 2016 23:19:37 +0100 Subject: RFR [9] 8153737: Unsupported Module In-Reply-To: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> References: <34E89289-EC26-4368-8258-697EA864D439@oracle.com> Message-ID: This change has been pushed to jdk9/dev. The hotspot gatekeeper will bring it down into the hotspot forests. -Chris. > On 7 Apr 2016, at 18:14, Chris Hegarty wrote: > > Enough technical debt has been paid down that we can now create the new > JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported. > This module will initially contain, and export, the sun.misc package, > and will eventually export the sun.reflect package too ( once it has > been sanitized ). The jdk.unsupported module will be present in full JRE > and JDK images. > > http://cr.openjdk.java.net/~chegar/8153737/ > https://bugs.openjdk.java.net/browse/JDK-8153737 > > Summary of the changes: > > - Restructure, what remains of, the sources in sun/misc to reflect the > new modular layout. There are still a few non-Critical APIs in sun.misc > that will be addressed later. > > - Add dependencies from several JDK modules to jdk.unsupported. All > dependencies have issues tracking them, and should be removed in 9. > > - The test library in the top-level repo provides a convenience to > tests to retrieve Unsafe. This has been updated to the "real" internal > Unsafe, so there are many many tests that require to be updated, mostly > the @modules tags. ( The Unsafe dependency in the library should > probably be revisited at some point, as it requires many tests, not > wishing to use Unsafe, to require an explicit dependency on it ) > > Note: with recent work from Mikael [2], sun.misc.Unsafe is now just a > delegate for the "real" internal Unsafe, so it is time to move the > tests to use it directly. > > - Cleanup any tests unnecessarily/incorrectly declaring a dependency > on sun.misc ( this could have been unnecessarily added, been refactored > out at one point, or the library upon which the tests depends refactored, > that the dependency is no longer required ). I'm sure further cleanup > could be done, but this is sufficient for now. > > - A small number of test in hotspot/test/compiler/unsafe, which are > generated, have been updated, along with the generation script, to > depend on jdk.unsupported/sun.misc ( they explicitly test the sun.misc > version ) > > All 'core', 'pit', and 'hotspot' testsets have been successfully run on > Mac, Linux, Windows, and Solaris. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8132928 > [2] https://bugs.openjdk.java.net/browse/JDK-8149159 From david.holmes at oracle.com Mon Apr 11 00:50:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Apr 2016 10:50:40 +1000 Subject: RFR(S): 8153890: Handle unsafe access error as an asynchronous exception In-Reply-To: <57083055.9070802@oracle.com> References: <57083055.9070802@oracle.com> Message-ID: <570AF4E0.9010300@oracle.com> Hi Mikael, On 9/04/2016 8:27 AM, Mikael Vidstedt wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153890 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8153890/webrev.01/hotspot/webrev/ I'm not at all sure this is going in the right direction and I certainly need some time to look at it in detail. I'm unclear what the timeliness issue actually is, as converting errors to exceptions only makes sense when entering/returning-to Java code. My initial reaction is to not entangle these two completely different forms of exceptional conditions. The unsafe access error is not really asynchronous at all - it is a synchronous condition! - but conversion to an exception is deferred which makes it appears as an asynchronous exception at the Java level. Thanks, David > > * Note: this is patch 1 in a set of 3 all aiming to clean up and unify > the unsafe memory getters/setters, along with the handling of unsafe > access errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153892 - Handle unsafe access > error directly in signal handler instead of going through a stub > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe > getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > In certain cases, such as accessing a region of a memory mapped file > which has been truncated on unix-style operating systems, a SIGBUS > signal will be raised and the VM will process it in the signal handler. > Currently, as part of the handling a flag is set on the thread > indicating that an error has occurred: > > _special_runtime_exit_condition = _async_unsafe_access_error; > > Eventually the VM will check the flag and throw an InternalError. > However, the flag is not always checked promptly, which means that the > time between the error and the time when the InternalError is thrown can > be very long. > > In parallel with this, there is functionality in the VM to set pending > asynchronous exceptions on threads. These asynchronous exceptions are > checked/thrown more often. > > Instead of having two mechanisms for handling these types of > asynchronous events the unsafe access errors should be converted to use > the normal asynchronous exception mechanism. > > One of the reasons why this isn't already the case is that when the > SIGBUS signal is raised, the thread may not be in a place where it can > allocate an exception - there may not be a safepoint on the instruction > performing the memory access. The solution to this is to preallocate the > InternalError exception at VM start up, and have the handler code simply > use that exception instead. The only downside of this is that the > exception will not have a stack trace. The flip side of that is that > because of the unpredictability in when the async unsafe access error is > actually thrown today it is likely that the stack trace in the exception > doesn't actually reflect the place where the error actually occurred > anyway. > > * Testing > > In addition to the JPRT smoke tests a new test has been developed for > testing unsafe access errors, in particular accessing data in the > truncated portion of a memory mapped file using the Unsafe primitives. > The test can be found here: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > The plan is to push it together with the final patch (JDK-8150921). Note > though that the test fails unless the other patches mentioned above are > also applied. > > I am also looking for to run additional testing on this before pushing, > but wanted to get some early feedback. > > Cheers, > Mikael > From david.holmes at oracle.com Mon Apr 11 00:57:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Apr 2016 10:57:47 +1000 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <570831BD.7080005@oracle.com> References: <570831BD.7080005@oracle.com> Message-ID: <570AF68B.9090707@oracle.com> Hi Mikael, I think we need to be able to answer the question as to why the stubbed and stubless forms of this code exist to ensure that converting all platforms to the same form is appropriate. I'm still going through this but my initial reaction is to wonder why we don't use the same form of handle_unsafe_access on all platforms and always pass in npc? (That seems to be the only difference in code that otherwise seems platform independent.) Thanks, David On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ > > > * Note: this is patch 2 in a set of 3 all aiming to clean up and unify > the unsafe memory getters/setters, along with the handling of unsafe > access errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe access > error as an asynchronous exception > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe > getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > > In certain cases, such as accessing a region of a memory mapped file > which has been truncated on unix-style operating systems, a SIGBUS > signal will be raised and the VM will process it in the signal handler. > > How the signal is processed differs depending on the operating system > and/or CPU architecture, with two major alternatives: > > * "stubless" > > Do the necessary thread state updates directly in the signal handler, > and modify the context so that the signal handler returns to the place > where the execution should continue > > * Using a stub > > Update the context so that when the signal handler returns the thread > will continue execution in a generated stub, which in turn will call > some native code in the VM to update the thread state and figure out > where execution should continue. The stub will then jump to that new place. > > > It should be noted that the work of updating the thread state is very > small - it's setting a flag or two in the thread structure, and figures > out where the next instruction starts. It should also be noted that the > generated stubs today are broken, because they do not preserve all the > live registers over the call into the VM. There are two ways to address > this: > > * Preserve all the necessary registers > > This would mean implementing, in macro assembly, the necessary logic for > preserving all the live registers, including, but not limited to, > floating point registers, flag registers, etc. It quickly becomes > obvious that this platform specific and error prone. > > * Leverage the fact that the operating system already does this as part > of the signal handling > > Do the necessary work in the signal handler instead, removing the need > for the stub alltogether > > As mentioned, on some platforms the latter model is already in use. It > is dramatically easier and all platforms should be updated to do it the > same way. > > > * Testing > > Just as mentioned in the RFR for JDK-8153890, a new test was developed > to test this code path: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > In fact, it was when running this test I found the register preservation > issue. JPRT also passes. Much like JDK-8153890 I wanted to get some > feedback on this before running additional tests. > > > Cheers, > Mikael > From thomas.stuefe at gmail.com Mon Apr 11 07:00:25 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Apr 2016 09:00:25 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <57080CF9.6010405@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> Message-ID: Hi Max, On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner wrote: > I forgot to respond to this: > On 4/1/2016 4:45 AM, Marcus Larsson wrote: > > Hi, > > On 03/31/2016 08:08 PM, Max Ockner wrote: > > (Replies in line) > > On 3/30/2016 9:31 AM, Thomas St?fe wrote: > > Hi Max, > > Disclaimer: not a (R)eviewer. > > Do we really need a list of all tags and all decorators? > > Just going by what we currently put in the hs_err file, I think this may > be the first "Do we really need" we've ever asked for this type of change. > > All joking aside, I think it is a good idea to direct users toward proper > UL usage whenever we have a chance. > > Also: I assume what you print is the Log state as it is at the time the > hs-err file is printed. If logging was enabled/changed during lifetime of > the VM, e.g. with jcmd, would it be possible to see that? At least a > warning if logging was not enabled from the start on. > > Would it be possible? Yes, but I think this would require a framework > change. It does not look like any marks are made when the LogConfiguration > changes during runtime, and we would need to record that in order to know > what to print when we dump into hs_err. > > > Yes, this would required the framework to keep some sort of log of > configuration changes. Is there value in knowing that the log configuration > changed since startup? > > > I think it is useful along with other information. An example case: > > Let's say we are logging a message whenever a lock is acquired or > released. In a subsystem like this, the action which dooms the vm may not > cause an immediate crash. This leaves time for logging to turn on or off in > between the bad action and the crash. If you don't know when logging was > active and when it was not, then the absence of a particular message does > not give you much information. You may not see the message that has the > answer for you because it was not logged, though the action may have > occurred. > > However, if we don't have the framework support for this then I believe it > should be added later. > > > This is a good example. A small easy solution, as I mentioned before, could be just to distinguish between "logging parameters stable since startup" and "logging parameters changed at some time". That way you would at least know whether to trust the logging output. But you are right, this can be added later. Kind Regards, Thomas > > > > Thanks, > Max > > Kind Regards, Thomas > > > > > On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner wrote: > >> Hello, >> Please review another Unified Logging change. They are almost done, and >> we are serious this time. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >> > > LogConfiguration::describe() takes the ConfigurationLock, which might be > problematic for the error handler. I suppose the error handler could > potentially deadlock if its thread already holds the lock. Unsure how to > resolve this, because skipping to take the lock means that we might crash > due to another thread changing the configuration as we read it. > > Thanks, > Marcus > > >> The logging configuration is now printed in each hs_err file. The output >> is the same as you would see from -Xlog:logging=trace and it is obtained >> from LogConfiguration::describe(). >> >> Below is a sample of the hs_err contents. The Logging info is printed >> after VM Arguments and Whitebox, and before Environment Variables. >> >> VM Arguments: >> java_command: Kaboom >> java_class_path (initial): . >> Launcher Type: SUN_STANDARD >> >> Logging: >> Available log levels: off, trace, debug, info, warning, error >> Available log decorators: time (t), uptime (u), timemillis (tm), >> uptimemillis (um), timenanos (tn), uptimenanos (un), hostname (hn), pid >> (p), tid (ti), level (l), tags (tg) >> Available log tags: alloc, age, barrier, biasedlocking, bot, census, >> classhisto, classresolve, classinit, classload, classloaderdata, >> classunload, classpath, compaction, cpu, cset, defaultmethods, ergo, >> exceptions, exit, freelist, gc, heap, humongous, ihop, itables, jni, >> liveness, logging, marking, metaspace, modules, monitorinflation, os, >> phases, plab, promotion, preorder, protectiondomain, ref, refine, region, >> remset, safepoint, safepointcleanup, scavenge, scrub, stacktrace, start, >> startuptime, state, stats, stringdedup, stringtable, survivor, sweep, task, >> thread, tlab, time, verboseverification, verify, vmoperation, vtables >> Log output configuration: >> #0: stdout all=off uptime,level,tags, >> #1: stderr all=warning uptime,level,tags, >> >> Environment Variables: >> >> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >> >> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >> SHELL=/bin/bash >> OS=Linux >> >> > > > > From marcus.larsson at oracle.com Mon Apr 11 08:19:53 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 11 Apr 2016 10:19:53 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> Message-ID: <570B5E29.6040709@oracle.com> On 04/11/2016 09:00 AM, Thomas St?fe wrote: > Hi Max, > > On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner > wrote: > > I forgot to respond to this: > On 4/1/2016 4:45 AM, Marcus Larsson wrote: >> Hi, >> >> On 03/31/2016 08:08 PM, Max Ockner wrote: >>> (Replies in line) >>> >>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>> Hi Max, >>>> >>>> Disclaimer: not a (R)eviewer. >>>> >>>> Do we really need a list of all tags and all decorators? >>>> >>> Just going by what we currently put in the hs_err file, I think >>> this may be the first "Do we really need" we've ever asked for >>> this type of change. >>> >>> All joking aside, I think it is a good idea to direct users >>> toward proper UL usage whenever we have a chance. >>> >>>> Also: I assume what you print is the Log state as it is at the >>>> time the hs-err file is printed. If logging was enabled/changed >>>> during lifetime of the VM, e.g. with jcmd, would it be possible >>>> to see that? At least a warning if logging was not enabled from >>>> the start on. >>>> >>> Would it be possible? Yes, but I think this would require a >>> framework change. It does not look like any marks are made when >>> the LogConfiguration changes during runtime, and we would need >>> to record that in order to know what to print when we dump into >>> hs_err. >> >> Yes, this would required the framework to keep some sort of log >> of configuration changes. Is there value in knowing that the log >> configuration changed since startup? > > I think it is useful along with other information. An example case: > > Let's say we are logging a message whenever a lock is acquired or > released. In a subsystem like this, the action which dooms the vm > may not cause an immediate crash. This leaves time for logging to > turn on or off in between the bad action and the crash. If you > don't know when logging was active and when it was not, then the > absence of a particular message does not give you much > information. You may not see the message that has the answer for > you because it was not logged, though the action may have occurred. > > However, if we don't have the framework support for this then I > believe it should be added later. > > > > This is a good example. A small easy solution, as I mentioned before, > could be just to distinguish between "logging parameters stable since > startup" and "logging parameters changed at some time". That way you > would at least know whether to trust the logging output. > > But you are right, this can be added later. I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for this. Max: Did you see my comments about the ConfigurationLock? It was an inline reply to your first mail. Thanks, Marcus > > Kind Regards, Thomas > > >> >>> >>> Thanks, >>> Max >>>> Kind Regards, Thomas >>>> >>>> >>>> >>>> >>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>> > wrote: >>>> >>>> Hello, >>>> Please review another Unified Logging change. They are >>>> almost done, and we are serious this time. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>> >>>> >> >> LogConfiguration::describe() takes the ConfigurationLock, which >> might be problematic for the error handler. I suppose the error >> handler could potentially deadlock if its thread already holds >> the lock. Unsure how to resolve this, because skipping to take >> the lock means that we might crash due to another thread changing >> the configuration as we read it. >> >> Thanks, >> Marcus >> >>>> >>>> The logging configuration is now printed in each hs_err >>>> file. The output is the same as you would see from >>>> -Xlog:logging=trace and it is obtained from >>>> LogConfiguration::describe(). >>>> >>>> Below is a sample of the hs_err contents. The Logging info >>>> is printed after VM Arguments and Whitebox, and before >>>> Environment Variables. >>>> >>>> VM Arguments: >>>> java_command: Kaboom >>>> java_class_path (initial): . >>>> Launcher Type: SUN_STANDARD >>>> >>>> Logging: >>>> Available log levels: off, trace, debug, info, warning, error >>>> Available log decorators: time (t), uptime (u), timemillis >>>> (tm), uptimemillis (um), timenanos (tn), uptimenanos (un), >>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>> Available log tags: alloc, age, barrier, biasedlocking, >>>> bot, census, classhisto, classresolve, classinit, >>>> classload, classloaderdata, classunload, classpath, >>>> compaction, cpu, cset, defaultmethods, ergo, exceptions, >>>> exit, freelist, gc, heap, humongous, ihop, itables, jni, >>>> liveness, logging, marking, metaspace, modules, >>>> monitorinflation, os, phases, plab, promotion, preorder, >>>> protectiondomain, ref, refine, region, remset, safepoint, >>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>> startuptime, state, stats, stringdedup, stringtable, >>>> survivor, sweep, task, thread, tlab, time, >>>> verboseverification, verify, vmoperation, vtables >>>> Log output configuration: >>>> #0: stdout all=off uptime,level,tags, >>>> #1: stderr all=warning uptime,level,tags, >>>> >>>> Environment Variables: >>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>> SHELL=/bin/bash >>>> OS=Linux >>>> >>>> >>> >> > > From paul.sandoz at oracle.com Mon Apr 11 08:42:37 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 11 Apr 2016 10:42:37 +0200 Subject: RFR(S): 8153890: Handle unsafe access error as an asynchronous exception In-Reply-To: <57083055.9070802@oracle.com> References: <57083055.9070802@oracle.com> Message-ID: <8E26D6C6-A388-49D4-AE3C-06D4C398F08F@oracle.com> Hi Mikael, I share David?s concern about the asynchrony, but it?s not possible to tell the difference at the Java level in this case? (i am not an expert in this area). The test looks good. Some suggested enhancements: 1) add the get/set*Unaligned calls; and 2) Access at misaligned addresses and at the buffer offset to those same addresses. Paul. > On 9 Apr 2016, at 00:27, Mikael Vidstedt wrote: > > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153890 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8153890/webrev.01/hotspot/webrev/ > > * Note: this is patch 1 in a set of 3 all aiming to clean up and unify the unsafe memory getters/setters, along with the handling of unsafe access errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153892 - Handle unsafe access error directly in signal handler instead of going through a stub > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > In certain cases, such as accessing a region of a memory mapped file which has been truncated on unix-style operating systems, a SIGBUS signal will be raised and the VM will process it in the signal handler. Currently, as part of the handling a flag is set on the thread indicating that an error has occurred: > > _special_runtime_exit_condition = _async_unsafe_access_error; > > Eventually the VM will check the flag and throw an InternalError. However, the flag is not always checked promptly, which means that the time between the error and the time when the InternalError is thrown can be very long. > > In parallel with this, there is functionality in the VM to set pending asynchronous exceptions on threads. These asynchronous exceptions are checked/thrown more often. > > Instead of having two mechanisms for handling these types of asynchronous events the unsafe access errors should be converted to use the normal asynchronous exception mechanism. > > One of the reasons why this isn't already the case is that when the SIGBUS signal is raised, the thread may not be in a place where it can allocate an exception - there may not be a safepoint on the instruction performing the memory access. The solution to this is to preallocate the InternalError exception at VM start up, and have the handler code simply use that exception instead. The only downside of this is that the exception will not have a stack trace. The flip side of that is that because of the unpredictability in when the async unsafe access error is actually thrown today it is likely that the stack trace in the exception doesn't actually reflect the place where the error actually occurred anyway. > > * Testing > > In addition to the JPRT smoke tests a new test has been developed for testing unsafe access errors, in particular accessing data in the truncated portion of a memory mapped file using the Unsafe primitives. The test can be found here: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > The plan is to push it together with the final patch (JDK-8150921). Note though that the test fails unless the other patches mentioned above are also applied. > > I am also looking for to run additional testing on this before pushing, but wanted to get some early feedback. > > Cheers, > Mikael > From thomas.stuefe at gmail.com Mon Apr 11 09:03:19 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Apr 2016 11:03:19 +0200 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <570831BD.7080005@oracle.com> References: <570831BD.7080005@oracle.com> Message-ID: Hi Mikael, just a question, should the new stubless functions not live someplace else instead of in stubRoutines_ ? After all, they are not stub routines anymore. Kind Regards, Thomas On Sat, Apr 9, 2016 at 12:33 AM, Mikael Vidstedt wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ > > * Note: this is patch 2 in a set of 3 all aiming to clean up and unify the > unsafe memory getters/setters, along with the handling of unsafe access > errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe access > error as an asynchronous exception > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe > getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > > In certain cases, such as accessing a region of a memory mapped file which > has been truncated on unix-style operating systems, a SIGBUS signal will be > raised and the VM will process it in the signal handler. > > How the signal is processed differs depending on the operating system > and/or CPU architecture, with two major alternatives: > > * "stubless" > > Do the necessary thread state updates directly in the signal handler, and > modify the context so that the signal handler returns to the place where > the execution should continue > > * Using a stub > > Update the context so that when the signal handler returns the thread will > continue execution in a generated stub, which in turn will call some native > code in the VM to update the thread state and figure out where execution > should continue. The stub will then jump to that new place. > > > It should be noted that the work of updating the thread state is very > small - it's setting a flag or two in the thread structure, and figures out > where the next instruction starts. It should also be noted that the > generated stubs today are broken, because they do not preserve all the live > registers over the call into the VM. There are two ways to address this: > > * Preserve all the necessary registers > > This would mean implementing, in macro assembly, the necessary logic for > preserving all the live registers, including, but not limited to, floating > point registers, flag registers, etc. It quickly becomes obvious that this > platform specific and error prone. > > * Leverage the fact that the operating system already does this as part of > the signal handling > > Do the necessary work in the signal handler instead, removing the need for > the stub alltogether > > As mentioned, on some platforms the latter model is already in use. It is > dramatically easier and all platforms should be updated to do it the same > way. > > > * Testing > > Just as mentioned in the RFR for JDK-8153890, a new test was developed to > test this code path: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > In fact, it was when running this test I found the register preservation > issue. JPRT also passes. Much like JDK-8153890 I wanted to get some > feedback on this before running additional tests. > > > Cheers, > Mikael > > From thomas.stuefe at gmail.com Mon Apr 11 09:05:46 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Apr 2016 11:05:46 +0200 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <570AF68B.9090707@oracle.com> References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> Message-ID: Hi David, On Mon, Apr 11, 2016 at 2:57 AM, David Holmes wrote: > Hi Mikael, > > I think we need to be able to answer the question as to why the stubbed > and stubless forms of this code exist to ensure that converting all > platforms to the same form is appropriate. > > I'm still going through this but my initial reaction is to wonder why we > don't use the same form of handle_unsafe_access on all platforms and always > pass in npc? (That seems to be the only difference in code that otherwise > seems platform independent.) > On Solaris we get the npc for free in the signal ucontext. On x86 it has to be calculated. But yes, this could be moved out of the handle functions and just passed in. I also saw that we apparently miss handling for ppc. No one seemed to miss it until now, but it may make sense to add handling anyway. Kind Regards, Thomas > > Thanks, > David > > > On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: > >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >> Webrev: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >> >> >> * Note: this is patch 2 in a set of 3 all aiming to clean up and unify >> the unsafe memory getters/setters, along with the handling of unsafe >> access errors. The other two issues are: >> >> https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe access >> error as an asynchronous exception >> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >> getters/setters to use double-register variants >> >> >> * Summary (copied from the bug description) >> >> >> In certain cases, such as accessing a region of a memory mapped file >> which has been truncated on unix-style operating systems, a SIGBUS >> signal will be raised and the VM will process it in the signal handler. >> >> How the signal is processed differs depending on the operating system >> and/or CPU architecture, with two major alternatives: >> >> * "stubless" >> >> Do the necessary thread state updates directly in the signal handler, >> and modify the context so that the signal handler returns to the place >> where the execution should continue >> >> * Using a stub >> >> Update the context so that when the signal handler returns the thread >> will continue execution in a generated stub, which in turn will call >> some native code in the VM to update the thread state and figure out >> where execution should continue. The stub will then jump to that new >> place. >> >> >> It should be noted that the work of updating the thread state is very >> small - it's setting a flag or two in the thread structure, and figures >> out where the next instruction starts. It should also be noted that the >> generated stubs today are broken, because they do not preserve all the >> live registers over the call into the VM. There are two ways to address >> this: >> >> * Preserve all the necessary registers >> >> This would mean implementing, in macro assembly, the necessary logic for >> preserving all the live registers, including, but not limited to, >> floating point registers, flag registers, etc. It quickly becomes >> obvious that this platform specific and error prone. >> >> * Leverage the fact that the operating system already does this as part >> of the signal handling >> >> Do the necessary work in the signal handler instead, removing the need >> for the stub alltogether >> >> As mentioned, on some platforms the latter model is already in use. It >> is dramatically easier and all platforms should be updated to do it the >> same way. >> >> >> * Testing >> >> Just as mentioned in the RFR for JDK-8153890, a new test was developed >> to test this code path: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >> >> In fact, it was when running this test I found the register preservation >> issue. JPRT also passes. Much like JDK-8153890 I wanted to get some >> feedback on this before running additional tests. >> >> >> Cheers, >> Mikael >> >> From thomas.stuefe at gmail.com Mon Apr 11 09:15:09 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 11 Apr 2016 11:15:09 +0200 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> Message-ID: On Mon, Apr 11, 2016 at 11:05 AM, Thomas St?fe wrote: > Hi David, > > On Mon, Apr 11, 2016 at 2:57 AM, David Holmes > wrote: > >> Hi Mikael, >> >> I think we need to be able to answer the question as to why the stubbed >> and stubless forms of this code exist to ensure that converting all >> platforms to the same form is appropriate. >> >> I'm still going through this but my initial reaction is to wonder why we >> don't use the same form of handle_unsafe_access on all platforms and always >> pass in npc? (That seems to be the only difference in code that otherwise >> seems platform independent.) >> > > On Solaris we get the npc for free in the signal ucontext. On x86 it has > to be calculated. But yes, this could be moved out of the handle functions > and just passed in. > > I also saw that we apparently miss handling for ppc. No one seemed to miss > it until now, but it may make sense to add handling anyway. > > Oh, we do not miss it. Volker just showed me that it is done directly in the signal handlers for AIX and Linux ppc. > Kind Regards, Thomas > > >> >> Thanks, >> David >> >> >> On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: >> >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >>> >>> >>> * Note: this is patch 2 in a set of 3 all aiming to clean up and unify >>> the unsafe memory getters/setters, along with the handling of unsafe >>> access errors. The other two issues are: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe access >>> error as an asynchronous exception >>> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >>> getters/setters to use double-register variants >>> >>> >>> * Summary (copied from the bug description) >>> >>> >>> In certain cases, such as accessing a region of a memory mapped file >>> which has been truncated on unix-style operating systems, a SIGBUS >>> signal will be raised and the VM will process it in the signal handler. >>> >>> How the signal is processed differs depending on the operating system >>> and/or CPU architecture, with two major alternatives: >>> >>> * "stubless" >>> >>> Do the necessary thread state updates directly in the signal handler, >>> and modify the context so that the signal handler returns to the place >>> where the execution should continue >>> >>> * Using a stub >>> >>> Update the context so that when the signal handler returns the thread >>> will continue execution in a generated stub, which in turn will call >>> some native code in the VM to update the thread state and figure out >>> where execution should continue. The stub will then jump to that new >>> place. >>> >>> >>> It should be noted that the work of updating the thread state is very >>> small - it's setting a flag or two in the thread structure, and figures >>> out where the next instruction starts. It should also be noted that the >>> generated stubs today are broken, because they do not preserve all the >>> live registers over the call into the VM. There are two ways to address >>> this: >>> >>> * Preserve all the necessary registers >>> >>> This would mean implementing, in macro assembly, the necessary logic for >>> preserving all the live registers, including, but not limited to, >>> floating point registers, flag registers, etc. It quickly becomes >>> obvious that this platform specific and error prone. >>> >>> * Leverage the fact that the operating system already does this as part >>> of the signal handling >>> >>> Do the necessary work in the signal handler instead, removing the need >>> for the stub alltogether >>> >>> As mentioned, on some platforms the latter model is already in use. It >>> is dramatically easier and all platforms should be updated to do it the >>> same way. >>> >>> >>> * Testing >>> >>> Just as mentioned in the RFR for JDK-8153890, a new test was developed >>> to test this code path: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >>> >>> In fact, it was when running this test I found the register preservation >>> issue. JPRT also passes. Much like JDK-8153890 I wanted to get some >>> feedback on this before running additional tests. >>> >>> >>> Cheers, >>> Mikael >>> >>> > From erik.osterlund at oracle.com Mon Apr 11 09:19:25 2016 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 11 Apr 2016 11:19:25 +0200 Subject: RFR(M): 8153076: Atomic::* on Solaris should use inline assembly instead of .il files In-Reply-To: <57084ABD.7080106@oracle.com> References: <57079B83.5040906@oracle.com> <57084ABD.7080106@oracle.com> Message-ID: <570B6C1D.2000407@oracle.com> Hi Dean, Changing the input to a memory operand did indeed work better. Thanks for the great idea. I updated the x86 code with cleaner assembly. Updated webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.01/ Thanks, /Erik On 2016-04-09 02:20, Dean Long wrote: > Hi Erik. Does this work any better? > > __asm__ volatile ("lock; addl $1,%0" : "+m" (*dest) : : "cc", > "memory"); > > > dl > > On 4/8/2016 4:52 AM, Erik ?sterlund wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153076 >> Webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.00/ >> >> On Solaris, the Atomic class puts its assembly in a separate .il >> file, then the code blobs are declared as extern "C" and called from >> Atomic. More modern GCC-style inline assembly is now supported, and >> we should use that instead. It works fine the way it is, but making >> calls just to get an instruction that could be inlined, seems >> suboptimal. >> >> There are two important things to note: >> >> 1) I have removed all the 32 bit code from solaris Atomic, and weird >> combinations with GCC and compiler1. JDK9 is only supported on 64 bit >> SPARC and x86, building using Solaris Studio. Since it is using >> GCC-style inline assembly, the code should work with GCC too, but I >> have not tested that as it is not a supported way of building >> OpenJDK. I personally do not think we should spend too much time on >> supporting unsupported code. >> >> 2) There appears to be a bug in Solaris Studio for emitting memory >> accesses on x86. >> >> The following code: >> >> inline void Atomic::inc (volatile jint* dest) { >> __asm__ volatile ("lock; addl $1,(%0)" : >> : "r" (dest) : "cc", "memory"); >> } >> >> generated the following in HandleMark::initialize(Thread* thread) on >> Solaris, x64, using SS12.4: >> >> lock addl $1, (%eax) >> >> Note the %eax instead of %rax. It is wrong and caused SIGSEGV as the >> address was truncated, and libraries are not put within the first 4 >> GB of VA. >> >> I worked around the issue by assigning the address operands to a >> fixed register, rdx. Being awkward with the choice of registers is >> still better than having to make calls. This will have to be fixed, >> once the solaris studio bug is fixed. >> >> Note that for SPARC there were no issues like this and the generated >> code is fine. >> >> Testing: JPRT >> >> I need a sponsor to push this. >> >> Thanks, >> /Erik > From yasuenag at gmail.com Mon Apr 11 09:25:29 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 11 Apr 2016 18:25:29 +0900 Subject: [PING] RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> Message-ID: <570B6D89.2040000@gmail.com> PING: Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ Thanks, Yasumasa On 2016/03/31 8:49, Yasumasa Suenaga wrote: > Thanks Robbin, > > I'm waiting a sponsor and more reviewer :-) > > Yasumasa > > 2016/03/31 5:58 "Robbin Ehn" >: > > FYI: I'm not a Reviewer. > > /Robbin > > On 03/30/2016 10:55 PM, Robbin Ehn wrote: > > Thanks, looks good. > > /Robbin > > On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: > > Hi, > > I uploaded new webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ > > > Thanks, > > Yasumasa > > > On 2016/03/30 19:10, Robbin Ehn wrote: > > Hi, > > On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: > > Hi Robbin, > > 2016/03/30 18:22 "Robbin Ehn" > >>: > > > > Hi Yasumasa, > > > > > > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: > >> > >> Hi Robbin, > >> 2016/03/25 1:51 "Robbin Ehn" > > > >> >>>: > >> > >> > > >> > Hi Yasumasa, > >> > > >> > I'm not sure why you don't set it: > >> > > >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp > >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 > +0000 > >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 > +0100 > >> > @@ -3584,6 +3584,7 @@ > >> > JavaThread* main_thread = new JavaThread(); > >> > main_thread->set_thread_state(_thread_in_vm); > >> > main_thread->initialize_thread_current(); > >> > + main_thread->set_native_thread_name("main"); > >> > // must do this before set_active_handles > >> > main_thread->record_stack_base_and_size(); > >> > > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > >> > > >> > here instead? Am I missing something? > >> > >> Native thread name is the same to thread name in Thread class. > >> It is set in c'tor in Thread or setName(). > >> If you create new thread in Java app, native thread name will be > set at > >> startup. However, main thread is already starte in VM. > >> Thread name for "main" is set in create_initial_thread(). > >> I think that the place of setting thrrad name should be the same. > > > > > > Yes, I see your point. But then something like this is nicer, no? > > > > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 > +0200 > > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 > +0200 > > @@ -981,6 +981,7 @@ > > // Creates the initial Thread > > static oop create_initial_thread(Handle thread_group, JavaThread* > thread, > > TRAPS) { > > + static const char* initial_thread_name = "main"; > > Klass* k = > SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, > CHECK_NULL); > > instanceKlassHandle klass (THREAD, k); > > instanceHandle thread_oop = > klass->allocate_instance_handle(CHECK_NULL); > > @@ -988,8 +989,10 @@ > > java_lang_Thread::set_thread(thread_oop(), thread); > > java_lang_Thread::set_priority(thread_oop(), NormPriority); > > thread->set_threadObj(thread_oop()); > > - > > - Handle string = java_lang_String::create_from_str("main", > CHECK_NULL); > > + > > + thread->set_native_thread_name(initial_thread_name); > > + > > + Handle string = > java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); > > > > JavaValue result(T_VOID); > > JavaCalls::call_special(&result, thread_oop, > > Okay, I will upload new webrev later. > > > Thanks! > > > >> > The launcher seem to name itself 'java' and naming this thread > just > >> > 'main' is confusing to me. > >> > > >> > E.g. so main thread of the process (and thus the process) is > 'java' but > >> > first JavaThread is 'main'. > >> > >> The native main thread in the process is not JavaThread. It is > waiting > >> for ending of Java main thread with pthread_join(). > >> set_native_thread_name() is for JavaThread. So I think that we do > not > >> need to call it for native main thread. > > > > > > Not sure if we can change it anyhow, since we want java and native > name to be the same and java thread name might have some dependents. > > > > The name is visible in e.g. /proc. > > > > $ ps H -C java -o 'pid tid comm' | head -4 > > PID TID COMMAND > > 6423 6423 java > > 6423 6424 main > > 6423 6425 GC Thread#0 > > > > It would be nice with something like 'Java Main Thread'. > > I do not think so. > Native main thread might not be a Java launcher - e.g. Apache > commons-daemon, JNI application, etc. > > If you want to change native main thread name, I think that we have to > change Java launcher code. > Should I include it in new webrev? > > > No > > Thanks again! > > /Robbin > > > Thanks, > > Yasumasa > > > Thanks > > > > /Robbin > > > > > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > Thanks! > >> > > >> > /Robbin > >> > > >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: > >> > > Hi all, > >> > > > >> > > HotSpot for Linux will set thread name via > pthread_setname_np(). > >> > > However, main thread does not have it. > >> > > > >> > > All JavaThread have native name, and main thread is > JavaThread. > >> > > For consistency, main thread should have native thread name. > >> > > > >> > > I uploaded a webrev. Could you review it? > >> > > > >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ > >> > > > >> > > I cannot access JPRT. > >> > > So I need a sponsor. > >> > > > >> > > > >> > > Thanks, > >> > > > >> > > Yasumasa > >> > > > >> > From claes.redestad at oracle.com Mon Apr 11 11:57:21 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 11 Apr 2016 13:57:21 +0200 Subject: RFR(M): 8153076: Atomic::* on Solaris should use inline assembly instead of .il files In-Reply-To: <570B6C1D.2000407@oracle.com> References: <57079B83.5040906@oracle.com> <57084ABD.7080106@oracle.com> <570B6C1D.2000407@oracle.com> Message-ID: <570B9121.1010908@oracle.com> Not really a qualified reviewer in this area, but I think this looks great! Shouldn't the remaining solaris 32-bit build support in the (old) makefiles and sources be purged altogether? Is there any point in holding on to things like solaris_x86_32.s (which in turn is referencing non-existent sources like os_solaris_i486.cpp)? Thanks! /Claes On 2016-04-11 11:19, Erik ?sterlund wrote: > Hi Dean, > > Changing the input to a memory operand did indeed work better. Thanks > for the great idea. > I updated the x86 code with cleaner assembly. > > Updated webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.01/ > > Thanks, > /Erik > > On 2016-04-09 02:20, Dean Long wrote: >> Hi Erik. Does this work any better? >> >> __asm__ volatile ("lock; addl $1,%0" : "+m" (*dest) : : "cc", >> "memory"); >> >> >> dl >> >> On 4/8/2016 4:52 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153076 >>> Webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.00/ >>> >>> On Solaris, the Atomic class puts its assembly in a separate .il >>> file, then the code blobs are declared as extern "C" and called from >>> Atomic. More modern GCC-style inline assembly is now supported, and >>> we should use that instead. It works fine the way it is, but making >>> calls just to get an instruction that could be inlined, seems >>> suboptimal. >>> >>> There are two important things to note: >>> >>> 1) I have removed all the 32 bit code from solaris Atomic, and weird >>> combinations with GCC and compiler1. JDK9 is only supported on 64 >>> bit SPARC and x86, building using Solaris Studio. Since it is using >>> GCC-style inline assembly, the code should work with GCC too, but I >>> have not tested that as it is not a supported way of building >>> OpenJDK. I personally do not think we should spend too much time on >>> supporting unsupported code. >>> >>> 2) There appears to be a bug in Solaris Studio for emitting memory >>> accesses on x86. >>> >>> The following code: >>> >>> inline void Atomic::inc (volatile jint* dest) { >>> __asm__ volatile ("lock; addl $1,(%0)" : >>> : "r" (dest) : "cc", "memory"); >>> } >>> >>> generated the following in HandleMark::initialize(Thread* thread) on >>> Solaris, x64, using SS12.4: >>> >>> lock addl $1, (%eax) >>> >>> Note the %eax instead of %rax. It is wrong and caused SIGSEGV as the >>> address was truncated, and libraries are not put within the first 4 >>> GB of VA. >>> >>> I worked around the issue by assigning the address operands to a >>> fixed register, rdx. Being awkward with the choice of registers is >>> still better than having to make calls. This will have to be fixed, >>> once the solaris studio bug is fixed. >>> >>> Note that for SPARC there were no issues like this and the generated >>> code is fine. >>> >>> Testing: JPRT >>> >>> I need a sponsor to push this. >>> >>> Thanks, >>> /Erik >> > From max.ockner at oracle.com Mon Apr 11 14:23:35 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 11 Apr 2016 10:23:35 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570B5E29.6040709@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> Message-ID: <570BB367.7060408@oracle.com> I missed this before. I'm going to investigate. Max On 4/11/2016 4:19 AM, Marcus Larsson wrote: > > > On 04/11/2016 09:00 AM, Thomas St?fe wrote: >> Hi Max, >> >> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner > > wrote: >> >> I forgot to respond to this: >> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>> (Replies in line) >>>> >>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>> Hi Max, >>>>> >>>>> Disclaimer: not a (R)eviewer. >>>>> >>>>> Do we really need a list of all tags and all decorators? >>>>> >>>> Just going by what we currently put in the hs_err file, I think >>>> this may be the first "Do we really need" we've ever asked for >>>> this type of change. >>>> >>>> All joking aside, I think it is a good idea to direct users >>>> toward proper UL usage whenever we have a chance. >>>> >>>>> Also: I assume what you print is the Log state as it is at the >>>>> time the hs-err file is printed. If logging was >>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>> would it be possible to see that? At least a warning if >>>>> logging was not enabled from the start on. >>>>> >>>> Would it be possible? Yes, but I think this would require a >>>> framework change. It does not look like any marks are made when >>>> the LogConfiguration changes during runtime, and we would need >>>> to record that in order to know what to print when we dump into >>>> hs_err. >>> >>> Yes, this would required the framework to keep some sort of log >>> of configuration changes. Is there value in knowing that the log >>> configuration changed since startup? >> >> I think it is useful along with other information. An example case: >> >> Let's say we are logging a message whenever a lock is acquired or >> released. In a subsystem like this, the action which dooms the vm >> may not cause an immediate crash. This leaves time for logging to >> turn on or off in between the bad action and the crash. If you >> don't know when logging was active and when it was not, then the >> absence of a particular message does not give you much >> information. You may not see the message that has the answer for >> you because it was not logged, though the action may have occurred. >> >> However, if we don't have the framework support for this then I >> believe it should be added later. >> >> >> >> This is a good example. A small easy solution, as I mentioned before, >> could be just to distinguish between "logging parameters stable since >> startup" and "logging parameters changed at some time". That way you >> would at least know whether to trust the logging output. >> >> But you are right, this can be added later. > > I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for this. > > Max: Did you see my comments about the ConfigurationLock? It was an > inline reply to your first mail. > > Thanks, > Marcus > >> >> Kind Regards, Thomas >> >> >>> >>>> >>>> Thanks, >>>> Max >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>> > wrote: >>>>> >>>>> Hello, >>>>> Please review another Unified Logging change. They are >>>>> almost done, and we are serious this time. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>> >>>>> >>> >>> LogConfiguration::describe() takes the ConfigurationLock, which >>> might be problematic for the error handler. I suppose the error >>> handler could potentially deadlock if its thread already holds >>> the lock. Unsure how to resolve this, because skipping to take >>> the lock means that we might crash due to another thread >>> changing the configuration as we read it. >>> >>> Thanks, >>> Marcus >>> >>>>> >>>>> The logging configuration is now printed in each hs_err >>>>> file. The output is the same as you would see from >>>>> -Xlog:logging=trace and it is obtained from >>>>> LogConfiguration::describe(). >>>>> >>>>> Below is a sample of the hs_err contents. The Logging info >>>>> is printed after VM Arguments and Whitebox, and before >>>>> Environment Variables. >>>>> >>>>> VM Arguments: >>>>> java_command: Kaboom >>>>> java_class_path (initial): . >>>>> Launcher Type: SUN_STANDARD >>>>> >>>>> Logging: >>>>> Available log levels: off, trace, debug, info, warning, error >>>>> Available log decorators: time (t), uptime (u), timemillis >>>>> (tm), uptimemillis (um), timenanos (tn), uptimenanos (un), >>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>> Available log tags: alloc, age, barrier, biasedlocking, >>>>> bot, census, classhisto, classresolve, classinit, >>>>> classload, classloaderdata, classunload, classpath, >>>>> compaction, cpu, cset, defaultmethods, ergo, exceptions, >>>>> exit, freelist, gc, heap, humongous, ihop, itables, jni, >>>>> liveness, logging, marking, metaspace, modules, >>>>> monitorinflation, os, phases, plab, promotion, preorder, >>>>> protectiondomain, ref, refine, region, remset, safepoint, >>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>> startuptime, state, stats, stringdedup, stringtable, >>>>> survivor, sweep, task, thread, tlab, time, >>>>> verboseverification, verify, vmoperation, vtables >>>>> Log output configuration: >>>>> #0: stdout all=off uptime,level,tags, >>>>> #1: stderr all=warning uptime,level,tags, >>>>> >>>>> Environment Variables: >>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>> SHELL=/bin/bash >>>>> OS=Linux >>>>> >>>>> >>>> >>> >> >> > From mikhailo.seledtsov at oracle.com Mon Apr 11 14:37:44 2016 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 11 Apr 2016 07:37:44 -0700 Subject: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder Message-ID: <570BB6B8.8000105@oracle.com> Please review this simple fix - the deletion of obsolete/redundant test utility class BasicJarBuilder. The functionality is now inside the ClassFileInstaller.java, and this utility is redundant. The work here was mainly to make sure no other parts of jdk or test reference BasicJarBuilder. JBS: https://bugs.openjdk.java.net/browse/JDK-8153549 Webrev: http://cr.openjdk.java.net/~mseledtsov/8153549.00/ Testing: - ensure no-one else uses it: grepped all hs-rt repository - no references - removed BasicJarBuilder; ran hotspot_all group locally on Linux-x64 Pass Thank you, Misha From ioi.lam at oracle.com Mon Apr 11 16:00:18 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 11 Apr 2016 09:00:18 -0700 Subject: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder In-Reply-To: <570BB6B8.8000105@oracle.com> References: <570BB6B8.8000105@oracle.com> Message-ID: <570BCA12.1030308@oracle.com> Looks good. Thanks Misha! - Ioi On 4/11/16 7:37 AM, Mikhailo Seledtsov wrote: > Please review this simple fix - the deletion of obsolete/redundant > test utility class > BasicJarBuilder. The functionality is now inside the > ClassFileInstaller.java, and this > utility is redundant. The work here was mainly to make sure no other > parts > of jdk or test reference BasicJarBuilder. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153549 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8153549.00/ > Testing: > - ensure no-one else uses it: grepped all hs-rt repository - no > references > - removed BasicJarBuilder; ran hotspot_all group locally on Linux-x64 > Pass > > Thank you, > Misha > From lois.foltan at oracle.com Mon Apr 11 17:24:11 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 11 Apr 2016 13:24:11 -0400 Subject: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder In-Reply-To: <570BB6B8.8000105@oracle.com> References: <570BB6B8.8000105@oracle.com> Message-ID: <570BDDBB.6040102@oracle.com> Looks good Misha! Lois On 4/11/2016 10:37 AM, Mikhailo Seledtsov wrote: > Please review this simple fix - the deletion of obsolete/redundant > test utility class > BasicJarBuilder. The functionality is now inside the > ClassFileInstaller.java, and this > utility is redundant. The work here was mainly to make sure no other > parts > of jdk or test reference BasicJarBuilder. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153549 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8153549.00/ > Testing: > - ensure no-one else uses it: grepped all hs-rt repository - no > references > - removed BasicJarBuilder; ran hotspot_all group locally on Linux-x64 > Pass > > Thank you, > Misha > From max.ockner at oracle.com Mon Apr 11 17:36:55 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 11 Apr 2016 13:36:55 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570BB367.7060408@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> Message-ID: <570BE0B7.4000406@oracle.com> Hello again, I have looked into this and I see a possible workaround to the issue raised by Marcus: LogConfiguration::describe() takes the ConfigurationLock, which might be problematic for the error handler. I suppose the error handler could potentially deadlock if its thread already holds the lock. Unsure how to resolve this, because skipping to take the lock means that we might crash due to another thread changing the configuration as we read it. My proposed solution is this: If the ConfigurationLock is held by another thread during the crash, then I think we could print "Log configuration can not be accessed because ConfigurationLock is currently held by another thread" or something similar. If the ConfigurationLock can be taken by the current thread, then print the configuration. We can accomplish this as follows: In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class extending ConfigurationLock. class ConfigurationLockMaybe : ConfigurationLock { private: bool _success; public: ConfigurationLockMaybe() { if (_semaphore.trywait()){_success = true;} } ~ConfigurationLock() { if(_success){_semaphore.signal();} } bool has_lock(){return _success;} }; _semaphore is a static var in ConfigurationLock, so the same copy is accessed in child classes. Another method LogConfiguration::describe_on_crash(outputStream* out) can use ConfigurationLockMaybe to attempt to print the configuration. In *vmError.cpp*: Replace LogConfiguration::describe with LogConfiguration::describe_on_crash. Max On 4/11/2016 10:23 AM, Max Ockner wrote: > I missed this before. I'm going to investigate. > Max > > On 4/11/2016 4:19 AM, Marcus Larsson wrote: >> >> >> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>> Hi Max, >>> >>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >> > wrote: >>> >>> I forgot to respond to this: >>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>> (Replies in line) >>>>> >>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>> Hi Max, >>>>>> >>>>>> Disclaimer: not a (R)eviewer. >>>>>> >>>>>> Do we really need a list of all tags and all decorators? >>>>>> >>>>> Just going by what we currently put in the hs_err file, I think >>>>> this may be the first "Do we really need" we've ever asked for >>>>> this type of change. >>>>> >>>>> All joking aside, I think it is a good idea to direct users >>>>> toward proper UL usage whenever we have a chance. >>>>> >>>>>> Also: I assume what you print is the Log state as it is at the >>>>>> time the hs-err file is printed. If logging was >>>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>>> would it be possible to see that? At least a warning if >>>>>> logging was not enabled from the start on. >>>>>> >>>>> Would it be possible? Yes, but I think this would require a >>>>> framework change. It does not look like any marks are made when >>>>> the LogConfiguration changes during runtime, and we would need >>>>> to record that in order to know what to print when we dump into >>>>> hs_err. >>>> >>>> Yes, this would required the framework to keep some sort of log >>>> of configuration changes. Is there value in knowing that the log >>>> configuration changed since startup? >>> >>> I think it is useful along with other information. An example case: >>> >>> Let's say we are logging a message whenever a lock is acquired or >>> released. In a subsystem like this, the action which dooms the vm >>> may not cause an immediate crash. This leaves time for logging to >>> turn on or off in between the bad action and the crash. If you >>> don't know when logging was active and when it was not, then the >>> absence of a particular message does not give you much >>> information. You may not see the message that has the answer for >>> you because it was not logged, though the action may have occurred. >>> >>> However, if we don't have the framework support for this then I >>> believe it should be added later. >>> >>> >>> >>> This is a good example. A small easy solution, as I mentioned >>> before, could be just to distinguish between "logging parameters >>> stable since startup" and "logging parameters changed at some time". >>> That way you would at least know whether to trust the logging output. >>> >>> But you are right, this can be added later. >> >> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >> >> Max: Did you see my comments about the ConfigurationLock? It was an >> inline reply to your first mail. >> >> Thanks, >> Marcus >> >>> >>> Kind Regards, Thomas >>> >>> >>>> >>>>> >>>>> Thanks, >>>>> Max >>>>>> Kind Regards, Thomas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>> > wrote: >>>>>> >>>>>> Hello, >>>>>> Please review another Unified Logging change. They are >>>>>> almost done, and we are serious this time. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>> >>>>>> >>>> >>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>> might be problematic for the error handler. I suppose the error >>>> handler could potentially deadlock if its thread already holds >>>> the lock. Unsure how to resolve this, because skipping to take >>>> the lock means that we might crash due to another thread >>>> changing the configuration as we read it. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>>> >>>>>> The logging configuration is now printed in each hs_err >>>>>> file. The output is the same as you would see from >>>>>> -Xlog:logging=trace and it is obtained from >>>>>> LogConfiguration::describe(). >>>>>> >>>>>> Below is a sample of the hs_err contents. The Logging info >>>>>> is printed after VM Arguments and Whitebox, and before >>>>>> Environment Variables. >>>>>> >>>>>> VM Arguments: >>>>>> java_command: Kaboom >>>>>> java_class_path (initial): . >>>>>> Launcher Type: SUN_STANDARD >>>>>> >>>>>> Logging: >>>>>> Available log levels: off, trace, debug, info, warning, >>>>>> error >>>>>> Available log decorators: time (t), uptime (u), timemillis >>>>>> (tm), uptimemillis (um), timenanos (tn), uptimenanos (un), >>>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>>> Available log tags: alloc, age, barrier, biasedlocking, >>>>>> bot, census, classhisto, classresolve, classinit, >>>>>> classload, classloaderdata, classunload, classpath, >>>>>> compaction, cpu, cset, defaultmethods, ergo, exceptions, >>>>>> exit, freelist, gc, heap, humongous, ihop, itables, jni, >>>>>> liveness, logging, marking, metaspace, modules, >>>>>> monitorinflation, os, phases, plab, promotion, preorder, >>>>>> protectiondomain, ref, refine, region, remset, safepoint, >>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>> survivor, sweep, task, thread, tlab, time, >>>>>> verboseverification, verify, vmoperation, vtables >>>>>> Log output configuration: >>>>>> #0: stdout all=off uptime,level,tags, >>>>>> #1: stderr all=warning uptime,level,tags, >>>>>> >>>>>> Environment Variables: >>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>> SHELL=/bin/bash >>>>>> OS=Linux >>>>>> >>>>>> >>>>> >>>> >>> >>> >> > From mikael.vidstedt at oracle.com Mon Apr 11 17:44:32 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 11 Apr 2016 10:44:32 -0700 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: References: <570831BD.7080005@oracle.com> Message-ID: <570BE280.6060301@oracle.com> Yes, I asked myself the same thing when I started moving things around. It may be more appropriate to put it in sharedRuntime instead. Does anybody else have an opinion on where it should go? Cheers, Mikael On 4/11/2016 2:03 AM, Thomas St?fe wrote: > Hi Mikael, > > just a question, should the new stubless functions not live someplace > else instead of in stubRoutines_ ? After all, they are not stub > routines anymore. > > Kind Regards, Thomas > > On Sat, Apr 9, 2016 at 12:33 AM, Mikael Vidstedt > > wrote: > > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ > > > * Note: this is patch 2 in a set of 3 all aiming to clean up and > unify the unsafe memory getters/setters, along with the handling > of unsafe access errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe > access error as an asynchronous exception > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe > getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > > In certain cases, such as accessing a region of a memory mapped > file which has been truncated on unix-style operating systems, a > SIGBUS signal will be raised and the VM will process it in the > signal handler. > > How the signal is processed differs depending on the operating > system and/or CPU architecture, with two major alternatives: > > * "stubless" > > Do the necessary thread state updates directly in the signal > handler, and modify the context so that the signal handler returns > to the place where the execution should continue > > * Using a stub > > Update the context so that when the signal handler returns the > thread will continue execution in a generated stub, which in turn > will call some native code in the VM to update the thread state > and figure out where execution should continue. The stub will then > jump to that new place. > > > It should be noted that the work of updating the thread state is > very small - it's setting a flag or two in the thread structure, > and figures out where the next instruction starts. It should also > be noted that the generated stubs today are broken, because they > do not preserve all the live registers over the call into the VM. > There are two ways to address this: > > * Preserve all the necessary registers > > This would mean implementing, in macro assembly, the necessary > logic for preserving all the live registers, including, but not > limited to, floating point registers, flag registers, etc. It > quickly becomes obvious that this platform specific and error prone. > > * Leverage the fact that the operating system already does this as > part of the signal handling > > Do the necessary work in the signal handler instead, removing the > need for the stub alltogether > > As mentioned, on some platforms the latter model is already in > use. It is dramatically easier and all platforms should be updated > to do it the same way. > > > * Testing > > Just as mentioned in the RFR for JDK-8153890, a new test was > developed to test this code path: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > > In fact, it was when running this test I found the register > preservation issue. JPRT also passes. Much like JDK-8153890 I > wanted to get some feedback on this before running additional tests. > > > Cheers, > Mikael > > From george.triantafillou at oracle.com Mon Apr 11 17:48:30 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Mon, 11 Apr 2016 13:48:30 -0400 Subject: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder In-Reply-To: <570BB6B8.8000105@oracle.com> References: <570BB6B8.8000105@oracle.com> Message-ID: <570BE36E.5070509@oracle.com> Hi Misha, Looks good. -George On 4/11/2016 10:37 AM, Mikhailo Seledtsov wrote: > Please review this simple fix - the deletion of obsolete/redundant > test utility class > BasicJarBuilder. The functionality is now inside the > ClassFileInstaller.java, and this > utility is redundant. The work here was mainly to make sure no other > parts > of jdk or test reference BasicJarBuilder. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153549 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8153549.00/ > Testing: > - ensure no-one else uses it: grepped all hs-rt repository - no > references > - removed BasicJarBuilder; ran hotspot_all group locally on Linux-x64 > Pass > > Thank you, > Misha > From christian.thalinger at oracle.com Mon Apr 11 17:59:42 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 11 Apr 2016 07:59:42 -1000 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> Message-ID: [This should be on hotspot-runtime-dev. BCC?ing hotspot-compiler-dev.] > On Apr 8, 2016, at 12:53 AM, Hiroshi H Horii wrote: > > Dear all: > > Can I please request reviews for the following change? > This change was created for JDK 9 and ppc64. > > Description: > This change adds options of compare-and-exchange for POWER architecture. > As described in atomic_linux_ppc.inline.hpp, the current implementation of > cmpxchg is fence_cmpxchg_acquire. This implementation is useful for > general purposes because twice calls of sync before and after cmpxchg will > keep consistency. However, they sometimes cause overheads because > sync instructions are very expensive in the current POWER chip design. > With this change, callers can explicitly specify to run fence and acquire with > two additional bool parameters. Because their default values are "true", > it is not necessary to modify existing cmpxchg calls. > > In addition, with the new parameters of cmpxchg, this change improves > performance of copy_to_survivor in the parallel GC. > copy_to_survivor changes forward pointers by using cmpxchg. This > operation doesn't require any sync instructions, in my understanding. > A pointer is changed at most once in a GC and when cmpxchg fails, > the latest pointer is available for the caller. > > When I evaluated SPECjbb2013 (slightly customized because obsolete grizzly > doesn't support new version format of Java 9), pause time of young GC was > reduced from 10% to 20%. > > Summary of source code changes: > > * src/share/vm/runtime/atomic.hpp > * src/share/vm/runtime/atomic.cpp > * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > - Add two arguments of fence and acquire to cmpxchg only for PPC64. > Though cmpxchg in atomic_linux_ppc.inline.hpp has some branches, > they are reduced while inlining to callers. > > * src/share/vm/oops/oop.inline.hpp > - Changed cas_set_mark to call cmpxchg without fence and acquire. > cas_set_mark is called only by cas_forward_to that is called only by > copy_to_survivor_space and oop_promotion_failed in > psPromotionManager. > > Code change: > > Please see an attached diff file that was generated with "hg diff -g" > under the latest hotspot directory. > > Passed test: > SPECjbb2013 (customized) > > * I believe some other cmpxchg will be optimized by reducing fence > or acquire because twice calls of sync are too conservative to implement > Java memory model. > > > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > From charlie.hunt at oracle.com Mon Apr 11 18:19:30 2016 From: charlie.hunt at oracle.com (charlie hunt) Date: Mon, 11 Apr 2016 13:19:30 -0500 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> Message-ID: <72593D96-F446-4A40-83AB-644E2B3A33EA@oracle.com> FYI, SPECjbb2013 is obsolete in favor of SPECjbb2015. SPECjbb2015 should run fine with JDK 9 in the default configuration with grizzly as the transport. I have run it on JDK 9 SPARC and JDK 9 x86/x64 platforms. hths, charlie > On Apr 11, 2016, at 12:59 PM, Christian Thalinger wrote: > > [This should be on hotspot-runtime-dev. BCC?ing hotspot-compiler-dev.] > >> On Apr 8, 2016, at 12:53 AM, Hiroshi H Horii wrote: >> >> Dear all: >> >> Can I please request reviews for the following change? >> This change was created for JDK 9 and ppc64. >> >> Description: >> This change adds options of compare-and-exchange for POWER architecture. >> As described in atomic_linux_ppc.inline.hpp, the current implementation of >> cmpxchg is fence_cmpxchg_acquire. This implementation is useful for >> general purposes because twice calls of sync before and after cmpxchg will >> keep consistency. However, they sometimes cause overheads because >> sync instructions are very expensive in the current POWER chip design. >> With this change, callers can explicitly specify to run fence and acquire with >> two additional bool parameters. Because their default values are "true", >> it is not necessary to modify existing cmpxchg calls. >> >> In addition, with the new parameters of cmpxchg, this change improves >> performance of copy_to_survivor in the parallel GC. >> copy_to_survivor changes forward pointers by using cmpxchg. This >> operation doesn't require any sync instructions, in my understanding. >> A pointer is changed at most once in a GC and when cmpxchg fails, >> the latest pointer is available for the caller. >> >> When I evaluated SPECjbb2013 (slightly customized because obsolete grizzly >> doesn't support new version format of Java 9), pause time of young GC was >> reduced from 10% to 20%. >> >> Summary of source code changes: >> >> * src/share/vm/runtime/atomic.hpp >> * src/share/vm/runtime/atomic.cpp >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >> - Add two arguments of fence and acquire to cmpxchg only for PPC64. >> Though cmpxchg in atomic_linux_ppc.inline.hpp has some branches, >> they are reduced while inlining to callers. >> >> * src/share/vm/oops/oop.inline.hpp >> - Changed cas_set_mark to call cmpxchg without fence and acquire. >> cas_set_mark is called only by cas_forward_to that is called only by >> copy_to_survivor_space and oop_promotion_failed in >> psPromotionManager. >> >> Code change: >> >> Please see an attached diff file that was generated with "hg diff -g" >> under the latest hotspot directory. >> >> Passed test: >> SPECjbb2013 (customized) >> >> * I believe some other cmpxchg will be optimized by reducing fence >> or acquire because twice calls of sync are too conservative to implement >> Java memory model. >> >> >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, Ph.D. >> IBM Research - Tokyo >> > From mikael.vidstedt at oracle.com Mon Apr 11 18:52:39 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 11 Apr 2016 11:52:39 -0700 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> Message-ID: <570BF276.5000000@oracle.com> David/Thomas, Thanks for the early feedback. Some comments below. On 4/11/2016 2:15 AM, Thomas St?fe wrote: > > > On Mon, Apr 11, 2016 at 11:05 AM, Thomas St?fe > > wrote: > > Hi David, > > On Mon, Apr 11, 2016 at 2:57 AM, David Holmes > > wrote: > > Hi Mikael, > > I think we need to be able to answer the question as to why > the stubbed and stubless forms of this code exist to ensure > that converting all platforms to the same form is appropriate. > > I'm still going through this but my initial reaction is to > wonder why we don't use the same form of handle_unsafe_access > on all platforms and always pass in npc? (That seems to be the > only difference in code that otherwise seems platform > independent.) > Yes, in effect what the handler is supposed to do is call t->set_pending_unsafe_access_error() and update the context so that when the thread eventually starts executing again it will start on the next instruction, following the one that faulted. Given how trivial the handler is I can see no reason to make it go through a stub, and several reasons for handling it directly in the signal handler instead. Maybe I'm missing something, let me know if you think of anything! > > On Solaris we get the npc for free in the signal ucontext. On x86 > it has to be calculated. But yes, this could be moved out of the > handle functions and just passed in. > Since the function is called from multiple different places it seems appropriate to have a dedicated function for it, even though it's "just" doing those two things. It also means it can be shared across the different operating systems, within the same CPU architecture. As noted, SPARC is indeed the odd man out which needs to take the additional "npc" argument, but I really don't think that's a big issue in the grand scheme of things. > > I also saw that we apparently miss handling for ppc. No one seemed > to miss it until now, but it may make sense to add handling anyway. > > > Oh, we do not miss it. Volker just showed me that it is done directly > in the signal handlers for AIX and Linux ppc. Exactly. AIX/ppc, linux/ppc and linux/aarch64 all handle it directly in the signal handler. Cheers, Mikael > Kind Regards, Thomas > > > Thanks, > David > > > On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: > > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ > > > > * Note: this is patch 2 in a set of 3 all aiming to clean > up and unify > the unsafe memory getters/setters, along with the handling > of unsafe > access errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle > unsafe access > error as an asynchronous exception > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update > Unsafe > getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > > In certain cases, such as accessing a region of a memory > mapped file > which has been truncated on unix-style operating systems, > a SIGBUS > signal will be raised and the VM will process it in the > signal handler. > > How the signal is processed differs depending on the > operating system > and/or CPU architecture, with two major alternatives: > > * "stubless" > > Do the necessary thread state updates directly in the > signal handler, > and modify the context so that the signal handler returns > to the place > where the execution should continue > > * Using a stub > > Update the context so that when the signal handler returns > the thread > will continue execution in a generated stub, which in turn > will call > some native code in the VM to update the thread state and > figure out > where execution should continue. The stub will then jump > to that new place. > > > It should be noted that the work of updating the thread > state is very > small - it's setting a flag or two in the thread > structure, and figures > out where the next instruction starts. It should also be > noted that the > generated stubs today are broken, because they do not > preserve all the > live registers over the call into the VM. There are two > ways to address > this: > > * Preserve all the necessary registers > > This would mean implementing, in macro assembly, the > necessary logic for > preserving all the live registers, including, but not > limited to, > floating point registers, flag registers, etc. It quickly > becomes > obvious that this platform specific and error prone. > > * Leverage the fact that the operating system already does > this as part > of the signal handling > > Do the necessary work in the signal handler instead, > removing the need > for the stub alltogether > > As mentioned, on some platforms the latter model is > already in use. It > is dramatically easier and all platforms should be updated > to do it the > same way. > > > * Testing > > Just as mentioned in the RFR for JDK-8153890, a new test > was developed > to test this code path: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > > In fact, it was when running this test I found the > register preservation > issue. JPRT also passes. Much like JDK-8153890 I wanted to > get some > feedback on this before running additional tests. > > > Cheers, > Mikael > > > From david.holmes at oracle.com Tue Apr 12 00:02:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Apr 2016 10:02:26 +1000 Subject: RFR(S): 8153890: Handle unsafe access error as an asynchronous exception In-Reply-To: <570AF4E0.9010300@oracle.com> References: <57083055.9070802@oracle.com> <570AF4E0.9010300@oracle.com> Message-ID: <570C3B12.6030207@oracle.com> HI Mikael, On 11/04/2016 10:50 AM, David Holmes wrote: > Hi Mikael, > > On 9/04/2016 8:27 AM, Mikael Vidstedt wrote: >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153890 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8153890/webrev.01/hotspot/webrev/ >> > > I'm not at all sure this is going in the right direction and I certainly > need some time to look at it in detail. I'm unclear what the timeliness > issue actually is, as converting errors to exceptions only makes sense > when entering/returning-to Java code. Can you elaborate on the timeliness problem please. The only way I could see this being an issue is if there is native loop using the unsafe access code, which also checks for pending exceptions. Otherwise you should see the exception thrown as soon as Java code is hit. I don't like using the preallocated InternalError instance precisely because we lose the stack information - something I would have thought to be the most important part! > My initial reaction is to not entangle these two completely different > forms of exceptional conditions. The unsafe access error is not really > asynchronous at all - it is a synchronous condition! - but conversion to > an exception is deferred which makes it appears as an asynchronous > exception at the Java level. Well there are three somewhat tangled "async" checks (external suspend, async-exceptions, unsafe access error) so always checking for unsafe access errors may not be an issue in itself - it is only the allocating of the InternalError that prohibits doing this presently. But as I said I think the inline allocation with a stacktrace is the most desired thing to have. Thanks, David > Thanks, > David > >> >> * Note: this is patch 1 in a set of 3 all aiming to clean up and unify >> the unsafe memory getters/setters, along with the handling of unsafe >> access errors. The other two issues are: >> >> https://bugs.openjdk.java.net/browse/JDK-8153892 - Handle unsafe access >> error directly in signal handler instead of going through a stub >> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >> getters/setters to use double-register variants >> >> >> * Summary (copied from the bug description) >> >> In certain cases, such as accessing a region of a memory mapped file >> which has been truncated on unix-style operating systems, a SIGBUS >> signal will be raised and the VM will process it in the signal handler. >> Currently, as part of the handling a flag is set on the thread >> indicating that an error has occurred: >> >> _special_runtime_exit_condition = _async_unsafe_access_error; >> >> Eventually the VM will check the flag and throw an InternalError. >> However, the flag is not always checked promptly, which means that the >> time between the error and the time when the InternalError is thrown can >> be very long. >> >> In parallel with this, there is functionality in the VM to set pending >> asynchronous exceptions on threads. These asynchronous exceptions are >> checked/thrown more often. >> >> Instead of having two mechanisms for handling these types of >> asynchronous events the unsafe access errors should be converted to use >> the normal asynchronous exception mechanism. >> >> One of the reasons why this isn't already the case is that when the >> SIGBUS signal is raised, the thread may not be in a place where it can >> allocate an exception - there may not be a safepoint on the instruction >> performing the memory access. The solution to this is to preallocate the >> InternalError exception at VM start up, and have the handler code simply >> use that exception instead. The only downside of this is that the >> exception will not have a stack trace. The flip side of that is that >> because of the unpredictability in when the async unsafe access error is >> actually thrown today it is likely that the stack trace in the exception >> doesn't actually reflect the place where the error actually occurred >> anyway. >> >> * Testing >> >> In addition to the JPRT smoke tests a new test has been developed for >> testing unsafe access errors, in particular accessing data in the >> truncated portion of a memory mapped file using the Unsafe primitives. >> The test can be found here: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >> >> The plan is to push it together with the final patch (JDK-8150921). Note >> though that the test fails unless the other patches mentioned above are >> also applied. >> >> I am also looking for to run additional testing on this before pushing, >> but wanted to get some early feedback. >> >> Cheers, >> Mikael >> From david.holmes at oracle.com Tue Apr 12 00:03:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Apr 2016 10:03:26 +1000 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> Message-ID: <570C3B4E.4080903@oracle.com> On 11/04/2016 7:15 PM, Thomas St?fe wrote: > > > On Mon, Apr 11, 2016 at 11:05 AM, Thomas St?fe > wrote: > > Hi David, > > On Mon, Apr 11, 2016 at 2:57 AM, David Holmes > > wrote: > > Hi Mikael, > > I think we need to be able to answer the question as to why the > stubbed and stubless forms of this code exist to ensure that > converting all platforms to the same form is appropriate. > > I'm still going through this but my initial reaction is to > wonder why we don't use the same form of handle_unsafe_access on > all platforms and always pass in npc? (That seems to be the only > difference in code that otherwise seems platform independent.) > > > On Solaris we get the npc for free in the signal ucontext. On x86 it > has to be calculated. But yes, this could be moved out of the handle > functions and just passed in. > > I also saw that we apparently miss handling for ppc. No one seemed > to miss it until now, but it may make sense to add handling anyway. > > > Oh, we do not miss it. Volker just showed me that it is done directly > in the signal handlers for AIX and Linux ppc. So is there more scope to refactor this out of the platform specific code altogether? David > > Kind Regards, Thomas > > > Thanks, > David > > > On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: > > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ > > > * Note: this is patch 2 in a set of 3 all aiming to clean up > and unify > the unsafe memory getters/setters, along with the handling > of unsafe > access errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle > unsafe access > error as an asynchronous exception > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe > getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > > In certain cases, such as accessing a region of a memory > mapped file > which has been truncated on unix-style operating systems, a > SIGBUS > signal will be raised and the VM will process it in the > signal handler. > > How the signal is processed differs depending on the > operating system > and/or CPU architecture, with two major alternatives: > > * "stubless" > > Do the necessary thread state updates directly in the signal > handler, > and modify the context so that the signal handler returns to > the place > where the execution should continue > > * Using a stub > > Update the context so that when the signal handler returns > the thread > will continue execution in a generated stub, which in turn > will call > some native code in the VM to update the thread state and > figure out > where execution should continue. The stub will then jump to > that new place. > > > It should be noted that the work of updating the thread > state is very > small - it's setting a flag or two in the thread structure, > and figures > out where the next instruction starts. It should also be > noted that the > generated stubs today are broken, because they do not > preserve all the > live registers over the call into the VM. There are two ways > to address > this: > > * Preserve all the necessary registers > > This would mean implementing, in macro assembly, the > necessary logic for > preserving all the live registers, including, but not > limited to, > floating point registers, flag registers, etc. It quickly > becomes > obvious that this platform specific and error prone. > > * Leverage the fact that the operating system already does > this as part > of the signal handling > > Do the necessary work in the signal handler instead, > removing the need > for the stub alltogether > > As mentioned, on some platforms the latter model is already > in use. It > is dramatically easier and all platforms should be updated > to do it the > same way. > > > * Testing > > Just as mentioned in the RFR for JDK-8153890, a new test was > developed > to test this code path: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > In fact, it was when running this test I found the register > preservation > issue. JPRT also passes. Much like JDK-8153890 I wanted to > get some > feedback on this before running additional tests. > > > Cheers, > Mikael > > > From david.holmes at oracle.com Tue Apr 12 00:29:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Apr 2016 10:29:51 +1000 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <570AF68B.9090707@oracle.com> References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> Message-ID: <570C417F.20600@oracle.com> On 11/04/2016 10:57 AM, David Holmes wrote: > Hi Mikael, > > I think we need to be able to answer the question as to why the stubbed > and stubless forms of this code exist to ensure that converting all > platforms to the same form is appropriate. The more I look at this the more the stubs make no sense :) AIII a stub is generated when we need runtime code that may be different to that which we could write directly for compiling at build time - ie to use CPU specific features of the actual CPU. But I see nothing here that suggests any such usage. So I agree with removing the stubs. > I'm still going through this but my initial reaction is to wonder why we > don't use the same form of handle_unsafe_access on all platforms and > always pass in npc? (That seems to be the only difference in code that > otherwise seems platform independent.) Futher to this and Thomas's comments I think handle_unsafe_access(thread, pc, npc) can be defined in shared code (where? not sure). Further, if we always pass in npc then we don't need to pass in pc as it is unused (seems unused in original code too for sparc). BTW I found this comment somewhat unfathomable (both now and in original code): + // pc is the instruction which we must emulate + // doing a no-op is fine: return garbage from the load but finally realized that it means that after the load that raised the signal the native code proceeds normally but the value apparently loaded is just garbage/arbitrary, and the only sign something went wrong is the setting of the pending unsafe-access-error bit. This would be a potential source of bugs I think, except that when we hit the Java level, we throw the exception and so never actually "return" the garbage value. But it does mean we would have to be careful if calling the unsafe routines from native code. Thanks, David > Thanks, > David > > On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >> >> >> >> * Note: this is patch 2 in a set of 3 all aiming to clean up and unify >> the unsafe memory getters/setters, along with the handling of unsafe >> access errors. The other two issues are: >> >> https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe access >> error as an asynchronous exception >> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >> getters/setters to use double-register variants >> >> >> * Summary (copied from the bug description) >> >> >> In certain cases, such as accessing a region of a memory mapped file >> which has been truncated on unix-style operating systems, a SIGBUS >> signal will be raised and the VM will process it in the signal handler. >> >> How the signal is processed differs depending on the operating system >> and/or CPU architecture, with two major alternatives: >> >> * "stubless" >> >> Do the necessary thread state updates directly in the signal handler, >> and modify the context so that the signal handler returns to the place >> where the execution should continue >> >> * Using a stub >> >> Update the context so that when the signal handler returns the thread >> will continue execution in a generated stub, which in turn will call >> some native code in the VM to update the thread state and figure out >> where execution should continue. The stub will then jump to that new >> place. >> >> >> It should be noted that the work of updating the thread state is very >> small - it's setting a flag or two in the thread structure, and figures >> out where the next instruction starts. It should also be noted that the >> generated stubs today are broken, because they do not preserve all the >> live registers over the call into the VM. There are two ways to address >> this: >> >> * Preserve all the necessary registers >> >> This would mean implementing, in macro assembly, the necessary logic for >> preserving all the live registers, including, but not limited to, >> floating point registers, flag registers, etc. It quickly becomes >> obvious that this platform specific and error prone. >> >> * Leverage the fact that the operating system already does this as part >> of the signal handling >> >> Do the necessary work in the signal handler instead, removing the need >> for the stub alltogether >> >> As mentioned, on some platforms the latter model is already in use. It >> is dramatically easier and all platforms should be updated to do it the >> same way. >> >> >> * Testing >> >> Just as mentioned in the RFR for JDK-8153890, a new test was developed >> to test this code path: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >> >> In fact, it was when running this test I found the register preservation >> issue. JPRT also passes. Much like JDK-8153890 I wanted to get some >> feedback on this before running additional tests. >> >> >> Cheers, >> Mikael >> From david.holmes at oracle.com Tue Apr 12 00:35:53 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Apr 2016 10:35:53 +1000 Subject: RFR(S): 8153890: Handle unsafe access error as an asynchronous exception In-Reply-To: <57083055.9070802@oracle.com> References: <57083055.9070802@oracle.com> Message-ID: <570C42E9.5040005@oracle.com> Looking at the test ... On 9/04/2016 8:27 AM, Mikael Vidstedt wrote: > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153890 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8153890/webrev.01/hotspot/webrev/ > > > * Note: this is patch 1 in a set of 3 all aiming to clean up and unify > the unsafe memory getters/setters, along with the handling of unsafe > access errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153892 - Handle unsafe access > error directly in signal handler instead of going through a stub > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe > getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > In certain cases, such as accessing a region of a memory mapped file > which has been truncated on unix-style operating systems, a SIGBUS > signal will be raised and the VM will process it in the signal handler. > Currently, as part of the handling a flag is set on the thread > indicating that an error has occurred: > > _special_runtime_exit_condition = _async_unsafe_access_error; > > Eventually the VM will check the flag and throw an InternalError. > However, the flag is not always checked promptly, which means that the > time between the error and the time when the InternalError is thrown can > be very long. > > In parallel with this, there is functionality in the VM to set pending > asynchronous exceptions on threads. These asynchronous exceptions are > checked/thrown more often. > > Instead of having two mechanisms for handling these types of > asynchronous events the unsafe access errors should be converted to use > the normal asynchronous exception mechanism. > > One of the reasons why this isn't already the case is that when the > SIGBUS signal is raised, the thread may not be in a place where it can > allocate an exception - there may not be a safepoint on the instruction > performing the memory access. The solution to this is to preallocate the > InternalError exception at VM start up, and have the handler code simply > use that exception instead. The only downside of this is that the > exception will not have a stack trace. The flip side of that is that > because of the unpredictability in when the async unsafe access error is > actually thrown today it is likely that the stack trace in the exception > doesn't actually reflect the place where the error actually occurred > anyway. > > * Testing > > In addition to the JPRT smoke tests a new test has been developed for > testing unsafe access errors, in particular accessing data in the > truncated portion of a memory mapped file using the Unsafe primitives. > The test can be found here: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java Here: } else { r.run(); // The operation may have raised a pending async // exception, make sure it's actually thrown forcePendingAsyncExceptionProcessing(); } forcePendingAsyncExceptionProcessing should not be needed. There is no way we should be able to return to Java without the pending exception being thrown from r.run()! If we can then there is a serious bug somewhere. Thanks, David > The plan is to push it together with the final patch (JDK-8150921). Note > though that the test fails unless the other patches mentioned above are > also applied. > > I am also looking for to run additional testing on this before pushing, > but wanted to get some early feedback. > > Cheers, > Mikael > From jiangli.zhou at oracle.com Tue Apr 12 01:44:48 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 11 Apr 2016 18:44:48 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <56FE0A77.6010604@oracle.com> References: <56FE0A77.6010604@oracle.com> Message-ID: Hi Ioi, I like the more structural way of reading/writing the compact table with SimpleCompactHashtable. It looks quite clean overall. - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive than TINY_BUCKET_TYPE? - The following assert in CompactSymbolTableWriter::add() limits the total shared space size to be less than MAX_SHARED_DELTA unnecessarily. Symbols are allocated from the RO space at dump time. We only need to make sure the max delta between the ?base_address? and the end of RO space is less than MAX_SHARED_DELTA. This is not a new issue introduced by your change, you don?t have to address that as part of this change if you prefer. I?ll file a separate RFE. 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol *symbol) { 172 address base_address = address(MetaspaceShared::shared_rs()->base()); 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); 174 assert(max_delta <= MAX_SHARED_DELTA, "range check"); - Why is the default RO space size increased? - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java Copyright year. Thanks, Jiangli > On Mar 31, 2016, at 10:43 PM, Ioi Lam wrote: > > Please review > > http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ > > Bug: Clean up CompactHashtable > > https://bugs.openjdk.java.net/browse/JDK-8150607 > > Summary of fix: > > [1] Instead of reading/writing the table bit-by-bit, which is tedious and > error prone, use SimpleCompactHashtable::serialize(), which is more > structural. > > [2] Split up the _buckets and _entries into two separate arrays, so the > dumping and walking code is easier to understand > > (see comments above SimpleCompactHashtable declaration) > These 2 arrays are now allocated from the RO region (used to be in RW) > > [3] Renamed a few things > > COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE > (having something called "compact" in CompactHashtable is confusing) > > The old names "dump_table" (actually dumping the buckets) and > "dump_buckets" (actually dumping the entries) were conflicting with > terminology used elsewhere. Now the terminology is unified: > "buckets" = the main index, "entries" = the second level. > > lookup_entry -> decode_entry (it wasn't doing any lookup) > > [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be > checked with assert. > > [5] Replaced all juint to u4 (suggested by Coleen) > > [6] templatize the iterator (see CompactHashtable::symbols_do -> > SimpleCompactHashtable::iterate) > > [7] I also added a test case using Serviceability Agent -- due to the lack of > a regression test, the walking of the compact hashtable in SA had been > broken for a while before it was fixed in JDK-8151368, so having a test > case would make the code more maintainable. > > Tests: > > Hotspot JTREG tests > > Thanks > - Ioi From david.holmes at oracle.com Tue Apr 12 01:54:37 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Apr 2016 11:54:37 +1000 Subject: RFR(S): 8153890: Handle unsafe access error as an asynchronous exception In-Reply-To: <570C42E9.5040005@oracle.com> References: <57083055.9070802@oracle.com> <570C42E9.5040005@oracle.com> Message-ID: <570C555D.8070307@oracle.com> The light is starting to shine ... :) On 12/04/2016 10:35 AM, David Holmes wrote: > Looking at the test ... > > On 9/04/2016 8:27 AM, Mikael Vidstedt wrote: >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153890 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8153890/webrev.01/hotspot/webrev/ >> >> >> >> * Note: this is patch 1 in a set of 3 all aiming to clean up and unify >> the unsafe memory getters/setters, along with the handling of unsafe >> access errors. The other two issues are: >> >> https://bugs.openjdk.java.net/browse/JDK-8153892 - Handle unsafe access >> error directly in signal handler instead of going through a stub >> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >> getters/setters to use double-register variants >> >> >> * Summary (copied from the bug description) >> >> In certain cases, such as accessing a region of a memory mapped file >> which has been truncated on unix-style operating systems, a SIGBUS >> signal will be raised and the VM will process it in the signal handler. >> Currently, as part of the handling a flag is set on the thread >> indicating that an error has occurred: >> >> _special_runtime_exit_condition = _async_unsafe_access_error; >> >> Eventually the VM will check the flag and throw an InternalError. >> However, the flag is not always checked promptly, which means that the >> time between the error and the time when the InternalError is thrown can >> be very long. >> >> In parallel with this, there is functionality in the VM to set pending >> asynchronous exceptions on threads. These asynchronous exceptions are >> checked/thrown more often. >> >> Instead of having two mechanisms for handling these types of >> asynchronous events the unsafe access errors should be converted to use >> the normal asynchronous exception mechanism. >> >> One of the reasons why this isn't already the case is that when the >> SIGBUS signal is raised, the thread may not be in a place where it can >> allocate an exception - there may not be a safepoint on the instruction >> performing the memory access. The solution to this is to preallocate the >> InternalError exception at VM start up, and have the handler code simply >> use that exception instead. The only downside of this is that the >> exception will not have a stack trace. The flip side of that is that >> because of the unpredictability in when the async unsafe access error is >> actually thrown today it is likely that the stack trace in the exception >> doesn't actually reflect the place where the error actually occurred >> anyway. >> >> * Testing >> >> In addition to the JPRT smoke tests a new test has been developed for >> testing unsafe access errors, in particular accessing data in the >> truncated portion of a memory mapped file using the Unsafe primitives. >> The test can be found here: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > Here: > > } else { > r.run(); > > // The operation may have raised a pending async > // exception, make sure it's actually thrown > forcePendingAsyncExceptionProcessing(); > } > > forcePendingAsyncExceptionProcessing should not be needed. There is no > way we should be able to return to Java without the pending exception > being thrown from r.run()! If we can then there is a serious bug somewhere. Ah! So now I think I see what the real bug is - it isn't timeliness it is a correctness issue. It should be impossible to return from native to Java without converting a pending "async error" into an actual exception. But the native call stub calls JavaThread::check_special_condition_for_native_trans, which in turn calls: thread->check_and_handle_async_exceptions(false); which skips the unsafe-access-error check. And that is wrong if the Unsafe methods are called as normal native methods. But we can't do the unsafe-access-error check while we are in a "trans" state if it will allocate. The existing code seems to assume that unsafe-access will not occur via the normal native call path. Exactly how are these unsafe accesses performed? David ----- > Thanks, > David > >> The plan is to push it together with the final patch (JDK-8150921). Note >> though that the test fails unless the other patches mentioned above are >> also applied. >> >> I am also looking for to run additional testing on this before pushing, >> but wanted to get some early feedback. >> >> Cheers, >> Mikael >> From ioi.lam at oracle.com Tue Apr 12 02:11:52 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 11 Apr 2016 19:11:52 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: References: <56FE0A77.6010604@oracle.com> Message-ID: <570C5968.3000401@oracle.com> Hi Jiangli, Thanks for the review: On 4/11/16 6:44 PM, Jiangli Zhou wrote: > Hi Ioi, > > I like the more structural way of reading/writing the compact table > with SimpleCompactHashtable. It looks quite clean overall. > > - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive > than TINY_BUCKET_TYPE? > OK, I will make the change. > - The following assert in CompactSymbolTableWriter::add() limits the > total shared space size to be less than MAX_SHARED_DELTA > unnecessarily. Symbols are allocated from the RO space at dump time. > We only need to make sure the max delta between the ?base_address? and > the end of RO space is less than MAX_SHARED_DELTA. This is not a new > issue introduced by your change, you don?t have to address that as > part of this change if you prefer. I?ll file a separate RFE. > I think it's better to do this in a separate RFE since MAX_SHARED_DELTA is used elsewhere as well. > 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol *symbol) { > 172 address base_address = address(MetaspaceShared::shared_rs()->base()); > 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); > 174 assert(max_delta <= MAX_SHARED_DELTA, "range check"); > > - Why is the default RO space size increased? > That's because the symbol table is moved from RW to RO, so I had to change the RO minimum size, or else test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. > - > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java > - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java > Copyright year. Will fix. Thanks - Ioi > > Thanks, > Jiangli > >> On Mar 31, 2016, at 10:43 PM, Ioi Lam > > wrote: >> >> Please review >> >> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >> >> >> Bug: Clean up CompactHashtable >> >> https://bugs.openjdk.java.net/browse/JDK-8150607 >> >> Summary of fix: >> >> [1] Instead of reading/writing the table bit-by-bit, which is tedious and >> error prone, use SimpleCompactHashtable::serialize(), which is more >> structural. >> >> [2] Split up the _buckets and _entries into two separate arrays, so the >> dumping and walking code is easier to understand >> >> (see comments above SimpleCompactHashtable declaration) >> These 2 arrays are now allocated from the RO region (used to be in RW) >> >> [3] Renamed a few things >> >> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >> (having something called "compact" in CompactHashtable is >> confusing) >> >> The old names "dump_table" (actually dumping the buckets) and >> "dump_buckets" (actually dumping the entries) were conflicting with >> terminology used elsewhere. Now the terminology is unified: >> "buckets" = the main index, "entries" = the second level. >> >> lookup_entry -> decode_entry (it wasn't doing any lookup) >> >> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >> checked with assert. >> >> [5] Replaced all juint to u4 (suggested by Coleen) >> >> [6] templatize the iterator (see CompactHashtable::symbols_do -> >> SimpleCompactHashtable::iterate) >> >> [7] I also added a test case using Serviceability Agent -- due to the >> lack of >> a regression test, the walking of the compact hashtable in SA had been >> broken for a while before it was fixed in JDK-8151368, so having a >> test >> case would make the code more maintainable. >> >> Tests: >> >> Hotspot JTREG tests >> >> Thanks >> - Ioi > From thomas.stuefe at gmail.com Tue Apr 12 09:15:37 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 12 Apr 2016 11:15:37 +0200 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <570C417F.20600@oracle.com> References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> <570C417F.20600@oracle.com> Message-ID: Hi Mikael, David, On Tue, Apr 12, 2016 at 2:29 AM, David Holmes wrote: > On 11/04/2016 10:57 AM, David Holmes wrote: > >> Hi Mikael, >> >> I think we need to be able to answer the question as to why the stubbed >> and stubless forms of this code exist to ensure that converting all >> platforms to the same form is appropriate. >> > > The more I look at this the more the stubs make no sense :) AIII a stub is > generated when we need runtime code that may be different to that which we > could write directly for compiling at build time - ie to use CPU specific > features of the actual CPU. But I see nothing here that suggests any such > usage. > > So I agree with removing the stubs. > > I'm still going through this but my initial reaction is to wonder why we >> don't use the same form of handle_unsafe_access on all platforms and >> always pass in npc? (That seems to be the only difference in code that >> otherwise seems platform independent.) >> > > Futher to this and Thomas's comments I think handle_unsafe_access(thread, > pc, npc) can be defined in shared code (where? not sure). Further, if we > always pass in npc then we don't need to pass in pc as it is unused (seems > unused in original code too for sparc). > > I agree. We commonized ucontext_set_pc for all Posix platforms, so we can make a common function "handle_unsafe_access(thread, npc)" and inside use os::Posix::ucontext_set_pc to modify the context. Then we can get rid of the special handling in the signal handlers inside os_aix_ppc.cpp and os_linux_ppc.cpp (for both the compiled and the interpreted case). BTW I found this comment somewhat unfathomable (both now and in original > code): > > + // pc is the instruction which we must emulate > + // doing a no-op is fine: return garbage from the load > > but finally realized that it means that after the load that raised the > signal the native code proceeds normally but the value apparently loaded is > just garbage/arbitrary, and the only sign something went wrong is the > setting of the pending unsafe-access-error bit. This would be a potential > source of bugs I think, except that when we hit the Java level, we throw > the exception and so never actually "return" the garbage value. But it does > mean we would have to be careful if calling the unsafe routines from native > code. > > I admit I do not understand fully how the _special_runtime_exit_condition flag is processed later, at least not for all cases: If I have a java method A using sun.misc.unsafe, which gets compiled, the sun.misc.unsafe intrinsic gets inlined into that method. So, the whole method A gets marked as "has unsafe access"? So, any SIGBUS happening inside this method - which may be larger than the inlined sun.misc.unsafe call - will yield an InternalError? And when is the flag checked if that method A is called from another java method B? Sorry if the questions are stupid, I am not a JIT expert, but I try to understand how much can happen between the SIGBUS and the InternalError getting thrown. Thanks, Thomas > Thanks, > David > > > Thanks, >> David >> >> On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: >> >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >>> >>> >>> >>> * Note: this is patch 2 in a set of 3 all aiming to clean up and unify >>> the unsafe memory getters/setters, along with the handling of unsafe >>> access errors. The other two issues are: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe access >>> error as an asynchronous exception >>> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >>> getters/setters to use double-register variants >>> >>> >>> * Summary (copied from the bug description) >>> >>> >>> In certain cases, such as accessing a region of a memory mapped file >>> which has been truncated on unix-style operating systems, a SIGBUS >>> signal will be raised and the VM will process it in the signal handler. >>> >>> How the signal is processed differs depending on the operating system >>> and/or CPU architecture, with two major alternatives: >>> >>> * "stubless" >>> >>> Do the necessary thread state updates directly in the signal handler, >>> and modify the context so that the signal handler returns to the place >>> where the execution should continue >>> >>> * Using a stub >>> >>> Update the context so that when the signal handler returns the thread >>> will continue execution in a generated stub, which in turn will call >>> some native code in the VM to update the thread state and figure out >>> where execution should continue. The stub will then jump to that new >>> place. >>> >>> >>> It should be noted that the work of updating the thread state is very >>> small - it's setting a flag or two in the thread structure, and figures >>> out where the next instruction starts. It should also be noted that the >>> generated stubs today are broken, because they do not preserve all the >>> live registers over the call into the VM. There are two ways to address >>> this: >>> >>> * Preserve all the necessary registers >>> >>> This would mean implementing, in macro assembly, the necessary logic for >>> preserving all the live registers, including, but not limited to, >>> floating point registers, flag registers, etc. It quickly becomes >>> obvious that this platform specific and error prone. >>> >>> * Leverage the fact that the operating system already does this as part >>> of the signal handling >>> >>> Do the necessary work in the signal handler instead, removing the need >>> for the stub alltogether >>> >>> As mentioned, on some platforms the latter model is already in use. It >>> is dramatically easier and all platforms should be updated to do it the >>> same way. >>> >>> >>> * Testing >>> >>> Just as mentioned in the RFR for JDK-8153890, a new test was developed >>> to test this code path: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >>> >>> In fact, it was when running this test I found the register preservation >>> issue. JPRT also passes. Much like JDK-8153890 I wanted to get some >>> feedback on this before running additional tests. >>> >>> >>> Cheers, >>> Mikael >>> >>> From andreas.eriksson at oracle.com Tue Apr 12 12:11:56 2016 From: andreas.eriksson at oracle.com (Andreas Eriksson) Date: Tue, 12 Apr 2016 14:11:56 +0200 Subject: RFR: 8135322: ConstantPool::release_C_heap_structures not run in some circumstances In-Reply-To: <56FEA04E.4060002@oracle.com> References: <56FBC2BE.3060806@oracle.com> <56FC5BE7.2080009@oracle.com> <56FDBDBC.40103@oracle.com> <56FEA04E.4060002@oracle.com> Message-ID: <570CE60C.2070306@oracle.com> Hi, Here is a new webrev where I do the filtering of the _deallocate_list. http://cr.openjdk.java.net/~aeriksso/8135322/webrev.01/ Another possible version is to call free_deallocate_list in ClassLoaderDataGraph::do_unloading. http://cr.openjdk.java.net/~aeriksso/8135322/webrev.do_unloading/ Both of these versions pass the test which crashed. What do you think? Any preference for one of the versions? Thanks, Andreas On 2016-04-01 18:22, Andreas Eriksson wrote: > Hi, > > When running some additional testing I had a test crash. > Looks like sometimes data we need to run a full deallocate_contents > call when we are in ~ClassLoaderData is already freed (seems to depend > on what GC we are running, and what we have in the _deallocate_list). > > Doing the free_deallocate_list call in > ClassLoaderDataGraph::do_unloading instead will most likely work, > since it's run at an earlier point in the GC. > Or I could do what I mentioned in the initial email, only run > release_C_heap_structures() on constant pools in the list that do not > have a corresponding InstanceKlass. > > I'm leaning towards, doing the free_deallocate_list call in > ClassLoaderDataGraph::do_unloading, when we detect that the > ClassLoaderData is dead. > I'll send out a new review once I've had some time to test that fix. > > Thanks, > Andreas > > On 2016-04-01 02:15, serguei.spitsyn at oracle.com wrote: >> Andreas, >> >> I agree with Coleen, it is a good find and a good and safe fix. >> >> Thanks! >> Serguei >> >> >> On 3/30/16 16:06, Coleen Phillimore wrote: >>> >>> Andreas, >>> >>> Good find! This seems like a safe fix. It's unfortunate to have to >>> walk the deallocate list, but I think it's short enough and less >>> work in comparison to having to call free_C_heap_structures on all >>> the other classes in the dead class loader data. And >>> deallocate_contents removes the scratch_class from the CLD _klasses >>> list so won't walk it twice. >>> >>> This is really good. >>> >>> Coleen >>> >>> On 3/30/16 8:12 AM, Andreas Eriksson wrote: >>>> Hi, >>>> >>>> Please review this fix for 8135322: >>>> ConstantPool::release_C_heap_structures not run in some circumstances. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135322 >>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8135322/webrev.00 >>>> >>>> The way this occurs is: >>>> >>>> 1. A ConstantPool, /merge_cp/, without a corresponding >>>> InstanceKlass is >>>> created during class redefinition. >>>> 2. /Merge_cp/ is added to ClassLoaderData::_deallocate_list, but is >>>> not >>>> cleaned up by ClassLoaderDataGraph::do_unloading because the >>>> holding >>>> ClassLoaderData is already dead. >>>> 3. ClassLoaderData::~ClassLoaderData is called, which usually runs >>>> InstanceKlass::release_C_heap_structures, which in turn will call >>>> ConstantPool::release_C_heap_structures. But since there is no >>>> corresponding InstanceKlass for /merge_cp/ it will never release >>>> its >>>> C heap structures. >>>> 4. For JDK 8 this means we leak a Monitor (ConstantPool::_lock). For >>>> JDK 9 the Monitor has been removed, but we will miss doing a >>>> call to >>>> ConstantPool::unreference_symbols, which is probably not good >>>> either. >>>> >>>> >>>> This change adds a call to free everything in the _deallocate_list >>>> first thing in ClassLoaderData::~ClassLoaderData. >>>> >>>> Note: >>>> Running deallocate_contents() on everything in the list might be >>>> doing unnecessary work: >>>> What we really would like to do is run release_C_heap_structures() >>>> on constant pools in the list that do not have a corresponding >>>> InstanceKlass. Not sure it's worth the effort to do the filtering, >>>> since I believe the _deallocate_list is usually not that long. >>>> >>>> Note 2: >>>> After fixing in JDK 9 I'll backport this to JDK 8, where it has a >>>> more immediately visible effect. >>>> >>>> Regards, >>>> Andreas >>>> >>> >> > From marcus.larsson at oracle.com Tue Apr 12 12:46:21 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 12 Apr 2016 14:46:21 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570BE0B7.4000406@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> Message-ID: <570CEE1D.2070306@oracle.com> Hi Max, On 04/11/2016 07:36 PM, Max Ockner wrote: > Hello again, > > I have looked into this and I see a possible workaround to the issue > raised by Marcus: > > LogConfiguration::describe() takes the ConfigurationLock, which > might be problematic for the error handler. I suppose the error > handler could potentially deadlock if its thread already holds > the lock. Unsure how to resolve this, because skipping to take > the lock means that we might crash due to another thread > changing the configuration as we read it. > > > My proposed solution is this: > > If the ConfigurationLock is held by another thread during the crash, > then I think we could print "Log configuration can not be accessed > because ConfigurationLock is currently held by another thread" or > something similar. If the ConfigurationLock can be taken by the > current thread, then print the configuration. > > We can accomplish this as follows: > > In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class > extending ConfigurationLock. > > class ConfigurationLockMaybe : ConfigurationLock { > private: > bool _success; > public: > ConfigurationLockMaybe() { > if (_semaphore.trywait()){_success = true;} > } > ~ConfigurationLock() { > if(_success){_semaphore.signal();} > } > bool has_lock(){return _success;} > }; > > _semaphore is a static var in ConfigurationLock, so the same copy is > accessed in child classes. > > Another method LogConfiguration::describe_on_crash(outputStream* out) > can use ConfigurationLockMaybe to attempt to print the configuration. > > In *vmError.cpp*: Replace LogConfiguration::describe with > LogConfiguration::describe_on_crash. Sounds good to me. ConfigurationLockMaybe sounds a bit weird but I don't have a better suggestion. Thanks, Marcus > > Max > > On 4/11/2016 10:23 AM, Max Ockner wrote: >> I missed this before. I'm going to investigate. >> Max >> >> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>> >>> >>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>> Hi Max, >>>> >>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>> > wrote: >>>> >>>> I forgot to respond to this: >>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>> (Replies in line) >>>>>> >>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> Disclaimer: not a (R)eviewer. >>>>>>> >>>>>>> Do we really need a list of all tags and all decorators? >>>>>>> >>>>>> Just going by what we currently put in the hs_err file, I think >>>>>> this may be the first "Do we really need" we've ever asked for >>>>>> this type of change. >>>>>> >>>>>> All joking aside, I think it is a good idea to direct users >>>>>> toward proper UL usage whenever we have a chance. >>>>>> >>>>>>> Also: I assume what you print is the Log state as it is at the >>>>>>> time the hs-err file is printed. If logging was >>>>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>>>> would it be possible to see that? At least a warning if >>>>>>> logging was not enabled from the start on. >>>>>>> >>>>>> Would it be possible? Yes, but I think this would require a >>>>>> framework change. It does not look like any marks are made when >>>>>> the LogConfiguration changes during runtime, and we would need >>>>>> to record that in order to know what to print when we dump into >>>>>> hs_err. >>>>> >>>>> Yes, this would required the framework to keep some sort of log >>>>> of configuration changes. Is there value in knowing that the log >>>>> configuration changed since startup? >>>> >>>> I think it is useful along with other information. An example >>>> case: >>>> >>>> Let's say we are logging a message whenever a lock is acquired or >>>> released. In a subsystem like this, the action which dooms the vm >>>> may not cause an immediate crash. This leaves time for logging to >>>> turn on or off in between the bad action and the crash. If you >>>> don't know when logging was active and when it was not, then the >>>> absence of a particular message does not give you much >>>> information. You may not see the message that has the answer for >>>> you because it was not logged, though the action may have >>>> occurred. >>>> >>>> However, if we don't have the framework support for this then I >>>> believe it should be added later. >>>> >>>> >>>> >>>> This is a good example. A small easy solution, as I mentioned >>>> before, could be just to distinguish between "logging parameters >>>> stable since startup" and "logging parameters changed at some >>>> time". That way you would at least know whether to trust the >>>> logging output. >>>> >>>> But you are right, this can be added later. >>> >>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >>> >>> Max: Did you see my comments about the ConfigurationLock? It was an >>> inline reply to your first mail. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>>> Kind Regards, Thomas >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>> > wrote: >>>>>>> >>>>>>> Hello, >>>>>>> Please review another Unified Logging change. They are >>>>>>> almost done, and we are serious this time. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>> >>>>>>> >>>>> >>>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>>> might be problematic for the error handler. I suppose the error >>>>> handler could potentially deadlock if its thread already holds >>>>> the lock. Unsure how to resolve this, because skipping to take >>>>> the lock means that we might crash due to another thread >>>>> changing the configuration as we read it. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>>> >>>>>>> The logging configuration is now printed in each hs_err >>>>>>> file. The output is the same as you would see from >>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>> LogConfiguration::describe(). >>>>>>> >>>>>>> Below is a sample of the hs_err contents. The Logging info >>>>>>> is printed after VM Arguments and Whitebox, and before >>>>>>> Environment Variables. >>>>>>> >>>>>>> VM Arguments: >>>>>>> java_command: Kaboom >>>>>>> java_class_path (initial): . >>>>>>> Launcher Type: SUN_STANDARD >>>>>>> >>>>>>> Logging: >>>>>>> Available log levels: off, trace, debug, info, warning, >>>>>>> error >>>>>>> Available log decorators: time (t), uptime (u), timemillis >>>>>>> (tm), uptimemillis (um), timenanos (tn), uptimenanos (un), >>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>>>> Available log tags: alloc, age, barrier, biasedlocking, >>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>> compaction, cpu, cset, defaultmethods, ergo, exceptions, >>>>>>> exit, freelist, gc, heap, humongous, ihop, itables, jni, >>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>> monitorinflation, os, phases, plab, promotion, preorder, >>>>>>> protectiondomain, ref, refine, region, remset, safepoint, >>>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>> Log output configuration: >>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>> >>>>>>> Environment Variables: >>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>> >>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>> >>>>>>> SHELL=/bin/bash >>>>>>> OS=Linux >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > From yasuenag at gmail.com Tue Apr 12 13:56:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 12 Apr 2016 22:56:33 +0900 Subject: Does CollectedHeap::print_on() need Heap_lock? Message-ID: <570CFE91.1070706@gmail.com> Hi all, I have a question about Heap_lock in Universe::print_*(). Universe::print_heap_at_SIGBREAK() gets Heap_lock. However, HeapInfoDCmd::execute() and Universe::print_on() do not get Heap_lock. Should we get Heap_lock when we print heap information? I guess that we should get this lock for consistency. -------------------- diff -r 87215e99d945 src/share/vm/memory/universe.cpp --- a/src/share/vm/memory/universe.cpp Wed Apr 06 23:42:52 2016 +0000 +++ b/src/share/vm/memory/universe.cpp Tue Apr 12 22:23:17 2016 +0900 @@ -1069,6 +1069,7 @@ } void Universe::print_on(outputStream* st) { + MutexLocker hl(Heap_lock); st->print_cr("Heap"); heap()->print_on(st); } diff -r 87215e99d945 src/share/vm/services/diagnosticCommand.cpp --- a/src/share/vm/services/diagnosticCommand.cpp Wed Apr 06 23:42:52 2016 +0000 +++ b/src/share/vm/services/diagnosticCommand.cpp Tue Apr 12 22:23:17 2016 +0900 @@ -413,6 +413,7 @@ } void HeapInfoDCmd::execute(DCmdSource source, TRAPS) { + MutexLocker hl(Heap_lock); Universe::heap()->print_on(output()); } -------------------- If it is correct, I file it to JBS and send review request. Thanks, Yasumasa From marcus.larsson at oracle.com Tue Apr 12 14:14:39 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 12 Apr 2016 16:14:39 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <5704B0B0.4010404@oracle.com> References: <5704B0B0.4010404@oracle.com> Message-ID: <570D02CF.7070708@oracle.com> Ping! On 04/06/2016 08:46 AM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add a warning for when tag > selections in -Xlog or VM.log don't match any tag sets used in the VM. > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8150894 > > Testing: > Internal VM tests with RBT > > Thanks, > Marcus From rachel.protacio at oracle.com Tue Apr 12 14:39:09 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 12 Apr 2016 10:39:09 -0400 Subject: RFR: 8152845: Improve PackageEntry and ModuleEntry print methods for future logging Message-ID: <570D088D.6090504@oracle.com> Hello, Please review this fix, moving the jigsaw PackageEntry and ModuleEntry print methods to product mode and making them able to take an outputStream. This way, we can use them for Unified Logging in the future. Note: I changed the signature to take an optional stream rather than following the "print_on" scheme because the print_on function that these classes inherit is declared as 'const', which is incompatible with the non-const function calls within the print function. Bug: https://bugs.openjdk.java.net/browse/JDK-8152845 Open webrev: http://cr.openjdk.java.net/~rprotacio/8152845.00/ Tested with JPRT and RBT quick and non-colo tests. Thanks, Rachel From max.ockner at oracle.com Tue Apr 12 15:01:35 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 12 Apr 2016 11:01:35 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570CEE1D.2070306@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> Message-ID: <570D0DCF.9030806@oracle.com> Marcus, I just spoke with Coleen about this. If I attempt to print configuration during a crash without lock and it crashes, the error handler will eat it up and start at the next step. It would be fun to write a locking mechanism, but this seems better to me. I will continue to call describe() from VM.info, but I will refactor the code in describe so that all of the information can be printed easily without taking a lock. For a crash, I'll use the refactored print functions to print all the necessary information without taking a lock. Even if the vm crashes during this step it is not such a bad thing because of the robust error handler. Thanks, Max On 4/12/2016 8:46 AM, Marcus Larsson wrote: > Hi Max, > > On 04/11/2016 07:36 PM, Max Ockner wrote: >> Hello again, >> >> I have looked into this and I see a possible workaround to the issue >> raised by Marcus: >> >> LogConfiguration::describe() takes the ConfigurationLock, which >> might be problematic for the error handler. I suppose the error >> handler could potentially deadlock if its thread already holds >> the lock. Unsure how to resolve this, because skipping to take >> the lock means that we might crash due to another thread >> changing the configuration as we read it. >> >> >> My proposed solution is this: >> >> If the ConfigurationLock is held by another thread during the crash, >> then I think we could print "Log configuration can not be accessed >> because ConfigurationLock is currently held by another thread" or >> something similar. If the ConfigurationLock can be taken by the >> current thread, then print the configuration. >> >> We can accomplish this as follows: >> >> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class >> extending ConfigurationLock. >> >> class ConfigurationLockMaybe : ConfigurationLock { >> private: >> bool _success; >> public: >> ConfigurationLockMaybe() { >> if (_semaphore.trywait()){_success = true;} >> } >> ~ConfigurationLock() { >> if(_success){_semaphore.signal();} >> } >> bool has_lock(){return _success;} >> }; >> >> _semaphore is a static var in ConfigurationLock, so the same copy is >> accessed in child classes. >> >> Another method LogConfiguration::describe_on_crash(outputStream* out) >> can use ConfigurationLockMaybe to attempt to print the configuration. >> >> In *vmError.cpp*: Replace LogConfiguration::describe with >> LogConfiguration::describe_on_crash. > > Sounds good to me. > > ConfigurationLockMaybe sounds a bit weird but I don't have a better > suggestion. > > Thanks, > Marcus > >> >> Max >> >> On 4/11/2016 10:23 AM, Max Ockner wrote: >>> I missed this before. I'm going to investigate. >>> Max >>> >>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>> >>>> >>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>> Hi Max, >>>>> >>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>> > wrote: >>>>> >>>>> I forgot to respond to this: >>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>> (Replies in line) >>>>>>> >>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>> >>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>> >>>>>>> Just going by what we currently put in the hs_err file, I think >>>>>>> this may be the first "Do we really need" we've ever asked for >>>>>>> this type of change. >>>>>>> >>>>>>> All joking aside, I think it is a good idea to direct users >>>>>>> toward proper UL usage whenever we have a chance. >>>>>>> >>>>>>>> Also: I assume what you print is the Log state as it is at the >>>>>>>> time the hs-err file is printed. If logging was >>>>>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>>>>> would it be possible to see that? At least a warning if >>>>>>>> logging was not enabled from the start on. >>>>>>>> >>>>>>> Would it be possible? Yes, but I think this would require a >>>>>>> framework change. It does not look like any marks are made when >>>>>>> the LogConfiguration changes during runtime, and we would need >>>>>>> to record that in order to know what to print when we dump into >>>>>>> hs_err. >>>>>> >>>>>> Yes, this would required the framework to keep some sort of log >>>>>> of configuration changes. Is there value in knowing that the log >>>>>> configuration changed since startup? >>>>> >>>>> I think it is useful along with other information. An example >>>>> case: >>>>> >>>>> Let's say we are logging a message whenever a lock is acquired or >>>>> released. In a subsystem like this, the action which dooms the vm >>>>> may not cause an immediate crash. This leaves time for logging to >>>>> turn on or off in between the bad action and the crash. If you >>>>> don't know when logging was active and when it was not, then the >>>>> absence of a particular message does not give you much >>>>> information. You may not see the message that has the answer for >>>>> you because it was not logged, though the action may have >>>>> occurred. >>>>> >>>>> However, if we don't have the framework support for this then I >>>>> believe it should be added later. >>>>> >>>>> >>>>> >>>>> This is a good example. A small easy solution, as I mentioned >>>>> before, could be just to distinguish between "logging parameters >>>>> stable since startup" and "logging parameters changed at some >>>>> time". That way you would at least know whether to trust the >>>>> logging output. >>>>> >>>>> But you are right, this can be added later. >>>> >>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >>>> >>>> Max: Did you see my comments about the ConfigurationLock? It was an >>>> inline reply to your first mail. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>>> Kind Regards, Thomas >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> Please review another Unified Logging change. They are >>>>>>>> almost done, and we are serious this time. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>> >>>>>>>> >>>>>> >>>>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>>>> might be problematic for the error handler. I suppose the error >>>>>> handler could potentially deadlock if its thread already holds >>>>>> the lock. Unsure how to resolve this, because skipping to take >>>>>> the lock means that we might crash due to another thread >>>>>> changing the configuration as we read it. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>>> >>>>>>>> The logging configuration is now printed in each hs_err >>>>>>>> file. The output is the same as you would see from >>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>> LogConfiguration::describe(). >>>>>>>> >>>>>>>> Below is a sample of the hs_err contents. The Logging info >>>>>>>> is printed after VM Arguments and Whitebox, and before >>>>>>>> Environment Variables. >>>>>>>> >>>>>>>> VM Arguments: >>>>>>>> java_command: Kaboom >>>>>>>> java_class_path (initial): . >>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>> >>>>>>>> Logging: >>>>>>>> Available log levels: off, trace, debug, info, warning, >>>>>>>> error >>>>>>>> Available log decorators: time (t), uptime (u), timemillis >>>>>>>> (tm), uptimemillis (um), timenanos (tn), uptimenanos (un), >>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>>>>> Available log tags: alloc, age, barrier, biasedlocking, >>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>> compaction, cpu, cset, defaultmethods, ergo, exceptions, >>>>>>>> exit, freelist, gc, heap, humongous, ihop, itables, jni, >>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>> monitorinflation, os, phases, plab, promotion, preorder, >>>>>>>> protectiondomain, ref, refine, region, remset, safepoint, >>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>> Log output configuration: >>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>> >>>>>>>> Environment Variables: >>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>> >>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>> >>>>>>>> SHELL=/bin/bash >>>>>>>> OS=Linux >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> > From lois.foltan at oracle.com Tue Apr 12 16:51:11 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 12 Apr 2016 12:51:11 -0400 Subject: RFR: 8152845: Improve PackageEntry and ModuleEntry print methods for future logging In-Reply-To: <570D088D.6090504@oracle.com> References: <570D088D.6090504@oracle.com> Message-ID: <570D277F.9060809@oracle.com> Looks good Rachel! Lois On 4/12/2016 10:39 AM, Rachel Protacio wrote: > Hello, > > Please review this fix, moving the jigsaw PackageEntry and ModuleEntry > print methods to product mode and making them able to take an > outputStream. This way, we can use them for Unified Logging in the > future. > > Note: I changed the signature to take an optional stream rather than > following the "print_on" scheme because the print_on function that > these classes inherit is declared as 'const', which is incompatible > with the non-const function calls within the print function. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152845 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152845.00/ > > Tested with JPRT and RBT quick and non-colo tests. > > Thanks, > Rachel From harold.seigel at oracle.com Tue Apr 12 17:16:54 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 12 Apr 2016 13:16:54 -0400 Subject: RFR: 8152845: Improve PackageEntry and ModuleEntry print methods for future logging In-Reply-To: <570D277F.9060809@oracle.com> References: <570D088D.6090504@oracle.com> <570D277F.9060809@oracle.com> Message-ID: <570D2D86.3090307@oracle.com> Looks good to me, also. Thanks, Harold On 4/12/2016 12:51 PM, Lois Foltan wrote: > Looks good Rachel! > Lois > > On 4/12/2016 10:39 AM, Rachel Protacio wrote: >> Hello, >> >> Please review this fix, moving the jigsaw PackageEntry and >> ModuleEntry print methods to product mode and making them able to >> take an outputStream. This way, we can use them for Unified Logging >> in the future. >> >> Note: I changed the signature to take an optional stream rather than >> following the "print_on" scheme because the print_on function that >> these classes inherit is declared as 'const', which is incompatible >> with the non-const function calls within the print function. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152845 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152845.00/ >> >> Tested with JPRT and RBT quick and non-colo tests. >> >> Thanks, >> Rachel > From rachel.protacio at oracle.com Tue Apr 12 17:18:13 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 12 Apr 2016 13:18:13 -0400 Subject: RFR: 8152845: Improve PackageEntry and ModuleEntry print methods for future logging In-Reply-To: <570D2D86.3090307@oracle.com> References: <570D088D.6090504@oracle.com> <570D277F.9060809@oracle.com> <570D2D86.3090307@oracle.com> Message-ID: <570D2DD5.4050303@oracle.com> Thanks for the reviews, Lois and Harold! Rachel On 4/12/2016 1:16 PM, harold seigel wrote: > Looks good to me, also. > > Thanks, Harold > > On 4/12/2016 12:51 PM, Lois Foltan wrote: >> Looks good Rachel! >> Lois >> >> On 4/12/2016 10:39 AM, Rachel Protacio wrote: >>> Hello, >>> >>> Please review this fix, moving the jigsaw PackageEntry and >>> ModuleEntry print methods to product mode and making them able to >>> take an outputStream. This way, we can use them for Unified Logging >>> in the future. >>> >>> Note: I changed the signature to take an optional stream rather than >>> following the "print_on" scheme because the print_on function that >>> these classes inherit is declared as 'const', which is incompatible >>> with the non-const function calls within the print function. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152845 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152845.00/ >>> >>> Tested with JPRT and RBT quick and non-colo tests. >>> >>> Thanks, >>> Rachel >> > From karen.kinnear at oracle.com Tue Apr 12 17:18:32 2016 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 12 Apr 2016 13:18:32 -0400 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <713E9C18-274A-41F5-AA40-56A78A608763@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <1EAD5675-6903-4C48-A778-05A99F591D1C@oracle.com> <4C106849-365D-42E8-B4A5-ADC7297BEA1B@oracle.com> <9F99FE47-E84D-4C4A-B854-F6432D10BC6C@oracle.com> <713E9C18-274A-41F5-AA40-56A78A608763@oracle.com> Message-ID: <2CAC294F-89AF-441B-B9BE-9CCD76C0B5B4@oracle.com> Igor, My apologies, I thought you had already decided to push. Yes, I am good with the changes. Sorry to keep you waiting. thanks, Karen > On Apr 6, 2016, at 1:49 PM, Igor Veresov wrote: > > Karen, am I correct to assume I can consider the current change reviewed? I?d like to push it. We can discuss how to harden/refactor other dimensions of the use of LinkResolver by compilers separately. > > Thanks, > igor > >> On Apr 5, 2016, at 4:22 PM, Igor Veresov wrote: >> >> >>> On Apr 5, 2016, at 3:33 PM, Karen Kinnear wrote: >>> >>> Igor, >>> >>> Do you run all the tests with -Xcomp or whatever flag ensures you test JVMCI vs. interpreter >>> for instance? >> >> Yes, I ran our RBT round of testing that does that -Xcomp and -Xmixed. >> >>> >>> If so, I am ok with checking this in - further notes below. >>> >>>> On Apr 5, 2016, at 3:43 PM, Igor Veresov > wrote: >>>> >>>> >>>>> On Apr 5, 2016, at 12:04 PM, Karen Kinnear > wrote: >>>>> >>>>> I am in agreement with Lois that the JVMS looks good with moving the exception. >>>> >>>> Thanks! >>>>> >>>>> With the checking I have done so far, I believe that linktime_resolve_static_method is only called with an invoke static - but after my next >>>>> meeting I will check one more time. It might be worth adding a comment. >>>> >>>> Ok, I added a comment to resolve_interface_method(): http://cr.openjdk.java.net/~iveresov/8153115/webrev.01/ >>>> Again, the bytecode argument here indicates the context, not the actual bytecode. Of course, for example, the method may be invoked with a method handle. >>>> >>>>> >>>>> My concern is specific to the code in jvmciCompilerToVM.cpp there is code called resolveMethod that checks >>>>> if holder_klass->is_interface -> LR::linktime_resolve_interface_method_or_null. >>>>> >>>> >>>> That code needs fixing as well. We have the following issue filed for that: https://bugs.openjdk.java.net/browse/JDK-8152903 >>>> In the nutshell, resolveMethod() sort of emulates what happens during a virtual call (it is only called for invokevirtual and invokeinterface). It should do both linktime and runtime resolutions. The JVMCI version should work the same way as the CI version (see ciMethod::resolve_invoke() in ciMethod.cpp). >>> >>> Hmmm - I see the ciMethod::resolve_invoke has the same problem that I just called out, so making the JVMCI one match >>> the CI version makes me wonder if we have sufficient test cases. But I hear that you would like to address that as a followup. >>> That is ok with me - I will add a note to the bug. >> >> Could you please explain what is the problem again? Are you concerned that the bytecode is not passed to resolve_invoke, so we may call linktime_resolve_interface_or_null, for an interface holder when in reality it was an invokevirtual instruction and vice versa? >> >>> >>> Also: I see a ciMethod::check_call that has a comment - >>> IT appears to fail when applied to an invoke interface call site. >>> FIXME: Remove this method and resolve_method_statically; refactor to use the other LinkResolver entry points. >>> >> >> This comment is odd. I don?t see why it would fail for invokeinterface. The code certainly seems to account for it. May be the comment is wrong? Any ideas? >> >> igor >> >>> Could you possibly file a bug on this one? What I am seeing is a conditional for invoke static vs. invoke virtual that does not take >>> the subtleties of invoke interface and invoke special into account. >>>> >>>> igor >>>> >>>>> I think we need to study this one more closely - I suspect that you need a set of detailed tests that cover the >>>>> corner cases here. I don?t know the code paths, but I would suggest following this approach of passing in the byte code, >>>>> so that you get the correct behavior depending on the requesting byte code. >>>>> >>>>> I am not sure what resolveMethod is doing here - since you seem to already have the resolved method and the receiver - so >>>>> I could use help studying this a bit more to understand if this really is resolution or is really selection. >>>>> >>>>> thanks, >>>>> Karen >>>>> >>>>>> On Apr 5, 2016, at 1:34 PM, Lois Foltan > wrote: >>>>>> >>>>>> >>>>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>>>> Hi Lois, >>>>>>> >>>>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>>>> >>>>>>> igor >>>>>> Hi Igor, >>>>>> >>>>>> Thanks for waiting on this. A couple of comments: >>>>>> >>>>>> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >>>>>> >>>>>> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >>>>>> >>>>>> Just curious did you also run the testbase default methods tests? >>>>>> Lois >>>>>> >>>>>>> >>>>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan > wrote: >>>>>>>> >>>>>>>> Hi Igor, >>>>>>>> >>>>>>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lois >>>>>>>> >>>>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> igor >> > From marcus.larsson at oracle.com Tue Apr 12 17:30:03 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 12 Apr 2016 19:30:03 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570D0DCF.9030806@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> Message-ID: <570D309B.5010109@oracle.com> Hey, On 2016-04-12 17:01, Max Ockner wrote: > Marcus, > > I just spoke with Coleen about this. If I attempt to print > configuration during a crash without lock and it crashes, the error > handler will eat it up and start at the next step. It would be fun to > write a locking mechanism, but this seems better to me. > > I will continue to call describe() from VM.info, but I will refactor > the code in describe so that all of the information can be printed > easily without taking a lock. For a crash, I'll use the refactored > print functions to print all the necessary information without taking > a lock. Even if the vm crashes during this step it is not such a bad > thing because of the robust error handler. Alright, that sounds good! Thanks, Marcus > > > Thanks, > Max > > On 4/12/2016 8:46 AM, Marcus Larsson wrote: >> Hi Max, >> >> On 04/11/2016 07:36 PM, Max Ockner wrote: >>> Hello again, >>> >>> I have looked into this and I see a possible workaround to the issue >>> raised by Marcus: >>> >>> LogConfiguration::describe() takes the ConfigurationLock, which >>> might be problematic for the error handler. I suppose the error >>> handler could potentially deadlock if its thread already holds >>> the lock. Unsure how to resolve this, because skipping to take >>> the lock means that we might crash due to another thread >>> changing the configuration as we read it. >>> >>> >>> My proposed solution is this: >>> >>> If the ConfigurationLock is held by another thread during the crash, >>> then I think we could print "Log configuration can not be accessed >>> because ConfigurationLock is currently held by another thread" or >>> something similar. If the ConfigurationLock can be taken by the >>> current thread, then print the configuration. >>> >>> We can accomplish this as follows: >>> >>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class >>> extending ConfigurationLock. >>> >>> class ConfigurationLockMaybe : ConfigurationLock { >>> private: >>> bool _success; >>> public: >>> ConfigurationLockMaybe() { >>> if (_semaphore.trywait()){_success = true;} >>> } >>> ~ConfigurationLock() { >>> if(_success){_semaphore.signal();} >>> } >>> bool has_lock(){return _success;} >>> }; >>> >>> _semaphore is a static var in ConfigurationLock, so the same copy is >>> accessed in child classes. >>> >>> Another method LogConfiguration::describe_on_crash(outputStream* >>> out) can use ConfigurationLockMaybe to attempt to print the >>> configuration. >>> >>> In *vmError.cpp*: Replace LogConfiguration::describe with >>> LogConfiguration::describe_on_crash. >> >> Sounds good to me. >> >> ConfigurationLockMaybe sounds a bit weird but I don't have a better >> suggestion. >> >> Thanks, >> Marcus >> >>> >>> Max >>> >>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>> I missed this before. I'm going to investigate. >>>> Max >>>> >>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>> >>>>> >>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>> Hi Max, >>>>>> >>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>> > wrote: >>>>>> >>>>>> I forgot to respond to this: >>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>> (Replies in line) >>>>>>>> >>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>> >>>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>>> >>>>>>>> Just going by what we currently put in the hs_err file, I >>>>>>>> think >>>>>>>> this may be the first "Do we really need" we've ever asked for >>>>>>>> this type of change. >>>>>>>> >>>>>>>> All joking aside, I think it is a good idea to direct users >>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>> >>>>>>>>> Also: I assume what you print is the Log state as it is at >>>>>>>>> the >>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>> logging was not enabled from the start on. >>>>>>>>> >>>>>>>> Would it be possible? Yes, but I think this would require a >>>>>>>> framework change. It does not look like any marks are made >>>>>>>> when >>>>>>>> the LogConfiguration changes during runtime, and we would need >>>>>>>> to record that in order to know what to print when we dump >>>>>>>> into >>>>>>>> hs_err. >>>>>>> >>>>>>> Yes, this would required the framework to keep some sort of log >>>>>>> of configuration changes. Is there value in knowing that the >>>>>>> log >>>>>>> configuration changed since startup? >>>>>> >>>>>> I think it is useful along with other information. An example >>>>>> case: >>>>>> >>>>>> Let's say we are logging a message whenever a lock is >>>>>> acquired or >>>>>> released. In a subsystem like this, the action which dooms >>>>>> the vm >>>>>> may not cause an immediate crash. This leaves time for >>>>>> logging to >>>>>> turn on or off in between the bad action and the crash. If you >>>>>> don't know when logging was active and when it was not, then the >>>>>> absence of a particular message does not give you much >>>>>> information. You may not see the message that has the answer for >>>>>> you because it was not logged, though the action may have >>>>>> occurred. >>>>>> >>>>>> However, if we don't have the framework support for this then I >>>>>> believe it should be added later. >>>>>> >>>>>> >>>>>> >>>>>> This is a good example. A small easy solution, as I mentioned >>>>>> before, could be just to distinguish between "logging parameters >>>>>> stable since startup" and "logging parameters changed at some >>>>>> time". That way you would at least know whether to trust the >>>>>> logging output. >>>>>> >>>>>> But you are right, this can be added later. >>>>> >>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >>>>> >>>>> Max: Did you see my comments about the ConfigurationLock? It was >>>>> an inline reply to your first mail. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> Kind Regards, Thomas >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>>> Kind Regards, Thomas >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> Please review another Unified Logging change. They are >>>>>>>>> almost done, and we are serious this time. >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>>>>> might be problematic for the error handler. I suppose the error >>>>>>> handler could potentially deadlock if its thread already holds >>>>>>> the lock. Unsure how to resolve this, because skipping to take >>>>>>> the lock means that we might crash due to another thread >>>>>>> changing the configuration as we read it. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>>> >>>>>>>>> The logging configuration is now printed in each hs_err >>>>>>>>> file. The output is the same as you would see from >>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>> LogConfiguration::describe(). >>>>>>>>> >>>>>>>>> Below is a sample of the hs_err contents. The Logging >>>>>>>>> info >>>>>>>>> is printed after VM Arguments and Whitebox, and before >>>>>>>>> Environment Variables. >>>>>>>>> >>>>>>>>> VM Arguments: >>>>>>>>> java_command: Kaboom >>>>>>>>> java_class_path (initial): . >>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>> >>>>>>>>> Logging: >>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>> warning, error >>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>> timemillis >>>>>>>>> (tm), uptimemillis (um), timenanos (tn), uptimenanos >>>>>>>>> (un), >>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>>>>>> Available log tags: alloc, age, barrier, biasedlocking, >>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, exceptions, >>>>>>>>> exit, freelist, gc, heap, humongous, ihop, itables, jni, >>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>> monitorinflation, os, phases, plab, promotion, preorder, >>>>>>>>> protectiondomain, ref, refine, region, remset, safepoint, >>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>> Log output configuration: >>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>> >>>>>>>>> Environment Variables: >>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>> >>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>> >>>>>>>>> SHELL=/bin/bash >>>>>>>>> OS=Linux >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From igor.veresov at oracle.com Tue Apr 12 18:54:33 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 12 Apr 2016 11:54:33 -0700 Subject: RFR(S) 8153115: Move private interface check to linktime In-Reply-To: <2CAC294F-89AF-441B-B9BE-9CCD76C0B5B4@oracle.com> References: <7C1EDB2F-3203-4699-861F-0C57BAF16E9D@oracle.com> <5703E823.8050400@oracle.com> <86D93F15-9D23-4BD1-A2C7-141548096024@oracle.com> <5703F717.702@oracle.com> <1EAD5675-6903-4C48-A778-05A99F591D1C@oracle.com> <4C106849-365D-42E8-B4A5-ADC7297BEA1B@oracle.com> <9F99FE47-E84D-4C4A-B854-F6432D10BC6C@oracle.com> <713E9C18-274A-41F5-AA40-56A78A608763@oracle.com> <2CAC294F-89AF-441B-B9BE-9CCD76C0B5B4@oracle.com> Message-ID: Thanks, Karen! igor > On Apr 12, 2016, at 10:18 AM, Karen Kinnear wrote: > > Igor, > > My apologies, I thought you had already decided to push. Yes, I am good with the changes. > Sorry to keep you waiting. > > thanks, > Karen > >> On Apr 6, 2016, at 1:49 PM, Igor Veresov wrote: >> >> Karen, am I correct to assume I can consider the current change reviewed? I?d like to push it. We can discuss how to harden/refactor other dimensions of the use of LinkResolver by compilers separately. >> >> Thanks, >> igor >> >>> On Apr 5, 2016, at 4:22 PM, Igor Veresov wrote: >>> >>> >>>> On Apr 5, 2016, at 3:33 PM, Karen Kinnear wrote: >>>> >>>> Igor, >>>> >>>> Do you run all the tests with -Xcomp or whatever flag ensures you test JVMCI vs. interpreter >>>> for instance? >>> >>> Yes, I ran our RBT round of testing that does that -Xcomp and -Xmixed. >>> >>>> >>>> If so, I am ok with checking this in - further notes below. >>>> >>>>> On Apr 5, 2016, at 3:43 PM, Igor Veresov > wrote: >>>>> >>>>> >>>>>> On Apr 5, 2016, at 12:04 PM, Karen Kinnear > wrote: >>>>>> >>>>>> I am in agreement with Lois that the JVMS looks good with moving the exception. >>>>> >>>>> Thanks! >>>>>> >>>>>> With the checking I have done so far, I believe that linktime_resolve_static_method is only called with an invoke static - but after my next >>>>>> meeting I will check one more time. It might be worth adding a comment. >>>>> >>>>> Ok, I added a comment to resolve_interface_method(): http://cr.openjdk.java.net/~iveresov/8153115/webrev.01/ >>>>> Again, the bytecode argument here indicates the context, not the actual bytecode. Of course, for example, the method may be invoked with a method handle. >>>>> >>>>>> >>>>>> My concern is specific to the code in jvmciCompilerToVM.cpp there is code called resolveMethod that checks >>>>>> if holder_klass->is_interface -> LR::linktime_resolve_interface_method_or_null. >>>>>> >>>>> >>>>> That code needs fixing as well. We have the following issue filed for that: https://bugs.openjdk.java.net/browse/JDK-8152903 >>>>> In the nutshell, resolveMethod() sort of emulates what happens during a virtual call (it is only called for invokevirtual and invokeinterface). It should do both linktime and runtime resolutions. The JVMCI version should work the same way as the CI version (see ciMethod::resolve_invoke() in ciMethod.cpp). >>>> >>>> Hmmm - I see the ciMethod::resolve_invoke has the same problem that I just called out, so making the JVMCI one match >>>> the CI version makes me wonder if we have sufficient test cases. But I hear that you would like to address that as a followup. >>>> That is ok with me - I will add a note to the bug. >>> >>> Could you please explain what is the problem again? Are you concerned that the bytecode is not passed to resolve_invoke, so we may call linktime_resolve_interface_or_null, for an interface holder when in reality it was an invokevirtual instruction and vice versa? >>> >>>> >>>> Also: I see a ciMethod::check_call that has a comment - >>>> IT appears to fail when applied to an invoke interface call site. >>>> FIXME: Remove this method and resolve_method_statically; refactor to use the other LinkResolver entry points. >>>> >>> >>> This comment is odd. I don?t see why it would fail for invokeinterface. The code certainly seems to account for it. May be the comment is wrong? Any ideas? >>> >>> igor >>> >>>> Could you possibly file a bug on this one? What I am seeing is a conditional for invoke static vs. invoke virtual that does not take >>>> the subtleties of invoke interface and invoke special into account. >>>>> >>>>> igor >>>>> >>>>>> I think we need to study this one more closely - I suspect that you need a set of detailed tests that cover the >>>>>> corner cases here. I don?t know the code paths, but I would suggest following this approach of passing in the byte code, >>>>>> so that you get the correct behavior depending on the requesting byte code. >>>>>> >>>>>> I am not sure what resolveMethod is doing here - since you seem to already have the resolved method and the receiver - so >>>>>> I could use help studying this a bit more to understand if this really is resolution or is really selection. >>>>>> >>>>>> thanks, >>>>>> Karen >>>>>> >>>>>>> On Apr 5, 2016, at 1:34 PM, Lois Foltan > wrote: >>>>>>> >>>>>>> >>>>>>> On 4/5/2016 12:50 PM, Igor Veresov wrote: >>>>>>>> Hi Lois, >>>>>>>> >>>>>>>> Thanks for looking at it. Yes, it passes all hotspot jtreg tests. >>>>>>>> >>>>>>>> igor >>>>>>> Hi Igor, >>>>>>> >>>>>>> Thanks for waiting on this. A couple of comments: >>>>>>> >>>>>>> - Section 6.5 Instructions for invokeinterface does indicate that a "Linking Exceptions" the VM can throw an ICCE if the resolved method is static or private. So I think moving this exception from runtime to linktime is okay. >>>>>>> >>>>>>> - I'm concerned about the change on line #998, #1030, #1316. I don't think you are necessarily guaranteed to have the bytecodes that you are now passing to resolve_interface_method. For example, line #998 within linktime_resolve_static_method, you may not have an invokestatic here, you may have another invoke* bytecode trying to invoke a static interface method. Passing in Bytecodes::_invokestatic seems wrong, because even if the resolved method is static, "nostatics" was set to false. >>>>>>> >>>>>>> Just curious did you also run the testbase default methods tests? >>>>>>> Lois >>>>>>> >>>>>>>> >>>>>>>>> On Apr 5, 2016, at 9:30 AM, Lois Foltan > wrote: >>>>>>>>> >>>>>>>>> Hi Igor, >>>>>>>>> >>>>>>>>> I know you have two reviews for this but could you hold off committing until I or Karen Kinnear have a chance to review. We both worked in this area a lot to support default methods in JDK 8. Also, have you run the hotspot/test/runtime/SelectionResolution tests on this? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Lois >>>>>>>>> >>>>>>>>> On 4/1/2016 2:28 PM, Igor Veresov wrote: >>>>>>>>>> When invoking private interface methods with invokeinterface we throw ICCE. The check for that happens in the runtime part of the resolution, however, doing it at linktime seems like a better place, since the check doesn't depend on the receiver type. It also allows compiler interfaces that rely on linktime resolution to detect inconsistencies during parsing (see ciEnv::lookup_method() (CI) and ConstantPool.lookupMethod() (JVMCI) that are affected). >>>>>>>>>> >>>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153115 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8153115/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> igor >>> >> > From jiangli.zhou at oracle.com Tue Apr 12 19:40:15 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 12 Apr 2016 12:40:15 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <570C5968.3000401@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> Message-ID: <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> Ioi, > On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: > > Hi Jiangli, > > > Thanks for the review: > > On 4/11/16 6:44 PM, Jiangli Zhou wrote: >> Hi Ioi, >> >> I like the more structural way of reading/writing the compact table with SimpleCompactHashtable. It looks quite clean overall. >> >> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive than TINY_BUCKET_TYPE? >> > OK, I will make the change. > >> - The following assert in CompactSymbolTableWriter::add() limits the total shared space size to be less than MAX_SHARED_DELTA unnecessarily. Symbols are allocated from the RO space at dump time. We only need to make sure the max delta between the ?base_address? and the end of RO space is less than MAX_SHARED_DELTA. This is not a new issue introduced by your change, you don?t have to address that as part of this change if you prefer. I?ll file a separate RFE. >> > I think it's better to do this in a separate RFE since MAX_SHARED_DELTA is used elsewhere as well. I filed JDK-8154108 . > >> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol *symbol) { >> 172 address base_address = address(MetaspaceShared::shared_rs()->base()); >> 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); >> 174 assert(max_delta <= MAX_SHARED_DELTA, "range check"); >> >> - Why is the default RO space size increased? >> > That's because the symbol table is moved from RW to RO, so I had to change the RO minimum size, or else test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. Ok. Thanks, Jiangli >> - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >> - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >> Copyright year. > > Will fix. > > Thanks > - Ioi >> >> Thanks, >> Jiangli >> >>> On Mar 31, 2016, at 10:43 PM, Ioi Lam > wrote: >>> >>> Please review >>> >>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>> >>> Bug: Clean up CompactHashtable >>> >>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>> >>> Summary of fix: >>> >>> [1] Instead of reading/writing the table bit-by-bit, which is tedious and >>> error prone, use SimpleCompactHashtable::serialize(), which is more >>> structural. >>> >>> [2] Split up the _buckets and _entries into two separate arrays, so the >>> dumping and walking code is easier to understand >>> >>> (see comments above SimpleCompactHashtable declaration) >>> These 2 arrays are now allocated from the RO region (used to be in RW) >>> >>> [3] Renamed a few things >>> >>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>> (having something called "compact" in CompactHashtable is confusing) >>> >>> The old names "dump_table" (actually dumping the buckets) and >>> "dump_buckets" (actually dumping the entries) were conflicting with >>> terminology used elsewhere. Now the terminology is unified: >>> "buckets" = the main index, "entries" = the second level. >>> >>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>> >>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>> checked with assert. >>> >>> [5] Replaced all juint to u4 (suggested by Coleen) >>> >>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>> SimpleCompactHashtable::iterate) >>> >>> [7] I also added a test case using Serviceability Agent -- due to the lack of >>> a regression test, the walking of the compact hashtable in SA had been >>> broken for a while before it was fixed in JDK-8151368, so having a test >>> case would make the code more maintainable. >>> >>> Tests: >>> >>> Hotspot JTREG tests >>> >>> Thanks >>> - Ioi >> > From coleen.phillimore at oracle.com Tue Apr 12 21:33:02 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 12 Apr 2016 17:33:02 -0400 Subject: RFR: 8152845: Improve PackageEntry and ModuleEntry print methods for future logging In-Reply-To: <570D088D.6090504@oracle.com> References: <570D088D.6090504@oracle.com> Message-ID: <570D698E.6030201@oracle.com> But in these functions, the print is going to print to tty rather than to the outputStream* st: +void ModuleEntryTable::print(outputStream* st) { + st->print_cr("Module Entry Table (table_size=%d, entries=%d)", table_size(), number_of_entries()); for (int i = 0; i < table_size(); i++) { for (ModuleEntry* probe = bucket(i); probe != NULL; probe = probe->next()) { probe->print(); } } } Which functions weren't declared as const? Coleen On 4/12/16 10:39 AM, Rachel Protacio wrote: > Hello, > > Please review this fix, moving the jigsaw PackageEntry and ModuleEntry > print methods to product mode and making them able to take an > outputStream. This way, we can use them for Unified Logging in the > future. > > Note: I changed the signature to take an optional stream rather than > following the "print_on" scheme because the print_on function that > these classes inherit is declared as 'const', which is incompatible > with the non-const function calls within the print function. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152845 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152845.00/ > > Tested with JPRT and RBT quick and non-colo tests. > > Thanks, > Rachel From david.holmes at oracle.com Wed Apr 13 12:56:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Apr 2016 22:56:54 +1000 Subject: [PING] RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570B6D89.2040000@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570B6D89.2040000@gmail.com> Message-ID: <570E4216.3070807@oracle.com> Hi Yasumasa, On 11/04/2016 7:25 PM, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ Please see my updates to the bug (sorry have been on vacation). This needs to be done in the launcher to be correct as we do not set the name of threads that attach via JNI, which includes the main thread. David > > Thanks, > > Yasumasa > > > On 2016/03/31 8:49, Yasumasa Suenaga wrote: >> Thanks Robbin, >> >> I'm waiting a sponsor and more reviewer :-) >> >> Yasumasa >> >> 2016/03/31 5:58 "Robbin Ehn" > >: >> >> FYI: I'm not a Reviewer. >> >> /Robbin >> >> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >> >> Thanks, looks good. >> >> /Robbin >> >> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >> >> Hi, >> >> I uploaded new webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/03/30 19:10, Robbin Ehn wrote: >> >> Hi, >> >> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >> >> Hi Robbin, >> >> 2016/03/30 18:22 "Robbin Ehn" >> >> > >>: >> > >> > Hi Yasumasa, >> > >> > >> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >> >> >> >> Hi Robbin, >> >> 2016/03/25 1:51 "Robbin Ehn" >> >> > > >> >> > > >>>: >> >> >> >> > >> >> > Hi Yasumasa, >> >> > >> >> > I'm not sure why you don't set it: >> >> > >> >> > diff -r ded6ef79c770 >> src/share/vm/runtime/thread.cpp >> >> > --- a/src/share/vm/runtime/thread.cpp >> Thu Mar 24 13:09:16 2016 >> +0000 >> >> > +++ b/src/share/vm/runtime/thread.cpp >> Thu Mar 24 17:40:09 2016 >> +0100 >> >> > @@ -3584,6 +3584,7 @@ >> >> > JavaThread* main_thread = new >> JavaThread(); >> >> > >> main_thread->set_thread_state(_thread_in_vm); >> >> > main_thread->initialize_thread_current(); >> >> > + >> main_thread->set_native_thread_name("main"); >> >> > // must do this before set_active_handles >> >> > main_thread->record_stack_base_and_size(); >> >> > >> >> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >> >> > >> >> > here instead? Am I missing something? >> >> >> >> Native thread name is the same to thread name >> in Thread class. >> >> It is set in c'tor in Thread or setName(). >> >> If you create new thread in Java app, native >> thread name will be >> set at >> >> startup. However, main thread is already >> starte in VM. >> >> Thread name for "main" is set in >> create_initial_thread(). >> >> I think that the place of setting thrrad name >> should be the same. >> > >> > >> > Yes, I see your point. But then something like >> this is nicer, no? >> > >> > --- a/src/share/vm/runtime/thread.cpp Tue >> Mar 29 09:43:05 2016 >> +0200 >> > +++ b/src/share/vm/runtime/thread.cpp Wed >> Mar 30 10:51:12 2016 >> +0200 >> > @@ -981,6 +981,7 @@ >> > // Creates the initial Thread >> > static oop create_initial_thread(Handle >> thread_group, JavaThread* >> thread, >> > TRAPS) { >> > + static const char* initial_thread_name = >> "main"; >> > Klass* k = >> >> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, >> CHECK_NULL); >> > instanceKlassHandle klass (THREAD, k); >> > instanceHandle thread_oop = >> klass->allocate_instance_handle(CHECK_NULL); >> > @@ -988,8 +989,10 @@ >> > java_lang_Thread::set_thread(thread_oop(), >> thread); >> > >> java_lang_Thread::set_priority(thread_oop(), NormPriority); >> > thread->set_threadObj(thread_oop()); >> > - >> > - Handle string = >> java_lang_String::create_from_str("main", >> CHECK_NULL); >> > + >> > + >> thread->set_native_thread_name(initial_thread_name); >> > + >> > + Handle string = >> >> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >> > >> > JavaValue result(T_VOID); >> > JavaCalls::call_special(&result, thread_oop, >> >> Okay, I will upload new webrev later. >> >> >> Thanks! >> >> >> >> > The launcher seem to name itself 'java' >> and naming this thread >> just >> >> > 'main' is confusing to me. >> >> > >> >> > E.g. so main thread of the process (and >> thus the process) is >> 'java' but >> >> > first JavaThread is 'main'. >> >> >> >> The native main thread in the process is not >> JavaThread. It is >> waiting >> >> for ending of Java main thread with >> pthread_join(). >> >> set_native_thread_name() is for JavaThread. >> So I think that we do >> not >> >> need to call it for native main thread. >> > >> > >> > Not sure if we can change it anyhow, since we >> want java and native >> name to be the same and java thread name might >> have some dependents. >> > >> > The name is visible in e.g. /proc. >> > >> > $ ps H -C java -o 'pid tid comm' | head -4 >> > PID TID COMMAND >> > 6423 6423 java >> > 6423 6424 main >> > 6423 6425 GC Thread#0 >> > >> > It would be nice with something like 'Java >> Main Thread'. >> >> I do not think so. >> Native main thread might not be a Java launcher - >> e.g. Apache >> commons-daemon, JNI application, etc. >> >> If you want to change native main thread name, I >> think that we have to >> change Java launcher code. >> Should I include it in new webrev? >> >> >> No >> >> Thanks again! >> >> /Robbin >> >> >> Thanks, >> >> Yasumasa >> >> > Thanks >> > >> > /Robbin >> > >> > >> >> >> >> Thanks, >> >> >> >> Yasumasa >> >> >> >> > Thanks! >> >> > >> >> > /Robbin >> >> > >> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga >> wrote: >> >> > > Hi all, >> >> > > >> >> > > HotSpot for Linux will set thread name via >> pthread_setname_np(). >> >> > > However, main thread does not have it. >> >> > > >> >> > > All JavaThread have native name, and >> main thread is >> JavaThread. >> >> > > For consistency, main thread should have >> native thread name. >> >> > > >> >> > > I uploaded a webrev. Could you review it? >> >> > > >> >> > > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >> >> > > >> >> > > I cannot access JPRT. >> >> > > So I need a sponsor. >> >> > > >> >> > > >> >> > > Thanks, >> >> > > >> >> > > Yasumasa >> >> > > >> >> >> From david.holmes at oracle.com Wed Apr 13 13:00:02 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Apr 2016 23:00:02 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> Message-ID: <570E42D2.4060609@oracle.com> I'll answer on this original thread as well ... Hi Yasumasa, Please see my updates to the bug (sorry have been on vacation). This needs to be done in the launcher to be correct as we do not set the name of threads that attach via JNI, which includes the "main" thread. David On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: > Thanks Robbin, > > I'm waiting a sponsor and more reviewer :-) > > Yasumasa > 2016/03/31 5:58 "Robbin Ehn" : > >> FYI: I'm not a Reviewer. >> >> /Robbin >> >> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >> >>> Thanks, looks good. >>> >>> /Robbin >>> >>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>> >>>> Hi, >>>> >>>> I uploaded new webrev. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>> >>>>> Hi, >>>>> >>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>> >>>>>> Hi Robbin, >>>>>> >>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>> >: >>>>>> > >>>>>> > Hi Yasumasa, >>>>>> > >>>>>> > >>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>> >> >>>>>> >> Hi Robbin, >>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>> >>>>>> >> >>: >>>>>> >> >>>>>> >> > >>>>>> >> > Hi Yasumasa, >>>>>> >> > >>>>>> >> > I'm not sure why you don't set it: >>>>>> >> > >>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 >>>>>> +0000 >>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 >>>>>> +0100 >>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>> >> > main_thread->initialize_thread_current(); >>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>> >> > // must do this before set_active_handles >>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>> >> > >>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>> >> > >>>>>> >> > here instead? Am I missing something? >>>>>> >> >>>>>> >> Native thread name is the same to thread name in Thread class. >>>>>> >> It is set in c'tor in Thread or setName(). >>>>>> >> If you create new thread in Java app, native thread name will be >>>>>> set at >>>>>> >> startup. However, main thread is already starte in VM. >>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>> >> I think that the place of setting thrrad name should be the same. >>>>>> > >>>>>> > >>>>>> > Yes, I see your point. But then something like this is nicer, no? >>>>>> > >>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 >>>>>> +0200 >>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 >>>>>> +0200 >>>>>> > @@ -981,6 +981,7 @@ >>>>>> > // Creates the initial Thread >>>>>> > static oop create_initial_thread(Handle thread_group, JavaThread* >>>>>> thread, >>>>>> > TRAPS) { >>>>>> > + static const char* initial_thread_name = "main"; >>>>>> > Klass* k = >>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, >>>>>> CHECK_NULL); >>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>> > instanceHandle thread_oop = >>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>> > @@ -988,8 +989,10 @@ >>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >>>>>> > thread->set_threadObj(thread_oop()); >>>>>> > - >>>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>>> CHECK_NULL); >>>>>> > + >>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>> > + >>>>>> > + Handle string = >>>>>> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >>>>>> > >>>>>> > JavaValue result(T_VOID); >>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>> >>>>>> Okay, I will upload new webrev later. >>>>>> >>>>> >>>>> Thanks! >>>>> >>>>> >>>>>> >> > The launcher seem to name itself 'java' and naming this thread >>>>>> just >>>>>> >> > 'main' is confusing to me. >>>>>> >> > >>>>>> >> > E.g. so main thread of the process (and thus the process) is >>>>>> 'java' but >>>>>> >> > first JavaThread is 'main'. >>>>>> >> >>>>>> >> The native main thread in the process is not JavaThread. It is >>>>>> waiting >>>>>> >> for ending of Java main thread with pthread_join(). >>>>>> >> set_native_thread_name() is for JavaThread. So I think that we do >>>>>> not >>>>>> >> need to call it for native main thread. >>>>>> > >>>>>> > >>>>>> > Not sure if we can change it anyhow, since we want java and native >>>>>> name to be the same and java thread name might have some dependents. >>>>>> > >>>>>> > The name is visible in e.g. /proc. >>>>>> > >>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>> > PID TID COMMAND >>>>>> > 6423 6423 java >>>>>> > 6423 6424 main >>>>>> > 6423 6425 GC Thread#0 >>>>>> > >>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>> >>>>>> I do not think so. >>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>> commons-daemon, JNI application, etc. >>>>>> >>>>>> If you want to change native main thread name, I think that we have to >>>>>> change Java launcher code. >>>>>> Should I include it in new webrev? >>>>>> >>>>> >>>>> No >>>>> >>>>> Thanks again! >>>>> >>>>> /Robbin >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> > Thanks >>>>>> > >>>>>> > /Robbin >>>>>> > >>>>>> > >>>>>> >> >>>>>> >> Thanks, >>>>>> >> >>>>>> >> Yasumasa >>>>>> >> >>>>>> >> > Thanks! >>>>>> >> > >>>>>> >> > /Robbin >>>>>> >> > >>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>> >> > > Hi all, >>>>>> >> > > >>>>>> >> > > HotSpot for Linux will set thread name via >>>>>> pthread_setname_np(). >>>>>> >> > > However, main thread does not have it. >>>>>> >> > > >>>>>> >> > > All JavaThread have native name, and main thread is >>>>>> JavaThread. >>>>>> >> > > For consistency, main thread should have native thread name. >>>>>> >> > > >>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>> >> > > >>>>>> >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>> >> > > >>>>>> >> > > I cannot access JPRT. >>>>>> >> > > So I need a sponsor. >>>>>> >> > > >>>>>> >> > > >>>>>> >> > > Thanks, >>>>>> >> > > >>>>>> >> > > Yasumasa >>>>>> >> > > >>>>>> >> >>>>>> >>>>>> From goetz.lindenmaier at sap.com Wed Apr 13 13:25:05 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 13 Apr 2016 13:25:05 +0000 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. Message-ID: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> Hi, could someone please have a look at this tiny issue? And sponsor? Thanks, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 8. April 2016 10:53 > To: hotspot-runtime-dev at openjdk.java.net > Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is > parsed at jlong. > > Hi, > > > > The upper limit of the range for flag MaxDirectMemorySize is MAX_SIZE_T. > > The flag is used to set a property that is parsed into a long. Thus, the max > > value on 64-bit platforms is too large. > > Fix: Limit the range to max_jlong, too. > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/wr16/8153835-MaxDMSz/webrev.01/ > > > > Best regards, > > Goetz. > > > > From rachel.protacio at oracle.com Wed Apr 13 14:57:05 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 13 Apr 2016 10:57:05 -0400 Subject: RFR: 8152845: Improve PackageEntry and ModuleEntry print methods for future logging In-Reply-To: <570D698E.6030201@oracle.com> References: <570D088D.6090504@oracle.com> <570D698E.6030201@oracle.com> Message-ID: <570E5E41.3020005@oracle.com> On 4/12/2016 5:33 PM, Coleen Phillimore wrote: > > But in these functions, the print is going to print to tty rather than > to the outputStream* st: > > +void ModuleEntryTable::print(outputStream* st) { > + st->print_cr("Module Entry Table (table_size=%d, entries=%d)", > table_size(), number_of_entries()); > for (int i = 0; i < table_size(); i++) { > for (ModuleEntry* probe = bucket(i); > probe != NULL; > probe = probe->next()) { > probe->print(); > } > } > } > I missed the print() at the end, thanks for noticing! New webrev: http://cr.openjdk.java.net/~rprotacio/8152845.01/ > Which functions weren't declared as const? > table_size() and number_of_entries() from hashtable.hpp both aren't const. And neither is ModuleEntryTable::bucket(). Rachel > Coleen > > > On 4/12/16 10:39 AM, Rachel Protacio wrote: >> Hello, >> >> Please review this fix, moving the jigsaw PackageEntry and >> ModuleEntry print methods to product mode and making them able to >> take an outputStream. This way, we can use them for Unified Logging >> in the future. >> >> Note: I changed the signature to take an optional stream rather than >> following the "print_on" scheme because the print_on function that >> these classes inherit is declared as 'const', which is incompatible >> with the non-const function calls within the print function. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152845 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152845.00/ >> >> Tested with JPRT and RBT quick and non-colo tests. >> >> Thanks, >> Rachel > From yasuenag at gmail.com Wed Apr 13 15:28:54 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 14 Apr 2016 00:28:54 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570E42D2.4060609@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> Message-ID: <570E65B6.2010809@gmail.com> Hi David, Thanks for your comment. I exported new JVM function to set native thread name, and JLI uses it in new webrev. Could you review again? - hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ - jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ Thanks, Yasumasa On 2016/04/13 22:00, David Holmes wrote: > I'll answer on this original thread as well ... > > Hi Yasumasa, > > Please see my updates to the bug (sorry have been on vacation). This needs to be done in the launcher to be correct as we do not set the name of threads that attach via JNI, which includes the "main" thread. > > David > > On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >> Thanks Robbin, >> >> I'm waiting a sponsor and more reviewer :-) >> >> Yasumasa >> 2016/03/31 5:58 "Robbin Ehn" : >> >>> FYI: I'm not a Reviewer. >>> >>> /Robbin >>> >>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>> >>>> Thanks, looks good. >>>> >>>> /Robbin >>>> >>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>> >>>>> Hi, >>>>> >>>>> I uploaded new webrev. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>> >>>>>>> Hi Robbin, >>>>>>> >>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>> >: >>>>>>> > >>>>>>> > Hi Yasumasa, >>>>>>> > >>>>>>> > >>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>> >> >>>>>>> >> Hi Robbin, >>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>> >>>>>>> >> >>: >>>>>>> >> >>>>>>> >> > >>>>>>> >> > Hi Yasumasa, >>>>>>> >> > >>>>>>> >> > I'm not sure why you don't set it: >>>>>>> >> > >>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 13:09:16 2016 >>>>>>> +0000 >>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 17:40:09 2016 >>>>>>> +0100 >>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>> >> > // must do this before set_active_handles >>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>> >> > >>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>> >> > >>>>>>> >> > here instead? Am I missing something? >>>>>>> >> >>>>>>> >> Native thread name is the same to thread name in Thread class. >>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>> >> If you create new thread in Java app, native thread name will be >>>>>>> set at >>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>>> >> I think that the place of setting thrrad name should be the same. >>>>>>> > >>>>>>> > >>>>>>> > Yes, I see your point. But then something like this is nicer, no? >>>>>>> > >>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 2016 >>>>>>> +0200 >>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 2016 >>>>>>> +0200 >>>>>>> > @@ -981,6 +981,7 @@ >>>>>>> > // Creates the initial Thread >>>>>>> > static oop create_initial_thread(Handle thread_group, JavaThread* >>>>>>> thread, >>>>>>> > TRAPS) { >>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>> > Klass* k = >>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), true, >>>>>>> CHECK_NULL); >>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>> > instanceHandle thread_oop = >>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>> > @@ -988,8 +989,10 @@ >>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>> > - >>>>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>>>> CHECK_NULL); >>>>>>> > + >>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>> > + >>>>>>> > + Handle string = >>>>>>> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >>>>>>> > >>>>>>> > JavaValue result(T_VOID); >>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>> >>>>>>> Okay, I will upload new webrev later. >>>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>>> >> > The launcher seem to name itself 'java' and naming this thread >>>>>>> just >>>>>>> >> > 'main' is confusing to me. >>>>>>> >> > >>>>>>> >> > E.g. so main thread of the process (and thus the process) is >>>>>>> 'java' but >>>>>>> >> > first JavaThread is 'main'. >>>>>>> >> >>>>>>> >> The native main thread in the process is not JavaThread. It is >>>>>>> waiting >>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>> >> set_native_thread_name() is for JavaThread. So I think that we do >>>>>>> not >>>>>>> >> need to call it for native main thread. >>>>>>> > >>>>>>> > >>>>>>> > Not sure if we can change it anyhow, since we want java and native >>>>>>> name to be the same and java thread name might have some dependents. >>>>>>> > >>>>>>> > The name is visible in e.g. /proc. >>>>>>> > >>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>> > PID TID COMMAND >>>>>>> > 6423 6423 java >>>>>>> > 6423 6424 main >>>>>>> > 6423 6425 GC Thread#0 >>>>>>> > >>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>> >>>>>>> I do not think so. >>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>> commons-daemon, JNI application, etc. >>>>>>> >>>>>>> If you want to change native main thread name, I think that we have to >>>>>>> change Java launcher code. >>>>>>> Should I include it in new webrev? >>>>>>> >>>>>> >>>>>> No >>>>>> >>>>>> Thanks again! >>>>>> >>>>>> /Robbin >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> > Thanks >>>>>>> > >>>>>>> > /Robbin >>>>>>> > >>>>>>> > >>>>>>> >> >>>>>>> >> Thanks, >>>>>>> >> >>>>>>> >> Yasumasa >>>>>>> >> >>>>>>> >> > Thanks! >>>>>>> >> > >>>>>>> >> > /Robbin >>>>>>> >> > >>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>> >> > > Hi all, >>>>>>> >> > > >>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>> pthread_setname_np(). >>>>>>> >> > > However, main thread does not have it. >>>>>>> >> > > >>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>> JavaThread. >>>>>>> >> > > For consistency, main thread should have native thread name. >>>>>>> >> > > >>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>> >> > > >>>>>>> >> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>> >> > > >>>>>>> >> > > I cannot access JPRT. >>>>>>> >> > > So I need a sponsor. >>>>>>> >> > > >>>>>>> >> > > >>>>>>> >> > > Thanks, >>>>>>> >> > > >>>>>>> >> > > Yasumasa >>>>>>> >> > > >>>>>>> >> >>>>>>> >>>>>>> From chris.hegarty at oracle.com Wed Apr 13 15:43:07 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Apr 2016 16:43:07 +0100 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported Message-ID: <570E690B.2060703@oracle.com> This review is for the second significant part of the changes for JEP 260 [1]. When created, the jdk.unsupported module [2] initially contained the sun.misc package. This issue is will move all the non-Critical APIs out of sun.reflect, leaving only the critical ones, at which point sun.reflect can be moved to the jdk.unsupported module. http://cr.openjdk.java.net/~chegar/8137058/ https://bugs.openjdk.java.net/browse/JDK-8137058 Summary of the changes: - Move all existing sun.reflect types to jdk.internal.reflect, and fix up references in the libraries, and the VM, to use the new internal location. - Update tests, as appropriate, to use the new location. - Add the minimal set of critical APIs to jdk.unsupported/sun.reflect. These ultimately delegate to the internal versions. Additionally, a few new tests have been added to exercise these. -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8132928 [2] https://bugs.openjdk.java.net/browse/JDK-8153737 From Alan.Bateman at oracle.com Wed Apr 13 15:59:20 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Apr 2016 16:59:20 +0100 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <570E690B.2060703@oracle.com> References: <570E690B.2060703@oracle.com> Message-ID: <570E6CD8.4080107@oracle.com> On 13/04/2016 16:43, Chris Hegarty wrote: > This review is for the second significant part of the changes for JEP > 260 [1]. When created, the jdk.unsupported module [2] initially > contained the sun.misc package. This issue is will move all the > non-Critical APIs out of sun.reflect, leaving only the critical ones, at > which point sun.reflect can be moved to the jdk.unsupported module. > > http://cr.openjdk.java.net/~chegar/8137058/ > https://bugs.openjdk.java.net/browse/JDK-8137058 > This looks good. A few comments: I assume the new sun.reflect.Reflection should have a private constructor to prevent it being instantiated. You've probably thought about this already but I assume the @Deprecated in Reflection.getCallerClass should reference the supported API. The changes to InetAddress don't seem unrelated but good. -Alan. From chris.hegarty at oracle.com Wed Apr 13 16:10:15 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Apr 2016 17:10:15 +0100 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <570E6CD8.4080107@oracle.com> References: <570E690B.2060703@oracle.com> <570E6CD8.4080107@oracle.com> Message-ID: <570E6F67.3030105@oracle.com> On 13/04/16 16:59, Alan Bateman wrote: > On 13/04/2016 16:43, Chris Hegarty wrote: >> This review is for the second significant part of the changes for JEP >> 260 [1]. When created, the jdk.unsupported module [2] initially >> contained the sun.misc package. This issue is will move all the >> non-Critical APIs out of sun.reflect, leaving only the critical ones, at >> which point sun.reflect can be moved to the jdk.unsupported module. >> >> http://cr.openjdk.java.net/~chegar/8137058/ >> https://bugs.openjdk.java.net/browse/JDK-8137058 >> > This looks good. A few comments: > > I assume the new sun.reflect.Reflection should have a private > constructor to prevent it being instantiated. D'oh! of course. Updated in-place. http://cr.openjdk.java.net/~chegar/8137058/jdk/src/jdk.unsupported/share/classes/sun/reflect/Reflection.java.html > You've probably thought > about this already but I assume the @Deprecated in > Reflection.getCallerClass should reference the supported API. If it is ok, I'd like to address that separately. I think there is probably more we can do there, and it probably deserves its own discussion. > The changes to InetAddress don't seem unrelated but good. They were sitting in my repo. Just some minor reformatting. -Chris. From gerard.ziemski at oracle.com Wed Apr 13 16:30:16 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 13 Apr 2016 11:30:16 -0500 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. In-Reply-To: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> References: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> Message-ID: hi Goetz, How about if we just change the MaxDirectMemorySize type to uint64_t, like so: http://cr.openjdk.java.net/~gziemski/8153835_rev1/ cheers > On Apr 13, 2016, at 8:25 AM, Lindenmaier, Goetz wrote: > > Hi, > > could someone please have a look at this tiny issue? And sponsor? > > Thanks, > Goetz. > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Freitag, 8. April 2016 10:53 >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is >> parsed at jlong. >> >> Hi, >> >> >> >> The upper limit of the range for flag MaxDirectMemorySize is MAX_SIZE_T. >> >> The flag is used to set a property that is parsed into a long. Thus, the max >> >> value on 64-bit platforms is too large. >> >> Fix: Limit the range to max_jlong, too. >> >> >> >> Please review this change. I please need a sponsor. >> >> http://cr.openjdk.java.net/~goetz/wr16/8153835-MaxDMSz/webrev.01/ >> >> >> >> Best regards, >> >> Goetz. >> >> >> >> > From mandy.chung at oracle.com Wed Apr 13 17:15:16 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Apr 2016 10:15:16 -0700 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <570E690B.2060703@oracle.com> References: <570E690B.2060703@oracle.com> Message-ID: <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> > On Apr 13, 2016, at 8:43 AM, Chris Hegarty wrote: > > This review is for the second significant part of the changes for JEP > 260 [1]. When created, the jdk.unsupported module [2] initially > contained the sun.misc package. This issue is will move all the > non-Critical APIs out of sun.reflect, leaving only the critical ones, at > which point sun.reflect can be moved to the jdk.unsupported module. > > http://cr.openjdk.java.net/~chegar/8137058/ > https://bugs.openjdk.java.net/browse/JDK-8137058 > > Summary of the changes: > > - Move all existing sun.reflect types to jdk.internal.reflect, and > fix up references in the libraries, and the VM, to use the new internal > location. I hope the getCallerClass(int depth) method is moved out of jdk.internal.reflect.Reflection. JDK is not using it and it?s retained for existing libraries to migrate to the new StackWalker API. Of course the cost is to add a native library and the build infra work has made this straight-forward. I agree with Alan that the @deprecated javadoc of sun.reflect.Reflection::getCallerClass should be updated to make it clear. What about: /** * @deprecated This method is an internal API and will be removed in JDK 10. * Use {@link StackWalker} to walk the stack and obtain the caller class * with {@link StackWalker.StackFrame#getDeclaringClass} instead. */ This patch will likely impact existing libraries that filter out reflection frames (IIRC Groovy and log4j may be examples) doing Class::getName().startsWith(?sun.reflect?). It may worth call out this incompatibility in JEP 260. StackStreamFactory.java shows an example: 1085 if (c.getName().startsWith("sun.reflect") && This should be changed to ?jdk.internal.reflect?. test/java/lang/StackWalker/EmbeddedStackWalkTest.java and maybe a few other stack walker tests. You may want to check any other of any similar pattern in the JDK code/tests (I think I got them all) The hotspot change drops the package name prefix in javaClasses.hpp which is inconsistent with other classes. I found including jdk_internal_reflect_ in the class name is useful. Coleen and others from the hotspot team may have opinion on this. FX will need to adjust for this patch (cc?ing Kevin to prepare for this) Mandy From chris.hegarty at oracle.com Wed Apr 13 17:28:00 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Apr 2016 18:28:00 +0100 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> References: <570E690B.2060703@oracle.com> <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> Message-ID: <570E81A0.5050904@oracle.com> Mandy, On 13/04/16 18:15, Mandy Chung wrote: > >> On Apr 13, 2016, at 8:43 AM, Chris Hegarty wrote: >> >> This review is for the second significant part of the changes for JEP >> 260 [1]. When created, the jdk.unsupported module [2] initially >> contained the sun.misc package. This issue is will move all the >> non-Critical APIs out of sun.reflect, leaving only the critical ones, at >> which point sun.reflect can be moved to the jdk.unsupported module. >> >> http://cr.openjdk.java.net/~chegar/8137058/ >> https://bugs.openjdk.java.net/browse/JDK-8137058 >> >> Summary of the changes: >> >> - Move all existing sun.reflect types to jdk.internal.reflect, and >> fix up references in the libraries, and the VM, to use the new internal >> location. > > I hope the getCallerClass(int depth) method is moved out of jdk.internal.reflect.Reflection. JDK is not using it and it?s retained for existing libraries to migrate to the new StackWalker API. Of course the cost is to add a native library and the build infra work has made this straight-forward. In my patch jdk.internal.reflect.Reflection.getCallerClass(int) is retained only to avoid the need for an unsupported.so, but if you feel strongly that is should go, then I can make the change. > I agree with Alan that the @deprecated javadoc of sun.reflect.Reflection::getCallerClass should be updated to make it clear. What about: > > /** > * @deprecated This method is an internal API and will be removed in JDK 10. > * Use {@link StackWalker} to walk the stack and obtain the caller class > * with {@link StackWalker.StackFrame#getDeclaringClass} instead. > */ That seems reasonable. The version number should be present in the @Deprecated forRemoval element too. I'll make the change. > This patch will likely impact existing libraries that filter out reflection frames (IIRC Groovy and log4j may be examples) doing Class::getName().startsWith(?sun.reflect?). It may worth call out this incompatibility in JEP 260. I'll add a note. > StackStreamFactory.java shows an example: > > 1085 if (c.getName().startsWith("sun.reflect") && > > This should be changed to ?jdk.internal.reflect?. Ah I missed this. Strangely all tests are passing without this change. I'll make the change. > test/java/lang/StackWalker/EmbeddedStackWalkTest.java and maybe a few other stack walker tests. You may want to check any other of any similar pattern in the JDK code/tests (I think I got them all) I did update some StackWalker tests, but missed this one ( it passes for me ). I'll check all of them. > The hotspot change drops the package name prefix in javaClasses.hpp which is inconsistent with other classes. I found including jdk_internal_reflect_ in the class name is useful. Coleen and others from the hotspot team may have opinion on this. Ok. > FX will need to adjust for this patch (cc?ing Kevin to prepare for this) Ah ok, thanks for copying Kevin. I'll send a note to the list once the webrev is updated. -Chris. From mandy.chung at oracle.com Wed Apr 13 17:43:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 13 Apr 2016 10:43:02 -0700 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <570E81A0.5050904@oracle.com> References: <570E690B.2060703@oracle.com> <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> <570E81A0.5050904@oracle.com> Message-ID: <0980D0EB-BAF1-4C76-9A82-D3F6BCCFA423@oracle.com> > On Apr 13, 2016, at 10:28 AM, Chris Hegarty wrote: > > Mandy, > > On 13/04/16 18:15, Mandy Chung wrote: >> >>> On Apr 13, 2016, at 8:43 AM, Chris Hegarty wrote: >>> >>> This review is for the second significant part of the changes for JEP >>> 260 [1]. When created, the jdk.unsupported module [2] initially >>> contained the sun.misc package. This issue is will move all the >>> non-Critical APIs out of sun.reflect, leaving only the critical ones, at >>> which point sun.reflect can be moved to the jdk.unsupported module. >>> >>> http://cr.openjdk.java.net/~chegar/8137058/ >>> https://bugs.openjdk.java.net/browse/JDK-8137058 >>> >>> Summary of the changes: >>> >>> - Move all existing sun.reflect types to jdk.internal.reflect, and >>> fix up references in the libraries, and the VM, to use the new internal >>> location. >> >> I hope the getCallerClass(int depth) method is moved out of jdk.internal.reflect.Reflection. JDK is not using it and it?s retained for existing libraries to migrate to the new StackWalker API. Of course the cost is to add a native library and the build infra work has made this straight-forward. > > In my patch jdk.internal.reflect.Reflection.getCallerClass(int) > is retained only to avoid the need for an unsupported.so, but > if you feel strongly that is should go, then I can make the > change. I?m less concerned of a native library but its name led me to have a second thought. I can leave with keeping jdk.internal.reflect.Reflection::getCallerClass(int depth) for another reason. > >> I agree with Alan that the @deprecated javadoc of sun.reflect.Reflection::getCallerClass should be updated to make it clear. What about: >> >> /** >> * @deprecated This method is an internal API and will be removed in JDK 10. >> * Use {@link StackWalker} to walk the stack and obtain the caller class >> * with {@link StackWalker.StackFrame#getDeclaringClass} instead. >> */ > > That seems reasonable. The version number should be present > in the @Deprecated forRemoval element too. I'll make the change. Thanks. > >> This patch will likely impact existing libraries that filter out reflection frames (IIRC Groovy and log4j may be examples) doing Class::getName().startsWith(?sun.reflect?). It may worth call out this incompatibility in JEP 260. > > I'll add a note. > >> StackStreamFactory.java shows an example: >> >> 1085 if (c.getName().startsWith("sun.reflect") && >> >> This should be changed to ?jdk.internal.reflect?. > > Ah I missed this. Strangely all tests are passing without > this change. I'll make the change. This is just like an assertion that should never reach there. It throws an internal error if a class starts with sun.reflect but not a reflective method. > >> test/java/lang/StackWalker/EmbeddedStackWalkTest.java and maybe a few other stack walker tests. You may want to check any other of any similar pattern in the JDK code/tests (I think I got them all) > > I did update some StackWalker tests, but missed this one ( it > passes for me ). I'll check all of them. It may be a check with several conditions or assertion like the above. Mandy From coleen.phillimore at oracle.com Wed Apr 13 19:03:39 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 13 Apr 2016 15:03:39 -0400 Subject: RFR: 8152845: Improve PackageEntry and ModuleEntry print methods for future logging In-Reply-To: <570E5E41.3020005@oracle.com> References: <570D088D.6090504@oracle.com> <570D698E.6030201@oracle.com> <570E5E41.3020005@oracle.com> Message-ID: <570E980B.6000100@oracle.com> On 4/13/16 10:57 AM, Rachel Protacio wrote: > On 4/12/2016 5:33 PM, Coleen Phillimore wrote: >> >> But in these functions, the print is going to print to tty rather >> than to the outputStream* st: >> >> +void ModuleEntryTable::print(outputStream* st) { >> + st->print_cr("Module Entry Table (table_size=%d, entries=%d)", >> table_size(), number_of_entries()); >> for (int i = 0; i < table_size(); i++) { >> for (ModuleEntry* probe = bucket(i); >> probe != NULL; >> probe = probe->next()) { >> probe->print(); >> } >> } >> } >> > I missed the print() at the end, thanks for noticing! New webrev: > http://cr.openjdk.java.net/~rprotacio/8152845.01/ > >> Which functions weren't declared as const? >> > table_size() and number_of_entries() from hashtable.hpp both aren't > const. And neither is ModuleEntryTable::bucket(). Ok. Someone should fix these non-const functions in hashtable.hpp some time. Reviewed! Coleen > > Rachel >> Coleen >> >> >> On 4/12/16 10:39 AM, Rachel Protacio wrote: >>> Hello, >>> >>> Please review this fix, moving the jigsaw PackageEntry and >>> ModuleEntry print methods to product mode and making them able to >>> take an outputStream. This way, we can use them for Unified Logging >>> in the future. >>> >>> Note: I changed the signature to take an optional stream rather than >>> following the "print_on" scheme because the print_on function that >>> these classes inherit is declared as 'const', which is incompatible >>> with the non-const function calls within the print function. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152845 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152845.00/ >>> >>> Tested with JPRT and RBT quick and non-colo tests. >>> >>> Thanks, >>> Rachel >> > From rachel.protacio at oracle.com Wed Apr 13 19:10:26 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Wed, 13 Apr 2016 15:10:26 -0400 Subject: RFR: 8152845: Improve PackageEntry and ModuleEntry print methods for future logging In-Reply-To: <570E980B.6000100@oracle.com> References: <570D088D.6090504@oracle.com> <570D698E.6030201@oracle.com> <570E5E41.3020005@oracle.com> <570E980B.6000100@oracle.com> Message-ID: <570E99A2.1000204@oracle.com> Thanks, Coleen! Rachel On 4/13/2016 3:03 PM, Coleen Phillimore wrote: > > > On 4/13/16 10:57 AM, Rachel Protacio wrote: >> On 4/12/2016 5:33 PM, Coleen Phillimore wrote: >>> >>> But in these functions, the print is going to print to tty rather >>> than to the outputStream* st: >>> >>> +void ModuleEntryTable::print(outputStream* st) { >>> + st->print_cr("Module Entry Table (table_size=%d, entries=%d)", >>> table_size(), number_of_entries()); >>> for (int i = 0; i < table_size(); i++) { >>> for (ModuleEntry* probe = bucket(i); >>> probe != NULL; >>> probe = probe->next()) { >>> probe->print(); >>> } >>> } >>> } >>> >> I missed the print() at the end, thanks for noticing! New webrev: >> http://cr.openjdk.java.net/~rprotacio/8152845.01/ >> >>> Which functions weren't declared as const? >>> >> table_size() and number_of_entries() from hashtable.hpp both aren't >> const. And neither is ModuleEntryTable::bucket(). > > Ok. Someone should fix these non-const functions in hashtable.hpp > some time. > > Reviewed! > Coleen > >> >> Rachel >>> Coleen >>> >>> >>> On 4/12/16 10:39 AM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review this fix, moving the jigsaw PackageEntry and >>>> ModuleEntry print methods to product mode and making them able to >>>> take an outputStream. This way, we can use them for Unified Logging >>>> in the future. >>>> >>>> Note: I changed the signature to take an optional stream rather >>>> than following the "print_on" scheme because the print_on function >>>> that these classes inherit is declared as 'const', which is >>>> incompatible with the non-const function calls within the print >>>> function. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152845 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152845.00/ >>>> >>>> Tested with JPRT and RBT quick and non-colo tests. >>>> >>>> Thanks, >>>> Rachel >>> >> > From max.ockner at oracle.com Wed Apr 13 19:33:08 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 13 Apr 2016 15:33:08 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570D309B.5010109@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> Message-ID: <570E9EF4.6000406@oracle.com> Hello, I have made these changes. - refactored describe into a portion which uses locking and one that does not. - in the print_vm_info function in vmError.cpp, describe() is used, since this function is called while the program is running. - in the report function, the describe_no_lock and describe_with_lock functions are both used without taking a lock. If it doesnt crash, then fantastic. If it does crash, the error handler will skip this step anyway. webrev: http://cr.openjdk.java.net/~mockner/8151526.04 Thanks, Max On 4/12/2016 1:30 PM, Marcus Larsson wrote: > Hey, > > On 2016-04-12 17:01, Max Ockner wrote: >> Marcus, >> >> I just spoke with Coleen about this. If I attempt to print >> configuration during a crash without lock and it crashes, the error >> handler will eat it up and start at the next step. It would be fun >> to write a locking mechanism, but this seems better to me. >> >> I will continue to call describe() from VM.info, but I will refactor >> the code in describe so that all of the information can be printed >> easily without taking a lock. For a crash, I'll use the refactored >> print functions to print all the necessary information without taking >> a lock. Even if the vm crashes during this step it is not such a bad >> thing because of the robust error handler. > > Alright, that sounds good! > > Thanks, > Marcus > >> >> >> Thanks, >> Max >> >> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>> Hi Max, >>> >>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>> Hello again, >>>> >>>> I have looked into this and I see a possible workaround to the >>>> issue raised by Marcus: >>>> >>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>> might be problematic for the error handler. I suppose the error >>>> handler could potentially deadlock if its thread already holds >>>> the lock. Unsure how to resolve this, because skipping to take >>>> the lock means that we might crash due to another thread >>>> changing the configuration as we read it. >>>> >>>> >>>> My proposed solution is this: >>>> >>>> If the ConfigurationLock is held by another thread during the >>>> crash, then I think we could print "Log configuration can not be >>>> accessed because ConfigurationLock is currently held by another >>>> thread" or something similar. If the ConfigurationLock can be >>>> taken by the current thread, then print the configuration. >>>> >>>> We can accomplish this as follows: >>>> >>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class >>>> extending ConfigurationLock. >>>> >>>> class ConfigurationLockMaybe : ConfigurationLock { >>>> private: >>>> bool _success; >>>> public: >>>> ConfigurationLockMaybe() { >>>> if (_semaphore.trywait()){_success = true;} >>>> } >>>> ~ConfigurationLock() { >>>> if(_success){_semaphore.signal();} >>>> } >>>> bool has_lock(){return _success;} >>>> }; >>>> >>>> _semaphore is a static var in ConfigurationLock, so the same copy >>>> is accessed in child classes. >>>> >>>> Another method LogConfiguration::describe_on_crash(outputStream* >>>> out) can use ConfigurationLockMaybe to attempt to print the >>>> configuration. >>>> >>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>> LogConfiguration::describe_on_crash. >>> >>> Sounds good to me. >>> >>> ConfigurationLockMaybe sounds a bit weird but I don't have a better >>> suggestion. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> Max >>>> >>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>> I missed this before. I'm going to investigate. >>>>> Max >>>>> >>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>> >>>>>> >>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>> > wrote: >>>>>>> >>>>>>> I forgot to respond to this: >>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>> (Replies in line) >>>>>>>>> >>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>> >>>>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>>>> >>>>>>>>> Just going by what we currently put in the hs_err file, I >>>>>>>>> think >>>>>>>>> this may be the first "Do we really need" we've ever asked >>>>>>>>> for >>>>>>>>> this type of change. >>>>>>>>> >>>>>>>>> All joking aside, I think it is a good idea to direct users >>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>> >>>>>>>>>> Also: I assume what you print is the Log state as it is >>>>>>>>>> at the >>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>> >>>>>>>>> Would it be possible? Yes, but I think this would require a >>>>>>>>> framework change. It does not look like any marks are made >>>>>>>>> when >>>>>>>>> the LogConfiguration changes during runtime, and we would >>>>>>>>> need >>>>>>>>> to record that in order to know what to print when we dump >>>>>>>>> into >>>>>>>>> hs_err. >>>>>>>> >>>>>>>> Yes, this would required the framework to keep some sort of >>>>>>>> log >>>>>>>> of configuration changes. Is there value in knowing that >>>>>>>> the log >>>>>>>> configuration changed since startup? >>>>>>> >>>>>>> I think it is useful along with other information. An >>>>>>> example case: >>>>>>> >>>>>>> Let's say we are logging a message whenever a lock is >>>>>>> acquired or >>>>>>> released. In a subsystem like this, the action which dooms >>>>>>> the vm >>>>>>> may not cause an immediate crash. This leaves time for >>>>>>> logging to >>>>>>> turn on or off in between the bad action and the crash. If you >>>>>>> don't know when logging was active and when it was not, then >>>>>>> the >>>>>>> absence of a particular message does not give you much >>>>>>> information. You may not see the message that has the answer >>>>>>> for >>>>>>> you because it was not logged, though the action may have >>>>>>> occurred. >>>>>>> >>>>>>> However, if we don't have the framework support for this then I >>>>>>> believe it should be added later. >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is a good example. A small easy solution, as I mentioned >>>>>>> before, could be just to distinguish between "logging parameters >>>>>>> stable since startup" and "logging parameters changed at some >>>>>>> time". That way you would at least know whether to trust the >>>>>>> logging output. >>>>>>> >>>>>>> But you are right, this can be added later. >>>>>> >>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for >>>>>> this. >>>>>> >>>>>> Max: Did you see my comments about the ConfigurationLock? It was >>>>>> an inline reply to your first mail. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> Kind Regards, Thomas >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>>> Kind Regards, Thomas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>> > >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> Please review another Unified Logging change. They are >>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>> which >>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>> error >>>>>>>> handler could potentially deadlock if its thread already holds >>>>>>>> the lock. Unsure how to resolve this, because skipping to take >>>>>>>> the lock means that we might crash due to another thread >>>>>>>> changing the configuration as we read it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>>>> >>>>>>>>>> The logging configuration is now printed in each hs_err >>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>> >>>>>>>>>> Below is a sample of the hs_err contents. The Logging >>>>>>>>>> info >>>>>>>>>> is printed after VM Arguments and Whitebox, and before >>>>>>>>>> Environment Variables. >>>>>>>>>> >>>>>>>>>> VM Arguments: >>>>>>>>>> java_command: Kaboom >>>>>>>>>> java_class_path (initial): . >>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>> >>>>>>>>>> Logging: >>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>> warning, error >>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>> timemillis >>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), uptimenanos >>>>>>>>>> (un), >>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>>>>>>> Available log tags: alloc, age, barrier, biasedlocking, >>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, exceptions, >>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, itables, jni, >>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>> monitorinflation, os, phases, plab, promotion, preorder, >>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>> safepoint, >>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>> Log output configuration: >>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>> >>>>>>>>>> Environment Variables: >>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>> >>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>> >>>>>>>>>> SHELL=/bin/bash >>>>>>>>>> OS=Linux >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From calvin.cheung at oracle.com Wed Apr 13 20:03:56 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 13 Apr 2016 13:03:56 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> Message-ID: <570EA62C.4080605@oracle.com> Hi Ioi, Just a few minor comments. No need to see another webrev. compactHashtable.cpp: 71 _num_entries ++; extra space before ++ similarly in lines 80, 112, 123, 125 118 Entry tent = bucket->at(i); It is clearer if 'tent' is just 'ent' since the code in this block is not dealing with tiny entry. 249 while (entry Ioi, > >> On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: >> >> Hi Jiangli, >> >> >> Thanks for the review: >> >> On 4/11/16 6:44 PM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>> I like the more structural way of reading/writing the compact table with SimpleCompactHashtable. It looks quite clean overall. >>> >>> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive than TINY_BUCKET_TYPE? >>> >> OK, I will make the change. >> >>> - The following assert in CompactSymbolTableWriter::add() limits the total shared space size to be less than MAX_SHARED_DELTA unnecessarily. Symbols are allocated from the RO space at dump time. We only need to make sure the max delta between the ?base_address? and the end of RO space is less than MAX_SHARED_DELTA. This is not a new issue introduced by your change, you don?t have to address that as part of this change if you prefer. I?ll file a separate RFE. >>> >> I think it's better to do this in a separate RFE since MAX_SHARED_DELTA is used elsewhere as well. > I filed JDK-8154108. > >>> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol *symbol) { >>> 172 address base_address = address(MetaspaceShared::shared_rs()->base()); >>> 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); >>> 174 assert(max_delta<= MAX_SHARED_DELTA, "range check"); >>> >>> - Why is the default RO space size increased? >>> >> That's because the symbol table is moved from RW to RO, so I had to change the RO minimum size, or else test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. > Ok. > > Thanks, > Jiangli > >>> - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >>> - src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >>> Copyright year. >> Will fix. >> >> Thanks >> - Ioi >>> Thanks, >>> Jiangli >>> >>>> On Mar 31, 2016, at 10:43 PM, Ioi Lam> wrote: >>>> >>>> Please review >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>>> >>>> Bug: Clean up CompactHashtable >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>>> >>>> Summary of fix: >>>> >>>> [1] Instead of reading/writing the table bit-by-bit, which is tedious and >>>> error prone, use SimpleCompactHashtable::serialize(), which is more >>>> structural. >>>> >>>> [2] Split up the _buckets and _entries into two separate arrays, so the >>>> dumping and walking code is easier to understand >>>> >>>> (see comments above SimpleCompactHashtable declaration) >>>> These 2 arrays are now allocated from the RO region (used to be in RW) >>>> >>>> [3] Renamed a few things >>>> >>>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>>> (having something called "compact" in CompactHashtable is confusing) >>>> >>>> The old names "dump_table" (actually dumping the buckets) and >>>> "dump_buckets" (actually dumping the entries) were conflicting with >>>> terminology used elsewhere. Now the terminology is unified: >>>> "buckets" = the main index, "entries" = the second level. >>>> >>>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>>> >>>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>>> checked with assert. >>>> >>>> [5] Replaced all juint to u4 (suggested by Coleen) >>>> >>>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>>> SimpleCompactHashtable::iterate) >>>> >>>> [7] I also added a test case using Serviceability Agent -- due to the lack of >>>> a regression test, the walking of the compact hashtable in SA had been >>>> broken for a while before it was fixed in JDK-8151368, so having a test >>>> case would make the code more maintainable. >>>> >>>> Tests: >>>> >>>> Hotspot JTREG tests >>>> >>>> Thanks >>>> - Ioi From chris.hegarty at oracle.com Wed Apr 13 21:36:02 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Apr 2016 22:36:02 +0100 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: References: <570E690B.2060703@oracle.com> <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> <570E81A0.5050904@oracle.com> <0980D0EB-BAF1-4C76-9A82-D3F6BCCFA423@oracle.com> Message-ID: > On 13 Apr 2016, at 19:03, Paul Benedict wrote: > > Since getCallerClass will be removed in 10, @Deprecated should also have its condemned=true `condemned` was renamed to `forRemoval` [1]. getCallerClass, in fact the whole class, will have `forRemoval=true`. -Chris. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-April/003932.html > > Cheers, > Paul > > On Wed, Apr 13, 2016 at 12:43 PM, Mandy Chung > wrote: > > > On Apr 13, 2016, at 10:28 AM, Chris Hegarty > wrote: > > > > Mandy, > > > > On 13/04/16 18:15, Mandy Chung wrote: > >> > >>> On Apr 13, 2016, at 8:43 AM, Chris Hegarty > wrote: > >>> > >>> This review is for the second significant part of the changes for JEP > >>> 260 [1]. When created, the jdk.unsupported module [2] initially > >>> contained the sun.misc package. This issue is will move all the > >>> non-Critical APIs out of sun.reflect, leaving only the critical ones, at > >>> which point sun.reflect can be moved to the jdk.unsupported module. > >>> > >>> http://cr.openjdk.java.net/~chegar/8137058/ > >>> https://bugs.openjdk.java.net/browse/JDK-8137058 > >>> > >>> Summary of the changes: > >>> > >>> - Move all existing sun.reflect types to jdk.internal.reflect, and > >>> fix up references in the libraries, and the VM, to use the new internal > >>> location. > >> > >> I hope the getCallerClass(int depth) method is moved out of jdk.internal.reflect.Reflection. JDK is not using it and it?s retained for existing libraries to migrate to the new StackWalker API. Of course the cost is to add a native library and the build infra work has made this straight-forward. > > > > In my patch jdk.internal.reflect.Reflection.getCallerClass(int) > > is retained only to avoid the need for an unsupported.so, but > > if you feel strongly that is should go, then I can make the > > change. > > I?m less concerned of a native library but its name led me to have a second thought. I can leave with keeping jdk.internal.reflect.Reflection::getCallerClass(int depth) for another reason. > > > > >> I agree with Alan that the @deprecated javadoc of sun.reflect.Reflection::getCallerClass should be updated to make it clear. What about: > >> > >> /** > >> * @deprecated This method is an internal API and will be removed in JDK 10. > >> * Use {@link StackWalker} to walk the stack and obtain the caller class > >> * with {@link StackWalker.StackFrame#getDeclaringClass} instead. > >> */ > > > > That seems reasonable. The version number should be present > > in the @Deprecated forRemoval element too. I'll make the change. > > Thanks. > > > > >> This patch will likely impact existing libraries that filter out reflection frames (IIRC Groovy and log4j may be examples) doing Class::getName().startsWith(?sun.reflect?). It may worth call out this incompatibility in JEP 260. > > > > I'll add a note. > > > >> StackStreamFactory.java shows an example: > >> > >> 1085 if (c.getName().startsWith("sun.reflect") && > >> > >> This should be changed to ?jdk.internal.reflect?. > > > > Ah I missed this. Strangely all tests are passing without > > this change. I'll make the change. > > This is just like an assertion that should never reach there. It throws an internal error if a class starts with sun.reflect but not a reflective method. > > > > >> test/java/lang/StackWalker/EmbeddedStackWalkTest.java and maybe a few other stack walker tests. You may want to check any other of any similar pattern in the JDK code/tests (I think I got them all) > > > > I did update some StackWalker tests, but missed this one ( it > > passes for me ). I'll check all of them. > > It may be a check with several conditions or assertion like the above. > > Mandy > From david.holmes at oracle.com Thu Apr 14 00:34:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Apr 2016 10:34:23 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570E65B6.2010809@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> Message-ID: <570EE58F.4060809@oracle.com> Hi, On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: > Hi David, > > Thanks for your comment. > > I exported new JVM function to set native thread name, and JLI uses it > in new webrev. First the launcher belongs to another team so core-libs will need to review and approve this (in particular Kumar) - now cc'd. Personally I would have used a Java upcall to Thread.setName rather than exporting JVM_SetNativeThreadName. No hotspot changes needed in that case. Thanks, David > Could you review again? > > - hotspot: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ > > - jdk: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ > > > Thanks, > > Yasumasa > > > On 2016/04/13 22:00, David Holmes wrote: >> I'll answer on this original thread as well ... >> >> Hi Yasumasa, >> >> Please see my updates to the bug (sorry have been on vacation). This >> needs to be done in the launcher to be correct as we do not set the >> name of threads that attach via JNI, which includes the "main" thread. >> >> David >> >> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>> Thanks Robbin, >>> >>> I'm waiting a sponsor and more reviewer :-) >>> >>> Yasumasa >>> 2016/03/31 5:58 "Robbin Ehn" : >>> >>>> FYI: I'm not a Reviewer. >>>> >>>> /Robbin >>>> >>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>> >>>>> Thanks, looks good. >>>>> >>>>> /Robbin >>>>> >>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I uploaded new webrev. >>>>>> Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>>> Hi Robbin, >>>>>>>> >>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>> >: >>>>>>>> > >>>>>>>> > Hi Yasumasa, >>>>>>>> > >>>>>>>> > >>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>> >> >>>>>>>> >> Hi Robbin, >>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>> >>>>>>>> >> >>>>>>> >>: >>>>>>>> >> >>>>>>>> >> > >>>>>>>> >> > Hi Yasumasa, >>>>>>>> >> > >>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>> >> > >>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>> 13:09:16 2016 >>>>>>>> +0000 >>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>> 17:40:09 2016 >>>>>>>> +0100 >>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>> >> > // must do this before set_active_handles >>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>> >> > >>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>> >> > >>>>>>>> >> > here instead? Am I missing something? >>>>>>>> >> >>>>>>>> >> Native thread name is the same to thread name in Thread class. >>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>> will be >>>>>>>> set at >>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>>>> >> I think that the place of setting thrrad name should be the >>>>>>>> same. >>>>>>>> > >>>>>>>> > >>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>> nicer, no? >>>>>>>> > >>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 >>>>>>>> 2016 >>>>>>>> +0200 >>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 >>>>>>>> 2016 >>>>>>>> +0200 >>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>> > // Creates the initial Thread >>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>> JavaThread* >>>>>>>> thread, >>>>>>>> > TRAPS) { >>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>> > Klass* k = >>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>> true, >>>>>>>> CHECK_NULL); >>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>> > instanceHandle thread_oop = >>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>> > - >>>>>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>>>>> CHECK_NULL); >>>>>>>> > + >>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>> > + >>>>>>>> > + Handle string = >>>>>>>> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >>>>>>>> > >>>>>>>> > JavaValue result(T_VOID); >>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>> >>>>>>>> Okay, I will upload new webrev later. >>>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>>> >> > The launcher seem to name itself 'java' and naming this >>>>>>>> thread >>>>>>>> just >>>>>>>> >> > 'main' is confusing to me. >>>>>>>> >> > >>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>> process) is >>>>>>>> 'java' but >>>>>>>> >> > first JavaThread is 'main'. >>>>>>>> >> >>>>>>>> >> The native main thread in the process is not JavaThread. It is >>>>>>>> waiting >>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>> >> set_native_thread_name() is for JavaThread. So I think that >>>>>>>> we do >>>>>>>> not >>>>>>>> >> need to call it for native main thread. >>>>>>>> > >>>>>>>> > >>>>>>>> > Not sure if we can change it anyhow, since we want java and >>>>>>>> native >>>>>>>> name to be the same and java thread name might have some >>>>>>>> dependents. >>>>>>>> > >>>>>>>> > The name is visible in e.g. /proc. >>>>>>>> > >>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>> > PID TID COMMAND >>>>>>>> > 6423 6423 java >>>>>>>> > 6423 6424 main >>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>> > >>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>> >>>>>>>> I do not think so. >>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>> commons-daemon, JNI application, etc. >>>>>>>> >>>>>>>> If you want to change native main thread name, I think that we >>>>>>>> have to >>>>>>>> change Java launcher code. >>>>>>>> Should I include it in new webrev? >>>>>>>> >>>>>>> >>>>>>> No >>>>>>> >>>>>>> Thanks again! >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> > Thanks >>>>>>>> > >>>>>>>> > /Robbin >>>>>>>> > >>>>>>>> > >>>>>>>> >> >>>>>>>> >> Thanks, >>>>>>>> >> >>>>>>>> >> Yasumasa >>>>>>>> >> >>>>>>>> >> > Thanks! >>>>>>>> >> > >>>>>>>> >> > /Robbin >>>>>>>> >> > >>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>> >> > > Hi all, >>>>>>>> >> > > >>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>> pthread_setname_np(). >>>>>>>> >> > > However, main thread does not have it. >>>>>>>> >> > > >>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>> JavaThread. >>>>>>>> >> > > For consistency, main thread should have native thread >>>>>>>> name. >>>>>>>> >> > > >>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>> >> > > >>>>>>>> >> > > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>> >> > > >>>>>>>> >> > > I cannot access JPRT. >>>>>>>> >> > > So I need a sponsor. >>>>>>>> >> > > >>>>>>>> >> > > >>>>>>>> >> > > Thanks, >>>>>>>> >> > > >>>>>>>> >> > > Yasumasa >>>>>>>> >> > > >>>>>>>> >> >>>>>>>> >>>>>>>> From yasuenag at gmail.com Thu Apr 14 03:52:03 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 14 Apr 2016 12:52:03 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570EE58F.4060809@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> Message-ID: <570F13E3.6000802@gmail.com> Hi, On 2016/04/14 9:34, David Holmes wrote: > Hi, > > On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >> Hi David, >> >> Thanks for your comment. >> >> I exported new JVM function to set native thread name, and JLI uses it >> in new webrev. > > First the launcher belongs to another team so core-libs will need to review and approve this (in particular Kumar) - now cc'd. Thanks! I'm waiting to review :-) > Personally I would have used a Java upcall to Thread.setName rather than exporting JVM_SetNativeThreadName. No hotspot changes needed in that case. As I wrote [1] in JBS, I changed to use Thread#setName() in Thread#init(), but I could not change native thread name. I guess that caller of main() is JNI attached thread. Thus I think that we have to provide a function to set native thread name. Thanks, Yasumasa [1] https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 > Thanks, > David > >> Could you review again? >> >> - hotspot: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >> >> - jdk: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/13 22:00, David Holmes wrote: >>> I'll answer on this original thread as well ... >>> >>> Hi Yasumasa, >>> >>> Please see my updates to the bug (sorry have been on vacation). This >>> needs to be done in the launcher to be correct as we do not set the >>> name of threads that attach via JNI, which includes the "main" thread. >>> >>> David >>> >>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>> Thanks Robbin, >>>> >>>> I'm waiting a sponsor and more reviewer :-) >>>> >>>> Yasumasa >>>> 2016/03/31 5:58 "Robbin Ehn" : >>>> >>>>> FYI: I'm not a Reviewer. >>>>> >>>>> /Robbin >>>>> >>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>> >>>>>> Thanks, looks good. >>>>>> >>>>>> /Robbin >>>>>> >>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I uploaded new webrev. >>>>>>> Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>>> Hi Robbin, >>>>>>>>> >>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>> >: >>>>>>>>> > >>>>>>>>> > Hi Yasumasa, >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>> >> >>>>>>>>> >> Hi Robbin, >>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>> >>>>>>>>> >> >>>>>>>> >>: >>>>>>>>> >> >>>>>>>>> >> > >>>>>>>>> >> > Hi Yasumasa, >>>>>>>>> >> > >>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>> >> > >>>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>> 13:09:16 2016 >>>>>>>>> +0000 >>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>> 17:40:09 2016 >>>>>>>>> +0100 >>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>> >> > >>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>> >> > >>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>> >> >>>>>>>>> >> Native thread name is the same to thread name in Thread class. >>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>>> will be >>>>>>>>> set at >>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>>>>> >> I think that the place of setting thrrad name should be the >>>>>>>>> same. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>> nicer, no? >>>>>>>>> > >>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 >>>>>>>>> 2016 >>>>>>>>> +0200 >>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 >>>>>>>>> 2016 >>>>>>>>> +0200 >>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>> > // Creates the initial Thread >>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>> JavaThread* >>>>>>>>> thread, >>>>>>>>> > TRAPS) { >>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>> > Klass* k = >>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>> true, >>>>>>>>> CHECK_NULL); >>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>> > instanceHandle thread_oop = >>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), NormPriority); >>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>> > - >>>>>>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>>>>>> CHECK_NULL); >>>>>>>>> > + >>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>> > + >>>>>>>>> > + Handle string = >>>>>>>>> java_lang_String::create_from_str(initial_thread_name, CHECK_NULL); >>>>>>>>> > >>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>> >>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>> >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>>> >> > The launcher seem to name itself 'java' and naming this >>>>>>>>> thread >>>>>>>>> just >>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>> >> > >>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>> process) is >>>>>>>>> 'java' but >>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>> >> >>>>>>>>> >> The native main thread in the process is not JavaThread. It is >>>>>>>>> waiting >>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>> >> set_native_thread_name() is for JavaThread. So I think that >>>>>>>>> we do >>>>>>>>> not >>>>>>>>> >> need to call it for native main thread. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Not sure if we can change it anyhow, since we want java and >>>>>>>>> native >>>>>>>>> name to be the same and java thread name might have some >>>>>>>>> dependents. >>>>>>>>> > >>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>> > >>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>> > PID TID COMMAND >>>>>>>>> > 6423 6423 java >>>>>>>>> > 6423 6424 main >>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>> > >>>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>>> >>>>>>>>> I do not think so. >>>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>> >>>>>>>>> If you want to change native main thread name, I think that we >>>>>>>>> have to >>>>>>>>> change Java launcher code. >>>>>>>>> Should I include it in new webrev? >>>>>>>>> >>>>>>>> >>>>>>>> No >>>>>>>> >>>>>>>> Thanks again! >>>>>>>> >>>>>>>> /Robbin >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> > Thanks >>>>>>>>> > >>>>>>>>> > /Robbin >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >> >>>>>>>>> >> Thanks, >>>>>>>>> >> >>>>>>>>> >> Yasumasa >>>>>>>>> >> >>>>>>>>> >> > Thanks! >>>>>>>>> >> > >>>>>>>>> >> > /Robbin >>>>>>>>> >> > >>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>> >> > > Hi all, >>>>>>>>> >> > > >>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>> pthread_setname_np(). >>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>> >> > > >>>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>>> JavaThread. >>>>>>>>> >> > > For consistency, main thread should have native thread >>>>>>>>> name. >>>>>>>>> >> > > >>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>> >> > > >>>>>>>>> >> > > >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>> >> > > >>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>> >> > > So I need a sponsor. >>>>>>>>> >> > > >>>>>>>>> >> > > >>>>>>>>> >> > > Thanks, >>>>>>>>> >> > > >>>>>>>>> >> > > Yasumasa >>>>>>>>> >> > > >>>>>>>>> >> >>>>>>>>> >>>>>>>>> From marcus.larsson at oracle.com Thu Apr 14 08:30:12 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 14 Apr 2016 10:30:12 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570E9EF4.6000406@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> Message-ID: <570F5514.9040805@oracle.com> Hi, On 04/13/2016 09:33 PM, Max Ockner wrote: > Hello, > I have made these changes. > - refactored describe into a portion which uses locking and one that > does not. > - in the print_vm_info function in vmError.cpp, describe() is used, > since this function is called while the program is running. > - in the report function, the describe_no_lock and describe_with_lock > functions are both used without taking a lock. If it doesnt crash, > then fantastic. If it does crash, the error handler will skip this > step anyway. > > webrev: http://cr.openjdk.java.net/~mockner/8151526.04 I suggest making the new two functions private in LogConfiguration, and friending VMError, instead of keeping them public. That should reduce confusion about which describe-method to use, and prevent misuse of the describe_with_lock in other places. Otherwise this looks good. Thanks, Marcus > > Thanks, > Max > > On 4/12/2016 1:30 PM, Marcus Larsson wrote: >> Hey, >> >> On 2016-04-12 17:01, Max Ockner wrote: >>> Marcus, >>> >>> I just spoke with Coleen about this. If I attempt to print >>> configuration during a crash without lock and it crashes, the error >>> handler will eat it up and start at the next step. It would be fun >>> to write a locking mechanism, but this seems better to me. >>> >>> I will continue to call describe() from VM.info, but I will refactor >>> the code in describe so that all of the information can be printed >>> easily without taking a lock. For a crash, I'll use the refactored >>> print functions to print all the necessary information without >>> taking a lock. Even if the vm crashes during this step it is not >>> such a bad thing because of the robust error handler. >> >> Alright, that sounds good! >> >> Thanks, >> Marcus >> >>> >>> >>> Thanks, >>> Max >>> >>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>> Hi Max, >>>> >>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>> Hello again, >>>>> >>>>> I have looked into this and I see a possible workaround to the >>>>> issue raised by Marcus: >>>>> >>>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>>> might be problematic for the error handler. I suppose the error >>>>> handler could potentially deadlock if its thread already holds >>>>> the lock. Unsure how to resolve this, because skipping to take >>>>> the lock means that we might crash due to another thread >>>>> changing the configuration as we read it. >>>>> >>>>> >>>>> My proposed solution is this: >>>>> >>>>> If the ConfigurationLock is held by another thread during the >>>>> crash, then I think we could print "Log configuration can not be >>>>> accessed because ConfigurationLock is currently held by another >>>>> thread" or something similar. If the ConfigurationLock can be >>>>> taken by the current thread, then print the configuration. >>>>> >>>>> We can accomplish this as follows: >>>>> >>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class >>>>> extending ConfigurationLock. >>>>> >>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>> private: >>>>> bool _success; >>>>> public: >>>>> ConfigurationLockMaybe() { >>>>> if (_semaphore.trywait()){_success = true;} >>>>> } >>>>> ~ConfigurationLock() { >>>>> if(_success){_semaphore.signal();} >>>>> } >>>>> bool has_lock(){return _success;} >>>>> }; >>>>> >>>>> _semaphore is a static var in ConfigurationLock, so the same copy >>>>> is accessed in child classes. >>>>> >>>>> Another method LogConfiguration::describe_on_crash(outputStream* >>>>> out) can use ConfigurationLockMaybe to attempt to print the >>>>> configuration. >>>>> >>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>> LogConfiguration::describe_on_crash. >>>> >>>> Sounds good to me. >>>> >>>> ConfigurationLockMaybe sounds a bit weird but I don't have a better >>>> suggestion. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> Max >>>>> >>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>> I missed this before. I'm going to investigate. >>>>>> Max >>>>>> >>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>> >>>>>>> >>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>> > wrote: >>>>>>>> >>>>>>>> I forgot to respond to this: >>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>> (Replies in line) >>>>>>>>>> >>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>> >>>>>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>>>>> >>>>>>>>>> Just going by what we currently put in the hs_err file, I >>>>>>>>>> think >>>>>>>>>> this may be the first "Do we really need" we've ever >>>>>>>>>> asked for >>>>>>>>>> this type of change. >>>>>>>>>> >>>>>>>>>> All joking aside, I think it is a good idea to direct users >>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>> >>>>>>>>>>> Also: I assume what you print is the Log state as it is >>>>>>>>>>> at the >>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>> >>>>>>>>>> Would it be possible? Yes, but I think this would require a >>>>>>>>>> framework change. It does not look like any marks are >>>>>>>>>> made when >>>>>>>>>> the LogConfiguration changes during runtime, and we would >>>>>>>>>> need >>>>>>>>>> to record that in order to know what to print when we >>>>>>>>>> dump into >>>>>>>>>> hs_err. >>>>>>>>> >>>>>>>>> Yes, this would required the framework to keep some sort >>>>>>>>> of log >>>>>>>>> of configuration changes. Is there value in knowing that >>>>>>>>> the log >>>>>>>>> configuration changed since startup? >>>>>>>> >>>>>>>> I think it is useful along with other information. An >>>>>>>> example case: >>>>>>>> >>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>> acquired or >>>>>>>> released. In a subsystem like this, the action which dooms >>>>>>>> the vm >>>>>>>> may not cause an immediate crash. This leaves time for >>>>>>>> logging to >>>>>>>> turn on or off in between the bad action and the crash. If you >>>>>>>> don't know when logging was active and when it was not, >>>>>>>> then the >>>>>>>> absence of a particular message does not give you much >>>>>>>> information. You may not see the message that has the >>>>>>>> answer for >>>>>>>> you because it was not logged, though the action may have >>>>>>>> occurred. >>>>>>>> >>>>>>>> However, if we don't have the framework support for this >>>>>>>> then I >>>>>>>> believe it should be added later. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This is a good example. A small easy solution, as I mentioned >>>>>>>> before, could be just to distinguish between "logging >>>>>>>> parameters stable since startup" and "logging parameters >>>>>>>> changed at some time". That way you would at least know whether >>>>>>>> to trust the logging output. >>>>>>>> >>>>>>>> But you are right, this can be added later. >>>>>>> >>>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for >>>>>>> this. >>>>>>> >>>>>>> Max: Did you see my comments about the ConfigurationLock? It was >>>>>>> an inline reply to your first mail. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>> >>>>>>>> Kind Regards, Thomas >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>> > >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> Please review another Unified Logging change. They are >>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>> >>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>>> which >>>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>>> error >>>>>>>>> handler could potentially deadlock if its thread already >>>>>>>>> holds >>>>>>>>> the lock. Unsure how to resolve this, because skipping to >>>>>>>>> take >>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>> changing the configuration as we read it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The logging configuration is now printed in each hs_err >>>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>> >>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>> Logging info >>>>>>>>>>> is printed after VM Arguments and Whitebox, and before >>>>>>>>>>> Environment Variables. >>>>>>>>>>> >>>>>>>>>>> VM Arguments: >>>>>>>>>>> java_command: Kaboom >>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>> >>>>>>>>>>> Logging: >>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>> warning, error >>>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>>> timemillis >>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), uptimenanos >>>>>>>>>>> (un), >>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>>>>>>>> Available log tags: alloc, age, barrier, biasedlocking, >>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>> exceptions, >>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, itables, >>>>>>>>>>> jni, >>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>> preorder, >>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>> safepoint, >>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>> Log output configuration: >>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>> >>>>>>>>>>> Environment Variables: >>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>> >>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>> >>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>> OS=Linux >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From goetz.lindenmaier at sap.com Thu Apr 14 10:14:25 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Apr 2016 10:14:25 +0000 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. In-Reply-To: References: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> Message-ID: Hi Gerard, The code you change is not the problem. The value is passed to Java code, and java code can't handle it: java.lang.NumberFormatException: For input string: "18446744073709551615" at java.lang.NumberFormatException.forInputString(java.base/NumberFormatException.java:65) at java.lang.Long.parseLong(java.base/Long.java:747) at java.lang.Long.parseLong(java.base/Long.java:872) at jdk.internal.misc.VM.saveAndRemoveProperties(java.base/VM.java:290) at java.lang.System.initPhase1(java.base/System.java:1865) We could change the flag to jlong / int64_t with a positive range. But I think size_t is best for a flag giving a memory size. Best regards, Goetz. > -----Original Message----- > From: Gerard Ziemski [mailto:gerard.ziemski at oracle.com] > Sent: Mittwoch, 13. April 2016 18:30 > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which > is parsed at jlong. > > hi Goetz, > > How about if we just change the MaxDirectMemorySize type to uint64_t, like > so: > > http://cr.openjdk.java.net/~gziemski/8153835_rev1/ > > > cheers > > > > On Apr 13, 2016, at 8:25 AM, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > could someone please have a look at this tiny issue? And sponsor? > > > > Thanks, > > Goetz. > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Freitag, 8. April 2016 10:53 > >> To: hotspot-runtime-dev at openjdk.java.net > >> Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which > is > >> parsed at jlong. > >> > >> Hi, > >> > >> > >> > >> The upper limit of the range for flag MaxDirectMemorySize is > MAX_SIZE_T. > >> > >> The flag is used to set a property that is parsed into a long. Thus, the max > >> > >> value on 64-bit platforms is too large. > >> > >> Fix: Limit the range to max_jlong, too. > >> > >> > >> > >> Please review this change. I please need a sponsor. > >> > >> http://cr.openjdk.java.net/~goetz/wr16/8153835-MaxDMSz/webrev.01/ > >> > >> > >> > >> Best regards, > >> > >> Goetz. > >> > >> > >> > >> > > From goetz.lindenmaier at sap.com Thu Apr 14 10:23:44 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Apr 2016 10:23:44 +0000 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. References: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> Message-ID: <077a096cb4dd406997636081fd939f92@DEWDFE13DE09.global.corp.sap> Oh, sorry, I missed the upper bound you are using. Max_jlong fixes the Java exception. Is it ok on 32-bit if you increase the bound from max_uint32 to max_int64? If so, your fix is fine for me. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 14. April 2016 12:14 > To: 'Gerard Ziemski' > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: RE: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which > is parsed at jlong. > > Hi Gerard, > > The code you change is not the problem. The value is passed to Java code, > and java code can't handle it: > > java.lang.NumberFormatException: For input string: > "18446744073709551615" > at > java.lang.NumberFormatException.forInputString(java.base/NumberFormat > Exception.java:65) > at java.lang.Long.parseLong(java.base/Long.java:747) > at java.lang.Long.parseLong(java.base/Long.java:872) > at > jdk.internal.misc.VM.saveAndRemoveProperties(java.base/VM.java:290) > at java.lang.System.initPhase1(java.base/System.java:1865) > > We could change the flag to jlong / int64_t with a positive range. But I think > size_t is best for a flag giving a memory size. > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Gerard Ziemski [mailto:gerard.ziemski at oracle.com] > > Sent: Mittwoch, 13. April 2016 18:30 > > To: Lindenmaier, Goetz > > Cc: hotspot-runtime-dev at openjdk.java.net > > Subject: Re: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize > which > > is parsed at jlong. > > > > hi Goetz, > > > > How about if we just change the MaxDirectMemorySize type to uint64_t, > like > > so: > > > > http://cr.openjdk.java.net/~gziemski/8153835_rev1/ > > > > > > cheers > > > > > > > On Apr 13, 2016, at 8:25 AM, Lindenmaier, Goetz > > wrote: > > > > > > Hi, > > > > > > could someone please have a look at this tiny issue? And sponsor? > > > > > > Thanks, > > > Goetz. > > > > > >> -----Original Message----- > > >> From: Lindenmaier, Goetz > > >> Sent: Freitag, 8. April 2016 10:53 > > >> To: hotspot-runtime-dev at openjdk.java.net > > >> Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize > which > > is > > >> parsed at jlong. > > >> > > >> Hi, > > >> > > >> > > >> > > >> The upper limit of the range for flag MaxDirectMemorySize is > > MAX_SIZE_T. > > >> > > >> The flag is used to set a property that is parsed into a long. Thus, the > max > > >> > > >> value on 64-bit platforms is too large. > > >> > > >> Fix: Limit the range to max_jlong, too. > > >> > > >> > > >> > > >> Please review this change. I please need a sponsor. > > >> > > >> http://cr.openjdk.java.net/~goetz/wr16/8153835- > MaxDMSz/webrev.01/ > > >> > > >> > > >> > > >> Best regards, > > >> > > >> Goetz. > > >> > > >> > > >> > > >> > > > From robbin.ehn at oracle.com Thu Apr 14 11:36:17 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 14 Apr 2016 13:36:17 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging Message-ID: <570F80B1.5020602@oracle.com> Hi all, Please review: This moves jvmti trace output to the tag jvmti on trace level. The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have a lot of functionality, e.g. can filter on func, in/out, etc, so it if left as is. TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti tag is set. Webrev: http://cr.openjdk.java.net/~rehn/8154041/ Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 Thanks! /Robbin From robbin.ehn at oracle.com Thu Apr 14 11:52:57 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 14 Apr 2016 13:52:57 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL Message-ID: <570F8499.7070604@oracle.com> Hi all, Please review: This moves jvmti object-tagging output to the tag-set jvmti,objecttagging on debug level. The TraceJVMTIObjectTagging argument is deprecated and aliased with: "-Xlog:jvmti+objecttagging=debug" Did this on top of: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html but only part common is the jvmti tag (logTag.hpp). Webrev: http://cr.openjdk.java.net/~rehn/8154059/ Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 Thanks! /Robbin From robbin.ehn at oracle.com Thu Apr 14 12:26:30 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 14 Apr 2016 14:26:30 +0200 Subject: RFR: 8154235: Using deprecated flags converted to UL shows wrong hint Message-ID: <570F8C76.6020909@oracle.com> Hi all, Please review. When using a deprecated flag that have been converted to UL, we print the wrong hint when it contains more than one tag. Bug: https://bugs.openjdk.java.net/browse/JDK-8154235 Thanks! /Robbin diff -r 6acb563d8621 src/share/vm/runtime/arguments.cpp --- a/src/share/vm/runtime/arguments.cpp Thu Apr 14 08:30:37 2016 +0200 +++ b/src/share/vm/runtime/arguments.cpp Thu Apr 14 14:18:30 2016 +0200 @@ -998,7 +998,7 @@ int max_tags = sizeof(tagSet)/sizeof(tagSet[0]); for (int i = 0; i < max_tags && tagSet[i] != LogTag::__NO_TAG; i++) { if (i > 0) { - strncat(tagset_buffer, ",", max_tagset_len - strlen(tagset_buffer)); + strncat(tagset_buffer, "+", max_tagset_len - strlen(tagset_buffer)); } strncat(tagset_buffer, LogTag::name(tagSet[i]), max_tagset_len - strlen(tagset_buffer)); } From david.holmes at oracle.com Thu Apr 14 12:32:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Apr 2016 22:32:30 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570F13E3.6000802@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> Message-ID: <570F8DDE.5000002@oracle.com> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: > Hi, > > On 2016/04/14 9:34, David Holmes wrote: >> Hi, >> >> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> Thanks for your comment. >>> >>> I exported new JVM function to set native thread name, and JLI uses it >>> in new webrev. >> >> First the launcher belongs to another team so core-libs will need to >> review and approve this (in particular Kumar) - now cc'd. > > Thanks! > I'm waiting to review :-) > > >> Personally I would have used a Java upcall to Thread.setName rather >> than exporting JVM_SetNativeThreadName. No hotspot changes needed in >> that case. > > As I wrote [1] in JBS, I changed to use Thread#setName() in Thread#init(), > but I could not change native thread name. At Thread.init time the thread is not alive, which is why the native name is not set. > I guess that caller of main() is JNI attached thread. That is an interesting question which I haven't had time to check - sorry. If the main thread is considered a JNI-attached thread then my suggestion wont work. If it isn't then my suggestion should work (but it means we have an inconsistency in our treatment of JNI-attached threads :( ) I'll wait to see what Kumar thinks about this. I don't like exposing a new JVM function this way. Thanks, David ----- > Thus I think that we have to provide a function to set native thread name. > > > Thanks, > > Yasumasa > > > [1] > https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 > > >> Thanks, >> David >> >>> Could you review again? >>> >>> - hotspot: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>> >>> - jdk: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/13 22:00, David Holmes wrote: >>>> I'll answer on this original thread as well ... >>>> >>>> Hi Yasumasa, >>>> >>>> Please see my updates to the bug (sorry have been on vacation). This >>>> needs to be done in the launcher to be correct as we do not set the >>>> name of threads that attach via JNI, which includes the "main" thread. >>>> >>>> David >>>> >>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>> Thanks Robbin, >>>>> >>>>> I'm waiting a sponsor and more reviewer :-) >>>>> >>>>> Yasumasa >>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>> >>>>>> FYI: I'm not a Reviewer. >>>>>> >>>>>> /Robbin >>>>>> >>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>> >>>>>>> Thanks, looks good. >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I uploaded new webrev. >>>>>>>> Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>>> Hi Robbin, >>>>>>>>>> >>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>> >: >>>>>>>>>> > >>>>>>>>>> > Hi Yasumasa, >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>> >> >>>>>>>>>> >> Hi Robbin, >>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>> >>>>>>>>>> >> >>>>>>>>> >>: >>>>>>>>>> >> >>>>>>>>>> >> > >>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>> >> > >>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>> >> > >>>>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>> 13:09:16 2016 >>>>>>>>>> +0000 >>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>> 17:40:09 2016 >>>>>>>>>> +0100 >>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>> >> > >>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>> >>>>>>>>>> >> > >>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>> >> >>>>>>>>>> >> Native thread name is the same to thread name in Thread >>>>>>>>>> class. >>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>>>> will be >>>>>>>>>> set at >>>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>>>>>> >> I think that the place of setting thrrad name should be the >>>>>>>>>> same. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>>> nicer, no? >>>>>>>>>> > >>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 >>>>>>>>>> 2016 >>>>>>>>>> +0200 >>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 >>>>>>>>>> 2016 >>>>>>>>>> +0200 >>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>> > // Creates the initial Thread >>>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>>> JavaThread* >>>>>>>>>> thread, >>>>>>>>>> > TRAPS) { >>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>> > Klass* k = >>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>> true, >>>>>>>>>> CHECK_NULL); >>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>> NormPriority); >>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>> > - >>>>>>>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>>>>>>> CHECK_NULL); >>>>>>>>>> > + >>>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>>> > + >>>>>>>>>> > + Handle string = >>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>> CHECK_NULL); >>>>>>>>>> > >>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>> >>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> >>>>>>>>>> >> > The launcher seem to name itself 'java' and naming this >>>>>>>>>> thread >>>>>>>>>> just >>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>> >> > >>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>> process) is >>>>>>>>>> 'java' but >>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>> >> >>>>>>>>>> >> The native main thread in the process is not JavaThread. >>>>>>>>>> It is >>>>>>>>>> waiting >>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I think that >>>>>>>>>> we do >>>>>>>>>> not >>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Not sure if we can change it anyhow, since we want java and >>>>>>>>>> native >>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>> dependents. >>>>>>>>>> > >>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>> > >>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>> > PID TID COMMAND >>>>>>>>>> > 6423 6423 java >>>>>>>>>> > 6423 6424 main >>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>> > >>>>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>>>> >>>>>>>>>> I do not think so. >>>>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>> >>>>>>>>>> If you want to change native main thread name, I think that we >>>>>>>>>> have to >>>>>>>>>> change Java launcher code. >>>>>>>>>> Should I include it in new webrev? >>>>>>>>>> >>>>>>>>> >>>>>>>>> No >>>>>>>>> >>>>>>>>> Thanks again! >>>>>>>>> >>>>>>>>> /Robbin >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> > Thanks >>>>>>>>>> > >>>>>>>>>> > /Robbin >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> >> >>>>>>>>>> >> Thanks, >>>>>>>>>> >> >>>>>>>>>> >> Yasumasa >>>>>>>>>> >> >>>>>>>>>> >> > Thanks! >>>>>>>>>> >> > >>>>>>>>>> >> > /Robbin >>>>>>>>>> >> > >>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>> >> > > Hi all, >>>>>>>>>> >> > > >>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>> pthread_setname_np(). >>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>> >> > > >>>>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>>>> JavaThread. >>>>>>>>>> >> > > For consistency, main thread should have native thread >>>>>>>>>> name. >>>>>>>>>> >> > > >>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>> >> > > >>>>>>>>>> >> > > >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>> >> > > >>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>> >> > > >>>>>>>>>> >> > > >>>>>>>>>> >> > > Thanks, >>>>>>>>>> >> > > >>>>>>>>>> >> > > Yasumasa >>>>>>>>>> >> > > >>>>>>>>>> >> >>>>>>>>>> >>>>>>>>>> From yasuenag at gmail.com Thu Apr 14 13:32:46 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 14 Apr 2016 22:32:46 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570F8DDE.5000002@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> Message-ID: <570F9BFE.8010400@gmail.com> > That is an interesting question which I haven't had time to check - sorry. If the main thread is considered a JNI-attached thread then my suggestion wont work. If it isn't then my suggestion should work (but it means we have an inconsistency in our treatment of JNI-attached threads :( ) I ran following program on JDK 9 EA b112, and I confirmed native thread name (test) was set. --------- public class Sleep{ public static void main(String[] args) throws Exception{ Thread.currentThread().setName("test"); Thread.sleep(3600000); } } --------- > I'll wait to see what Kumar thinks about this. I don't like exposing a new JVM function this way. I will update webrev after hearing Kumar's comment. Thanks, Yasumasa On 2016/04/14 21:32, David Holmes wrote: > On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >> Hi, >> >> On 2016/04/14 9:34, David Holmes wrote: >>> Hi, >>> >>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> Thanks for your comment. >>>> >>>> I exported new JVM function to set native thread name, and JLI uses it >>>> in new webrev. >>> >>> First the launcher belongs to another team so core-libs will need to >>> review and approve this (in particular Kumar) - now cc'd. >> >> Thanks! >> I'm waiting to review :-) >> >> >>> Personally I would have used a Java upcall to Thread.setName rather >>> than exporting JVM_SetNativeThreadName. No hotspot changes needed in >>> that case. >> >> As I wrote [1] in JBS, I changed to use Thread#setName() in Thread#init(), >> but I could not change native thread name. > > At Thread.init time the thread is not alive, which is why the native name is not set. > >> I guess that caller of main() is JNI attached thread. > > That is an interesting question which I haven't had time to check - sorry. If the main thread is considered a JNI-attached thread then my suggestion wont work. If it isn't then my suggestion should work (but it means we have an inconsistency in our treatment of JNI-attached threads :( ) > > I'll wait to see what Kumar thinks about this. I don't like exposing a new JVM function this way. > > Thanks, > David > ----- > >> Thus I think that we have to provide a function to set native thread name. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >> >> >>> Thanks, >>> David >>> >>>> Could you review again? >>>> >>>> - hotspot: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>> >>>> - jdk: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/13 22:00, David Holmes wrote: >>>>> I'll answer on this original thread as well ... >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> Please see my updates to the bug (sorry have been on vacation). This >>>>> needs to be done in the launcher to be correct as we do not set the >>>>> name of threads that attach via JNI, which includes the "main" thread. >>>>> >>>>> David >>>>> >>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>> Thanks Robbin, >>>>>> >>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>> >>>>>> Yasumasa >>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>> >>>>>>> FYI: I'm not a Reviewer. >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>> >>>>>>>> Thanks, looks good. >>>>>>>> >>>>>>>> /Robbin >>>>>>>> >>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I uploaded new webrev. >>>>>>>>> Could you review it? >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>>>>> Hi Robbin, >>>>>>>>>>> >>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>> >: >>>>>>>>>>> > >>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> >> >>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>> >>>>>>>>>>> >> >>>>>>>>>> >>: >>>>>>>>>>> >> >>>>>>>>>>> >> > >>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>> >> > >>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>> >> > >>>>>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>> +0000 >>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>> +0100 >>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>> >> > >>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>> >>>>>>>>>>> >> > >>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>> >> >>>>>>>>>>> >> Native thread name is the same to thread name in Thread >>>>>>>>>>> class. >>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>>>>> will be >>>>>>>>>>> set at >>>>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>>>>>>> >> I think that the place of setting thrrad name should be the >>>>>>>>>>> same. >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>>>> nicer, no? >>>>>>>>>>> > >>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 >>>>>>>>>>> 2016 >>>>>>>>>>> +0200 >>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 >>>>>>>>>>> 2016 >>>>>>>>>>> +0200 >>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>>>> JavaThread* >>>>>>>>>>> thread, >>>>>>>>>>> > TRAPS) { >>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>> > Klass* k = >>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>> true, >>>>>>>>>>> CHECK_NULL); >>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>> NormPriority); >>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>> > - >>>>>>>>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>>>>>>>> CHECK_NULL); >>>>>>>>>>> > + >>>>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>> > + >>>>>>>>>>> > + Handle string = >>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>> CHECK_NULL); >>>>>>>>>>> > >>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>> >>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >> > The launcher seem to name itself 'java' and naming this >>>>>>>>>>> thread >>>>>>>>>>> just >>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>> >> > >>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>> process) is >>>>>>>>>>> 'java' but >>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>> >> >>>>>>>>>>> >> The native main thread in the process is not JavaThread. >>>>>>>>>>> It is >>>>>>>>>>> waiting >>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I think that >>>>>>>>>>> we do >>>>>>>>>>> not >>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Not sure if we can change it anyhow, since we want java and >>>>>>>>>>> native >>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>> dependents. >>>>>>>>>>> > >>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>> > >>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>> > 6423 6423 java >>>>>>>>>>> > 6423 6424 main >>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>> > >>>>>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>>>>> >>>>>>>>>>> I do not think so. >>>>>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>> >>>>>>>>>>> If you want to change native main thread name, I think that we >>>>>>>>>>> have to >>>>>>>>>>> change Java launcher code. >>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No >>>>>>>>>> >>>>>>>>>> Thanks again! >>>>>>>>>> >>>>>>>>>> /Robbin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> > Thanks >>>>>>>>>>> > >>>>>>>>>>> > /Robbin >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >> >>>>>>>>>>> >> Thanks, >>>>>>>>>>> >> >>>>>>>>>>> >> Yasumasa >>>>>>>>>>> >> >>>>>>>>>>> >> > Thanks! >>>>>>>>>>> >> > >>>>>>>>>>> >> > /Robbin >>>>>>>>>>> >> > >>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> >> > > Hi all, >>>>>>>>>>> >> > > >>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>> >> > > >>>>>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>>>>> JavaThread. >>>>>>>>>>> >> > > For consistency, main thread should have native thread >>>>>>>>>>> name. >>>>>>>>>>> >> > > >>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>> >> > > >>>>>>>>>>> >> > > >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>> >> > > >>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>> >> > > >>>>>>>>>>> >> > > >>>>>>>>>>> >> > > Thanks, >>>>>>>>>>> >> > > >>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>> >> > > >>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> From rachel.protacio at oracle.com Thu Apr 14 13:47:01 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 14 Apr 2016 09:47:01 -0400 Subject: RFR: 8154235: Using deprecated flags converted to UL shows wrong hint In-Reply-To: <570F8C76.6020909@oracle.com> References: <570F8C76.6020909@oracle.com> Message-ID: <570F9F55.8090109@oracle.com> Looks good, thanks for catching that! Rachel On 4/14/2016 8:26 AM, Robbin Ehn wrote: > Hi all, > > Please review. > > When using a deprecated flag that have been converted to UL, > we print the wrong hint when it contains more than one tag. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154235 > > Thanks! > > /Robbin > > diff -r 6acb563d8621 src/share/vm/runtime/arguments.cpp > --- a/src/share/vm/runtime/arguments.cpp Thu Apr 14 08:30:37 2016 > +0200 > +++ b/src/share/vm/runtime/arguments.cpp Thu Apr 14 14:18:30 2016 > +0200 > @@ -998,7 +998,7 @@ > int max_tags = sizeof(tagSet)/sizeof(tagSet[0]); > for (int i = 0; i < max_tags && tagSet[i] != LogTag::__NO_TAG; i++) { > if (i > 0) { > - strncat(tagset_buffer, ",", max_tagset_len - > strlen(tagset_buffer)); > + strncat(tagset_buffer, "+", max_tagset_len - > strlen(tagset_buffer)); > } > strncat(tagset_buffer, LogTag::name(tagSet[i]), max_tagset_len - > strlen(tagset_buffer)); > } From Roger.Riggs at Oracle.com Thu Apr 14 14:24:03 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 14 Apr 2016 10:24:03 -0400 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570F9BFE.8010400@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> Message-ID: <570FA803.1010105@Oracle.com> Hi, Comments: jvm.h: The function names are too similar but perform different functions: -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName - The first function applies to the current thread, the second one a specific java thread. It would seem useful for there to be a comment somewhere about what the new function does. windows/native/libjli/java_md.c: line 408 casts to (void*) instead of (SetNativeThreadName0_t) as is done on unix and mac. - macosx/native/libjli/java_md_macosx.c: - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at line 730 - 738 Incorrect indentation; if possible keep the cast on the same line as dlsym... $.02, Roger On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >> That is an interesting question which I haven't had time to check - >> sorry. If the main thread is considered a JNI-attached thread then my >> suggestion wont work. If it isn't then my suggestion should work (but >> it means we have an inconsistency in our treatment of JNI-attached >> threads :( ) > > I ran following program on JDK 9 EA b112, and I confirmed native > thread name (test) was set. > --------- > public class Sleep{ > public static void main(String[] args) throws Exception{ > Thread.currentThread().setName("test"); > Thread.sleep(3600000); > } > } > --------- > > >> I'll wait to see what Kumar thinks about this. I don't like exposing >> a new JVM function this way. > > I will update webrev after hearing Kumar's comment. > > > Thanks, > > Yasumasa > > > On 2016/04/14 21:32, David Holmes wrote: >> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>> Hi, >>> >>> On 2016/04/14 9:34, David Holmes wrote: >>>> Hi, >>>> >>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> Thanks for your comment. >>>>> >>>>> I exported new JVM function to set native thread name, and JLI >>>>> uses it >>>>> in new webrev. >>>> >>>> First the launcher belongs to another team so core-libs will need to >>>> review and approve this (in particular Kumar) - now cc'd. >>> >>> Thanks! >>> I'm waiting to review :-) >>> >>> >>>> Personally I would have used a Java upcall to Thread.setName rather >>>> than exporting JVM_SetNativeThreadName. No hotspot changes needed in >>>> that case. >>> >>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>> Thread#init(), >>> but I could not change native thread name. >> >> At Thread.init time the thread is not alive, which is why the native >> name is not set. >> >>> I guess that caller of main() is JNI attached thread. >> >> That is an interesting question which I haven't had time to check - >> sorry. If the main thread is considered a JNI-attached thread then my >> suggestion wont work. If it isn't then my suggestion should work (but >> it means we have an inconsistency in our treatment of JNI-attached >> threads :( ) >> >> I'll wait to see what Kumar thinks about this. I don't like exposing >> a new JVM function this way. >> >> Thanks, >> David >> ----- >> >>> Thus I think that we have to provide a function to set native thread >>> name. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>> >>> >>> >>>> Thanks, >>>> David >>>> >>>>> Could you review again? >>>>> >>>>> - hotspot: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>> >>>>> - jdk: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>> I'll answer on this original thread as well ... >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> Please see my updates to the bug (sorry have been on vacation). This >>>>>> needs to be done in the launcher to be correct as we do not set the >>>>>> name of threads that attach via JNI, which includes the "main" >>>>>> thread. >>>>>> >>>>>> David >>>>>> >>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>> Thanks Robbin, >>>>>>> >>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>> >>>>>>> Yasumasa >>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>> >>>>>>>> FYI: I'm not a Reviewer. >>>>>>>> >>>>>>>> /Robbin >>>>>>>> >>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>> >>>>>>>>> Thanks, looks good. >>>>>>>>> >>>>>>>>> /Robbin >>>>>>>>> >>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I uploaded new webrev. >>>>>>>>>> Could you review it? >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>> >>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>> >: >>>>>>>>>>>> > >>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>> >>>>>>>>>>>> >> >>>>>>>>>>> >>: >>>>>>>>>>>> >> >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>> +0000 >>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>> +0100 >>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>> >> > >>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>> >> >>>>>>>>>>>> >> Native thread name is the same to thread name in Thread >>>>>>>>>>>> class. >>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>>>>>> will be >>>>>>>>>>>> set at >>>>>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>>>>>>>> >> I think that the place of setting thrrad name should >>>>>>>>>>>> be the >>>>>>>>>>>> same. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>>>>> nicer, no? >>>>>>>>>>>> > >>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>> 09:43:05 >>>>>>>>>>>> 2016 >>>>>>>>>>>> +0200 >>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>> 10:51:12 >>>>>>>>>>>> 2016 >>>>>>>>>>>> +0200 >>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>>>>> JavaThread* >>>>>>>>>>>> thread, >>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>> > Klass* k = >>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>> >>>>>>>>>>>> true, >>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>> NormPriority); >>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>> > - >>>>>>>>>>>> > - Handle string = >>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>> > + >>>>>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>> > + >>>>>>>>>>>> > + Handle string = >>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>> > >>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>> >>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >> > The launcher seem to name itself 'java' and naming >>>>>>>>>>>> this >>>>>>>>>>>> thread >>>>>>>>>>>> just >>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>>> process) is >>>>>>>>>>>> 'java' but >>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>> >> >>>>>>>>>>>> >> The native main thread in the process is not JavaThread. >>>>>>>>>>>> It is >>>>>>>>>>>> waiting >>>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I think >>>>>>>>>>>> that >>>>>>>>>>>> we do >>>>>>>>>>>> not >>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Not sure if we can change it anyhow, since we want java >>>>>>>>>>>> and >>>>>>>>>>>> native >>>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>>> dependents. >>>>>>>>>>>> > >>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>> > >>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>> > >>>>>>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>>>>>> >>>>>>>>>>>> I do not think so. >>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>> >>>>>>>>>>>> If you want to change native main thread name, I think that we >>>>>>>>>>>> have to >>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No >>>>>>>>>>> >>>>>>>>>>> Thanks again! >>>>>>>>>>> >>>>>>>>>>> /Robbin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> > Thanks >>>>>>>>>>>> > >>>>>>>>>>>> > /Robbin >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> >> >>>>>>>>>>>> >> Thanks, >>>>>>>>>>>> >> >>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>> >> >>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>>>>>> JavaThread. >>>>>>>>>>>> >> > > For consistency, main thread should have native >>>>>>>>>>>> thread >>>>>>>>>>>> name. >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> > > >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>> >> > > >>>>>>>>>>>> >> >>>>>>>>>>>> >>>>>>>>>>>> From mikhailo.seledtsov at oracle.com Thu Apr 14 14:26:35 2016 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 14 Apr 2016 07:26:35 -0700 Subject: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder In-Reply-To: <570BB6B8.8000105@oracle.com> References: <570BB6B8.8000105@oracle.com> Message-ID: <570FA89B.9040000@oracle.com> Ioi, Lois, George, Thank you for review. I believe I still need one Capital "R" reviewer for an open change. Any Reviewer volunteers for this simple file removal change? Please take a look. Thank you, Misha On 4/11/2016 7:37 AM, Mikhailo Seledtsov wrote: > Please review this simple fix - the deletion of obsolete/redundant > test utility class > BasicJarBuilder. The functionality is now inside the > ClassFileInstaller.java, and this > utility is redundant. The work here was mainly to make sure no other > parts > of jdk or test reference BasicJarBuilder. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153549 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8153549.00/ > Testing: > - ensure no-one else uses it: grepped all hs-rt repository - no > references > - removed BasicJarBuilder; ran hotspot_all group locally on Linux-x64 > Pass > > Thank you, > Misha > From harold.seigel at oracle.com Thu Apr 14 14:29:06 2016 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 14 Apr 2016 10:29:06 -0400 Subject: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder In-Reply-To: <570FA89B.9040000@oracle.com> References: <570BB6B8.8000105@oracle.com> <570FA89B.9040000@oracle.com> Message-ID: <570FA932.4090707@oracle.com> The change looks good! Harold On 4/14/2016 10:26 AM, Mikhailo Seledtsov wrote: > Ioi, Lois, George, > > Thank you for review. > > I believe I still need one Capital "R" reviewer for an open change. > Any Reviewer volunteers for this simple file removal change? Please > take a look. > > Thank you, > Misha > > > On 4/11/2016 7:37 AM, Mikhailo Seledtsov wrote: >> Please review this simple fix - the deletion of obsolete/redundant >> test utility class >> BasicJarBuilder. The functionality is now inside the >> ClassFileInstaller.java, and this >> utility is redundant. The work here was mainly to make sure no other >> parts >> of jdk or test reference BasicJarBuilder. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8153549 >> Webrev: http://cr.openjdk.java.net/~mseledtsov/8153549.00/ >> Testing: >> - ensure no-one else uses it: grepped all hs-rt repository - no >> references >> - removed BasicJarBuilder; ran hotspot_all group locally on >> Linux-x64 >> Pass >> >> Thank you, >> Misha >> > From mikhailo.seledtsov at oracle.com Thu Apr 14 14:34:24 2016 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Thu, 14 Apr 2016 07:34:24 -0700 Subject: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder In-Reply-To: <570FA932.4090707@oracle.com> References: <570BB6B8.8000105@oracle.com> <570FA89B.9040000@oracle.com> <570FA932.4090707@oracle.com> Message-ID: <570FAA70.6000900@oracle.com> Thank you Harold, Misha On 4/14/2016 7:29 AM, harold seigel wrote: > The change looks good! > Harold > > On 4/14/2016 10:26 AM, Mikhailo Seledtsov wrote: >> Ioi, Lois, George, >> >> Thank you for review. >> >> I believe I still need one Capital "R" reviewer for an open change. >> Any Reviewer volunteers for this simple file removal change? Please >> take a look. >> >> Thank you, >> Misha >> >> >> On 4/11/2016 7:37 AM, Mikhailo Seledtsov wrote: >>> Please review this simple fix - the deletion of obsolete/redundant >>> test utility class >>> BasicJarBuilder. The functionality is now inside the >>> ClassFileInstaller.java, and this >>> utility is redundant. The work here was mainly to make sure no other >>> parts >>> of jdk or test reference BasicJarBuilder. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8153549 >>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8153549.00/ >>> Testing: >>> - ensure no-one else uses it: grepped all hs-rt repository - no >>> references >>> - removed BasicJarBuilder; ran hotspot_all group locally on >>> Linux-x64 >>> Pass >>> >>> Thank you, >>> Misha >>> >> > From christian.tornqvist at oracle.com Thu Apr 14 14:49:20 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 14 Apr 2016 10:49:20 -0400 Subject: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder In-Reply-To: <570FA89B.9040000@oracle.com> References: <570BB6B8.8000105@oracle.com> <570FA89B.9040000@oracle.com> Message-ID: <5c7c01d1965c$d43b9fd0$7cb2df70$@oracle.com> Hi Misha, This looks good. Thanks, Christian -----Original Message----- From: Mikhailo Seledtsov [mailto:mikhailo.seledtsov at oracle.com] Sent: Thursday, April 14, 2016 10:27 AM To: hotspot-runtime-dev at openjdk.java.net >> hotspot-runtime-dev ; Ioi Lam ; LOIS.FOLTAN ; David Holmes ; Christian T?rnqvist Subject: Re: RFR(XS): JDK-8153549 - [TESTBUG] remove obsolete runtime/SharedArchiveFile/BasicJarBuilder Ioi, Lois, George, Thank you for review. I believe I still need one Capital "R" reviewer for an open change. Any Reviewer volunteers for this simple file removal change? Please take a look. Thank you, Misha On 4/11/2016 7:37 AM, Mikhailo Seledtsov wrote: > Please review this simple fix - the deletion of obsolete/redundant > test utility class BasicJarBuilder. The functionality is now inside > the ClassFileInstaller.java, and this utility is redundant. The work > here was mainly to make sure no other parts of jdk or test reference > BasicJarBuilder. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8153549 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8153549.00/ > Testing: > - ensure no-one else uses it: grepped all hs-rt repository - no > references > - removed BasicJarBuilder; ran hotspot_all group locally on Linux-x64 > Pass > > Thank you, > Misha > From yasuenag at gmail.com Thu Apr 14 15:11:36 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 15 Apr 2016 00:11:36 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570FA803.1010105@Oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> Message-ID: <570FB328.5020902@gmail.com> Roger, Thanks for your comment! David, >>> I'll wait to see what Kumar thinks about this. I don't like exposing a new JVM function this way. I tried to call Thread#setName() after initializing VM (before calling main method), I could set native thread name. However, DestroyJavaVM() calls AttachCurrentThread(). So we can't set native thread name for DestroyJavaVM. Thanks, Yasumasa On 2016/04/14 23:24, Roger Riggs wrote: > Hi, > > Comments: > > jvm.h: The function names are too similar but perform different functions: > > -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName > > - The first function applies to the current thread, the second one a specific java thread. > It would seem useful for there to be a comment somewhere about what the new function does. > > windows/native/libjli/java_md.c: line 408 casts to (void*) instead of (SetNativeThreadName0_t) > as is done on unix and mac. > > - macosx/native/libjli/java_md_macosx.c: > - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at line 730 > - 738 Incorrect indentation; if possible keep the cast on the same line as dlsym... > > $.02, Roger > > > On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>> That is an interesting question which I haven't had time to check - sorry. If the main thread is considered a JNI-attached thread then my suggestion wont work. If it isn't then my suggestion should work (but it means we have an inconsistency in our treatment of JNI-attached threads :( ) >> >> I ran following program on JDK 9 EA b112, and I confirmed native thread name (test) was set. >> --------- >> public class Sleep{ >> public static void main(String[] args) throws Exception{ >> Thread.currentThread().setName("test"); >> Thread.sleep(3600000); >> } >> } >> --------- >> >> >>> I'll wait to see what Kumar thinks about this. I don't like exposing a new JVM function this way. >> >> I will update webrev after hearing Kumar's comment. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/14 21:32, David Holmes wrote: >>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>> On 2016/04/14 9:34, David Holmes wrote: >>>>> Hi, >>>>> >>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for your comment. >>>>>> >>>>>> I exported new JVM function to set native thread name, and JLI uses it >>>>>> in new webrev. >>>>> >>>>> First the launcher belongs to another team so core-libs will need to >>>>> review and approve this (in particular Kumar) - now cc'd. >>>> >>>> Thanks! >>>> I'm waiting to review :-) >>>> >>>> >>>>> Personally I would have used a Java upcall to Thread.setName rather >>>>> than exporting JVM_SetNativeThreadName. No hotspot changes needed in >>>>> that case. >>>> >>>> As I wrote [1] in JBS, I changed to use Thread#setName() in Thread#init(), >>>> but I could not change native thread name. >>> >>> At Thread.init time the thread is not alive, which is why the native name is not set. >>> >>>> I guess that caller of main() is JNI attached thread. >>> >>> That is an interesting question which I haven't had time to check - sorry. If the main thread is considered a JNI-attached thread then my suggestion wont work. If it isn't then my suggestion should work (but it means we have an inconsistency in our treatment of JNI-attached threads :( ) >>> >>> I'll wait to see what Kumar thinks about this. I don't like exposing a new JVM function this way. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Thus I think that we have to provide a function to set native thread name. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Could you review again? >>>>>> >>>>>> - hotspot: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>> >>>>>> - jdk: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>> I'll answer on this original thread as well ... >>>>>>> >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Please see my updates to the bug (sorry have been on vacation). This >>>>>>> needs to be done in the launcher to be correct as we do not set the >>>>>>> name of threads that attach via JNI, which includes the "main" thread. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>> Thanks Robbin, >>>>>>>> >>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>> >>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>> >>>>>>>>> /Robbin >>>>>>>>> >>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>> >>>>>>>>>> Thanks, looks good. >>>>>>>>>> >>>>>>>>>> /Robbin >>>>>>>>>> >>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>> Could you review it? >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>> >>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>> >: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>> >>: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>> +0000 >>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>> +0100 >>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>> >> > >>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>> >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Native thread name is the same to thread name in Thread >>>>>>>>>>>>> class. >>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>>>>>>> will be >>>>>>>>>>>>> set at >>>>>>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>>>>>> >> Thread name for "main" is set in create_initial_thread(). >>>>>>>>>>>>> >> I think that the place of setting thrrad name should be the >>>>>>>>>>>>> same. >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>> > >>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 09:43:05 >>>>>>>>>>>>> 2016 >>>>>>>>>>>>> +0200 >>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 10:51:12 >>>>>>>>>>>>> 2016 >>>>>>>>>>>>> +0200 >>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>> thread, >>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>> true, >>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>> > - >>>>>>>>>>>>> > - Handle string = java_lang_String::create_from_str("main", >>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>> > + >>>>>>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>> > + >>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>> > >>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>> >>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and naming this >>>>>>>>>>>>> thread >>>>>>>>>>>>> just >>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>>>> process) is >>>>>>>>>>>>> 'java' but >>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> The native main thread in the process is not JavaThread. >>>>>>>>>>>>> It is >>>>>>>>>>>>> waiting >>>>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I think that >>>>>>>>>>>>> we do >>>>>>>>>>>>> not >>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want java and >>>>>>>>>>>>> native >>>>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>>>> dependents. >>>>>>>>>>>>> > >>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>> > >>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>> > >>>>>>>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>>>>>>> >>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>> >>>>>>>>>>>>> If you want to change native main thread name, I think that we >>>>>>>>>>>>> have to >>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> No >>>>>>>>>>>> >>>>>>>>>>>> Thanks again! >>>>>>>>>>>> >>>>>>>>>>>> /Robbin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> > Thanks >>>>>>>>>>>>> > >>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>> >> > >>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>> >> > > For consistency, main thread should have native thread >>>>>>>>>>>>> name. >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>>> > From robbin.ehn at oracle.com Thu Apr 14 15:20:29 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 14 Apr 2016 17:20:29 +0200 Subject: RFR: 8154235: Using deprecated flags converted to UL shows wrong hint In-Reply-To: <570F9F55.8090109@oracle.com> References: <570F8C76.6020909@oracle.com> <570F9F55.8090109@oracle.com> Message-ID: <570FB53D.6090904@oracle.com> Thanks Rachel! /Robbin On 04/14/2016 03:47 PM, Rachel Protacio wrote: > Looks good, thanks for catching that! > Rachel > > On 4/14/2016 8:26 AM, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> When using a deprecated flag that have been converted to UL, >> we print the wrong hint when it contains more than one tag. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154235 >> >> Thanks! >> >> /Robbin >> >> diff -r 6acb563d8621 src/share/vm/runtime/arguments.cpp >> --- a/src/share/vm/runtime/arguments.cpp Thu Apr 14 08:30:37 2016 >> +0200 >> +++ b/src/share/vm/runtime/arguments.cpp Thu Apr 14 14:18:30 2016 >> +0200 >> @@ -998,7 +998,7 @@ >> int max_tags = sizeof(tagSet)/sizeof(tagSet[0]); >> for (int i = 0; i < max_tags && tagSet[i] != LogTag::__NO_TAG; i++) { >> if (i > 0) { >> - strncat(tagset_buffer, ",", max_tagset_len - >> strlen(tagset_buffer)); >> + strncat(tagset_buffer, "+", max_tagset_len - >> strlen(tagset_buffer)); >> } >> strncat(tagset_buffer, LogTag::name(tagSet[i]), max_tagset_len - >> strlen(tagset_buffer)); >> } > From max.ockner at oracle.com Thu Apr 14 15:31:51 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 14 Apr 2016 11:31:51 -0400 Subject: RFR: 8154235: Using deprecated flags converted to UL shows wrong hint In-Reply-To: <570F8C76.6020909@oracle.com> References: <570F8C76.6020909@oracle.com> Message-ID: <570FB7E7.7070608@oracle.com> Looks good. Thanks for fixing. -Max On 4/14/2016 8:26 AM, Robbin Ehn wrote: > Hi all, > > Please review. > > When using a deprecated flag that have been converted to UL, > we print the wrong hint when it contains more than one tag. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154235 > > Thanks! > > /Robbin > > diff -r 6acb563d8621 src/share/vm/runtime/arguments.cpp > --- a/src/share/vm/runtime/arguments.cpp Thu Apr 14 08:30:37 2016 > +0200 > +++ b/src/share/vm/runtime/arguments.cpp Thu Apr 14 14:18:30 2016 > +0200 > @@ -998,7 +998,7 @@ > int max_tags = sizeof(tagSet)/sizeof(tagSet[0]); > for (int i = 0; i < max_tags && tagSet[i] != LogTag::__NO_TAG; i++) { > if (i > 0) { > - strncat(tagset_buffer, ",", max_tagset_len - > strlen(tagset_buffer)); > + strncat(tagset_buffer, "+", max_tagset_len - > strlen(tagset_buffer)); > } > strncat(tagset_buffer, LogTag::name(tagSet[i]), max_tagset_len - > strlen(tagset_buffer)); > } From chris.hegarty at oracle.com Thu Apr 14 15:38:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Apr 2016 16:38:03 +0100 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <0980D0EB-BAF1-4C76-9A82-D3F6BCCFA423@oracle.com> References: <570E690B.2060703@oracle.com> <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> <570E81A0.5050904@oracle.com> <0980D0EB-BAF1-4C76-9A82-D3F6BCCFA423@oracle.com> Message-ID: <8492DC62-0397-44E7-A987-24364140EC5C@oracle.com> Mandy, The webrev has been updated in-place http://cr.openjdk.java.net/~chegar/8137058/ http://cr.openjdk.java.net/~chegar/8137058/jdk_incremental.diffs All 'core', 'pit', and 'hotspot' testsets have been successfully run on Mac, Linux, Windows, and Solaris. On 13 Apr 2016, at 18:43, Mandy Chung wrote: >>> This patch will likely impact existing libraries that filter out reflection frames (IIRC Groovy and log4j may be examples) doing Class::getName().startsWith(?sun.reflect?). It may worth call out this incompatibility in JEP 260. I added the following note to the Risks and Assumptions section of JEP 260: Beyond the proposed critical APIs for `sun.reflect`, said package contains the machinery that implements the `java.lang(.reflect)` subsystem. That machinery will be moved to an internal, non-exported, package in the base module. Consequently, the stack trace of reflective calls will appear somewhat different. That is, stack frames that represent the reflective implementation will see their class name ( `StackTraceElement.getClassName()` ) change from `sun.reflect.XXX` to `jdk.internal.reflect.XXX`. Any code analysing, or filtering, based on the stack trace element's class name should be updated appropriately, to handle this. See [8137058](https://bugs.openjdk.java.net/browse/JDK-8137058) for further details. -Chris. From robbin.ehn at oracle.com Thu Apr 14 15:41:19 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 14 Apr 2016 17:41:19 +0200 Subject: RFR: 8154235: Using deprecated flags converted to UL shows wrong hint In-Reply-To: <570FB7E7.7070608@oracle.com> References: <570F8C76.6020909@oracle.com> <570FB7E7.7070608@oracle.com> Message-ID: <570FBA1F.2020600@oracle.com> Thanks Max! /Robbin On 04/14/2016 05:31 PM, Max Ockner wrote: > Looks good. Thanks for fixing. > -Max > > On 4/14/2016 8:26 AM, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> When using a deprecated flag that have been converted to UL, >> we print the wrong hint when it contains more than one tag. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154235 >> >> Thanks! >> >> /Robbin >> >> diff -r 6acb563d8621 src/share/vm/runtime/arguments.cpp >> --- a/src/share/vm/runtime/arguments.cpp Thu Apr 14 08:30:37 2016 >> +0200 >> +++ b/src/share/vm/runtime/arguments.cpp Thu Apr 14 14:18:30 2016 >> +0200 >> @@ -998,7 +998,7 @@ >> int max_tags = sizeof(tagSet)/sizeof(tagSet[0]); >> for (int i = 0; i < max_tags && tagSet[i] != LogTag::__NO_TAG; i++) { >> if (i > 0) { >> - strncat(tagset_buffer, ",", max_tagset_len - >> strlen(tagset_buffer)); >> + strncat(tagset_buffer, "+", max_tagset_len - >> strlen(tagset_buffer)); >> } >> strncat(tagset_buffer, LogTag::name(tagSet[i]), max_tagset_len - >> strlen(tagset_buffer)); >> } > From max.ockner at oracle.com Thu Apr 14 16:22:10 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 14 Apr 2016 12:22:10 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570F5514.9040805@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> Message-ID: <570FC3B2.4040805@oracle.com> new webrev: http://cr.openjdk.java.net/~mockner/8151526.05/ - new describe_* methods are now private - VMError is now a friend class in logConfiguration. Thanks, Max On 4/14/2016 4:30 AM, Marcus Larsson wrote: > Hi, > > On 04/13/2016 09:33 PM, Max Ockner wrote: >> Hello, >> I have made these changes. >> - refactored describe into a portion which uses locking and one that >> does not. >> - in the print_vm_info function in vmError.cpp, describe() is used, >> since this function is called while the program is running. >> - in the report function, the describe_no_lock and describe_with_lock >> functions are both used without taking a lock. If it doesnt crash, >> then fantastic. If it does crash, the error handler will skip this >> step anyway. >> >> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 > > I suggest making the new two functions private in LogConfiguration, > and friending VMError, instead of keeping them public. That should > reduce confusion about which describe-method to use, and prevent > misuse of the describe_with_lock in other places. > > Otherwise this looks good. > > Thanks, > Marcus > >> >> Thanks, >> Max >> >> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>> Hey, >>> >>> On 2016-04-12 17:01, Max Ockner wrote: >>>> Marcus, >>>> >>>> I just spoke with Coleen about this. If I attempt to print >>>> configuration during a crash without lock and it crashes, the error >>>> handler will eat it up and start at the next step. It would be fun >>>> to write a locking mechanism, but this seems better to me. >>>> >>>> I will continue to call describe() from VM.info, but I will >>>> refactor the code in describe so that all of the information can be >>>> printed easily without taking a lock. For a crash, I'll use the >>>> refactored print functions to print all the necessary information >>>> without taking a lock. Even if the vm crashes during this step it >>>> is not such a bad thing because of the robust error handler. >>> >>> Alright, that sounds good! >>> >>> Thanks, >>> Marcus >>> >>>> >>>> >>>> Thanks, >>>> Max >>>> >>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>> Hi Max, >>>>> >>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>> Hello again, >>>>>> >>>>>> I have looked into this and I see a possible workaround to the >>>>>> issue raised by Marcus: >>>>>> >>>>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>>>> might be problematic for the error handler. I suppose the error >>>>>> handler could potentially deadlock if its thread already holds >>>>>> the lock. Unsure how to resolve this, because skipping to take >>>>>> the lock means that we might crash due to another thread >>>>>> changing the configuration as we read it. >>>>>> >>>>>> >>>>>> My proposed solution is this: >>>>>> >>>>>> If the ConfigurationLock is held by another thread during the >>>>>> crash, then I think we could print "Log configuration can not be >>>>>> accessed because ConfigurationLock is currently held by another >>>>>> thread" or something similar. If the ConfigurationLock can be >>>>>> taken by the current thread, then print the configuration. >>>>>> >>>>>> We can accomplish this as follows: >>>>>> >>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class >>>>>> extending ConfigurationLock. >>>>>> >>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>> private: >>>>>> bool _success; >>>>>> public: >>>>>> ConfigurationLockMaybe() { >>>>>> if (_semaphore.trywait()){_success = true;} >>>>>> } >>>>>> ~ConfigurationLock() { >>>>>> if(_success){_semaphore.signal();} >>>>>> } >>>>>> bool has_lock(){return _success;} >>>>>> }; >>>>>> >>>>>> _semaphore is a static var in ConfigurationLock, so the same copy >>>>>> is accessed in child classes. >>>>>> >>>>>> Another method LogConfiguration::describe_on_crash(outputStream* >>>>>> out) can use ConfigurationLockMaybe to attempt to print the >>>>>> configuration. >>>>>> >>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>> LogConfiguration::describe_on_crash. >>>>> >>>>> Sounds good to me. >>>>> >>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>> better suggestion. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> Max >>>>>> >>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>> I missed this before. I'm going to investigate. >>>>>>> Max >>>>>>> >>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> I forgot to respond to this: >>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>> (Replies in line) >>>>>>>>>>> >>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>> >>>>>>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>>>>>> >>>>>>>>>>> Just going by what we currently put in the hs_err file, >>>>>>>>>>> I think >>>>>>>>>>> this may be the first "Do we really need" we've ever >>>>>>>>>>> asked for >>>>>>>>>>> this type of change. >>>>>>>>>>> >>>>>>>>>>> All joking aside, I think it is a good idea to direct users >>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>> >>>>>>>>>>>> Also: I assume what you print is the Log state as it is >>>>>>>>>>>> at the >>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>> >>>>>>>>>>> Would it be possible? Yes, but I think this would require a >>>>>>>>>>> framework change. It does not look like any marks are >>>>>>>>>>> made when >>>>>>>>>>> the LogConfiguration changes during runtime, and we >>>>>>>>>>> would need >>>>>>>>>>> to record that in order to know what to print when we >>>>>>>>>>> dump into >>>>>>>>>>> hs_err. >>>>>>>>>> >>>>>>>>>> Yes, this would required the framework to keep some sort >>>>>>>>>> of log >>>>>>>>>> of configuration changes. Is there value in knowing that >>>>>>>>>> the log >>>>>>>>>> configuration changed since startup? >>>>>>>>> >>>>>>>>> I think it is useful along with other information. An >>>>>>>>> example case: >>>>>>>>> >>>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>>> acquired or >>>>>>>>> released. In a subsystem like this, the action which dooms >>>>>>>>> the vm >>>>>>>>> may not cause an immediate crash. This leaves time for >>>>>>>>> logging to >>>>>>>>> turn on or off in between the bad action and the crash. If >>>>>>>>> you >>>>>>>>> don't know when logging was active and when it was not, >>>>>>>>> then the >>>>>>>>> absence of a particular message does not give you much >>>>>>>>> information. You may not see the message that has the >>>>>>>>> answer for >>>>>>>>> you because it was not logged, though the action may have >>>>>>>>> occurred. >>>>>>>>> >>>>>>>>> However, if we don't have the framework support for this >>>>>>>>> then I >>>>>>>>> believe it should be added later. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This is a good example. A small easy solution, as I mentioned >>>>>>>>> before, could be just to distinguish between "logging >>>>>>>>> parameters stable since startup" and "logging parameters >>>>>>>>> changed at some time". That way you would at least know >>>>>>>>> whether to trust the logging output. >>>>>>>>> >>>>>>>>> But you are right, this can be added later. >>>>>>>> >>>>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for >>>>>>>> this. >>>>>>>> >>>>>>>> Max: Did you see my comments about the ConfigurationLock? It >>>>>>>> was an inline reply to your first mail. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>>> >>>>>>>>> Kind Regards, Thomas >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>> > >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> Please review another Unified Logging change. They are >>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>> >>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>> webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>>>> which >>>>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>>>> error >>>>>>>>>> handler could potentially deadlock if its thread already >>>>>>>>>> holds >>>>>>>>>> the lock. Unsure how to resolve this, because skipping to >>>>>>>>>> take >>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>> changing the configuration as we read it. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The logging configuration is now printed in each >>>>>>>>>>>> hs_err >>>>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>> >>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>> Logging info >>>>>>>>>>>> is printed after VM Arguments and Whitebox, and before >>>>>>>>>>>> Environment Variables. >>>>>>>>>>>> >>>>>>>>>>>> VM Arguments: >>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>> >>>>>>>>>>>> Logging: >>>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>>> warning, error >>>>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>>>> timemillis >>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>> biasedlocking, >>>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>> exceptions, >>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, itables, >>>>>>>>>>>> jni, >>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>>> preorder, >>>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>>> safepoint, >>>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>>> Log output configuration: >>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>> >>>>>>>>>>>> Environment Variables: >>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>> >>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>> >>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>> OS=Linux >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From mandy.chung at oracle.com Thu Apr 14 17:55:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Apr 2016 12:55:54 -0500 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <8492DC62-0397-44E7-A987-24364140EC5C@oracle.com> References: <570E690B.2060703@oracle.com> <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> <570E81A0.5050904@oracle.com> <0980D0EB-BAF1-4C76-9A82-D3F6BCCFA423@oracle.com> <8492DC62-0397-44E7-A987-24364140EC5C@oracle.com> Message-ID: > On Apr 14, 2016, at 10:38 AM, Chris Hegarty wrote: > > Mandy, > > The webrev has been updated in-place > http://cr.openjdk.java.net/~chegar/8137058/ > http://cr.openjdk.java.net/~chegar/8137058/jdk_incremental.diffs > Looks good. Thanks for making the change. > All 'core', 'pit', and 'hotspot' testsets have been successfully run on > Mac, Linux, Windows, and Solaris. > > On 13 Apr 2016, at 18:43, Mandy Chung wrote: > >>>> This patch will likely impact existing libraries that filter out reflection frames (IIRC Groovy and log4j may be examples) doing Class::getName().startsWith(?sun.reflect?). It may worth call out this incompatibility in JEP 260. > > I added the following note to the Risks and Assumptions section of JEP 260: > > Beyond the proposed critical APIs for `sun.reflect`, said package contains > the machinery that implements the `java.lang(.reflect)` subsystem. That > machinery will be moved to an internal, non-exported, package in the base > module. Consequently, the stack trace of reflective calls will appear > somewhat different. That is, stack frames that represent the reflective > implementation will see their class name ( `StackTraceElement.getClassName()` ) > change from `sun.reflect.XXX` to `jdk.internal.reflect.XXX`. Any code > analysing, or filtering, based on the stack trace element's class name > should be updated appropriately, to handle this. See > [8137058](https://bugs.openjdk.java.net/browse/JDK-8137058) for further > details. Thanks for this. Mandy From coleen.phillimore at oracle.com Thu Apr 14 18:17:12 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 14 Apr 2016 14:17:12 -0400 Subject: RFR: 8154235: Using deprecated flags converted to UL shows wrong hint In-Reply-To: <570F8C76.6020909@oracle.com> References: <570F8C76.6020909@oracle.com> Message-ID: <570FDEA8.9020504@oracle.com> Looks good. Coleen On 4/14/16 8:26 AM, Robbin Ehn wrote: > Hi all, > > Please review. > > When using a deprecated flag that have been converted to UL, > we print the wrong hint when it contains more than one tag. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154235 > > Thanks! > > /Robbin > > diff -r 6acb563d8621 src/share/vm/runtime/arguments.cpp > --- a/src/share/vm/runtime/arguments.cpp Thu Apr 14 08:30:37 2016 > +0200 > +++ b/src/share/vm/runtime/arguments.cpp Thu Apr 14 14:18:30 2016 > +0200 > @@ -998,7 +998,7 @@ > int max_tags = sizeof(tagSet)/sizeof(tagSet[0]); > for (int i = 0; i < max_tags && tagSet[i] != LogTag::__NO_TAG; i++) { > if (i > 0) { > - strncat(tagset_buffer, ",", max_tagset_len - > strlen(tagset_buffer)); > + strncat(tagset_buffer, "+", max_tagset_len - > strlen(tagset_buffer)); > } > strncat(tagset_buffer, LogTag::name(tagSet[i]), max_tagset_len - > strlen(tagset_buffer)); > } From gerard.ziemski at oracle.com Thu Apr 14 19:38:06 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 14 Apr 2016 14:38:06 -0500 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. In-Reply-To: <077a096cb4dd406997636081fd939f92@DEWDFE13DE09.global.corp.sap> References: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> <077a096cb4dd406997636081fd939f92@DEWDFE13DE09.global.corp.sap> Message-ID: <932CC317-7EEB-49A2-A74F-6371E137F4A6@oracle.com> hi Goetz, It appears to work as expected on 32bit - the value gets parsed into "java long?, so that?s what the max range supplies. I will test it out using our internal testing, then ask for final review. Do you mind if I assign the issue to myself, so that you can then officially review the fix? cheers > On Apr 14, 2016, at 5:23 AM, Lindenmaier, Goetz wrote: > > Oh, sorry, I missed the upper bound you are using. Max_jlong fixes the > Java exception. > > Is it ok on 32-bit if you increase the bound from max_uint32 to max_int64? > If so, your fix is fine for me. > > Best regards, > Goetz. > > > > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Donnerstag, 14. April 2016 12:14 >> To: 'Gerard Ziemski' >> Cc: hotspot-runtime-dev at openjdk.java.net >> Subject: RE: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which >> is parsed at jlong. >> >> Hi Gerard, >> >> The code you change is not the problem. The value is passed to Java code, >> and java code can't handle it: >> >> java.lang.NumberFormatException: For input string: >> "18446744073709551615" >> at >> java.lang.NumberFormatException.forInputString(java.base/NumberFormat >> Exception.java:65) >> at java.lang.Long.parseLong(java.base/Long.java:747) >> at java.lang.Long.parseLong(java.base/Long.java:872) >> at >> jdk.internal.misc.VM.saveAndRemoveProperties(java.base/VM.java:290) >> at java.lang.System.initPhase1(java.base/System.java:1865) >> >> We could change the flag to jlong / int64_t with a positive range. But I think >> size_t is best for a flag giving a memory size. >> >> Best regards, >> Goetz. >> >> >> >>> -----Original Message----- >>> From: Gerard Ziemski [mailto:gerard.ziemski at oracle.com] >>> Sent: Mittwoch, 13. April 2016 18:30 >>> To: Lindenmaier, Goetz >>> Cc: hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize >> which >>> is parsed at jlong. >>> >>> hi Goetz, >>> >>> How about if we just change the MaxDirectMemorySize type to uint64_t, >> like >>> so: >>> >>> http://cr.openjdk.java.net/~gziemski/8153835_rev1/ >>> >>> >>> cheers >>> >>> >>>> On Apr 13, 2016, at 8:25 AM, Lindenmaier, Goetz >>> wrote: >>>> >>>> Hi, >>>> >>>> could someone please have a look at this tiny issue? And sponsor? >>>> >>>> Thanks, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: Lindenmaier, Goetz >>>>> Sent: Freitag, 8. April 2016 10:53 >>>>> To: hotspot-runtime-dev at openjdk.java.net >>>>> Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize >> which >>> is >>>>> parsed at jlong. >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> The upper limit of the range for flag MaxDirectMemorySize is >>> MAX_SIZE_T. >>>>> >>>>> The flag is used to set a property that is parsed into a long. Thus, the >> max >>>>> >>>>> value on 64-bit platforms is too large. >>>>> >>>>> Fix: Limit the range to max_jlong, too. >>>>> >>>>> >>>>> >>>>> Please review this change. I please need a sponsor. >>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8153835- >> MaxDMSz/webrev.01/ >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> >>>> > From david.holmes at oracle.com Fri Apr 15 04:32:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Apr 2016 14:32:19 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <570FB328.5020902@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> Message-ID: <57106ED3.5090002@oracle.com> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: > Roger, > Thanks for your comment! > > David, > >>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>> a new JVM function this way. > > I tried to call Thread#setName() after initializing VM (before calling > main method), > I could set native thread name. > However, DestroyJavaVM() calls AttachCurrentThread(). So we can't set > native thread name for DestroyJavaVM. Right - I came to the same realization earlier this morning. Which, unfortunately, takes me back to the basic premise here that we don't set the name of threads not created by the JVM. The fact that the "main" thread is not tagged as being a JNI-attached thread seems accidental to me - so JVM_SetNativeThreadName is only working by accident for the initial attach, and can't be used for the DestroyJavaVM part - which leaves the thread inconsistently named at the native level. I'm afraid my view here is that the launcher has to be treated like any other process that might host a JVM. If it wants to name its native threads then it is free to do so, but I would not be exporting a function from the JVM to do that - it would have to use the OS specific API's for that on a platform-by-platform basis. Sorry. David ----- > > > Thanks, > > Yasumasa > > > On 2016/04/14 23:24, Roger Riggs wrote: >> Hi, >> >> Comments: >> >> jvm.h: The function names are too similar but perform different >> functions: >> >> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >> >> - The first function applies to the current thread, the second one a >> specific java thread. >> It would seem useful for there to be a comment somewhere about what >> the new function does. >> >> windows/native/libjli/java_md.c: line 408 casts to (void*) instead of >> (SetNativeThreadName0_t) >> as is done on unix and mac. >> >> - macosx/native/libjli/java_md_macosx.c: >> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at line 730 >> - 738 Incorrect indentation; if possible keep the cast on the same >> line as dlsym... >> >> $.02, Roger >> >> >> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>> That is an interesting question which I haven't had time to check - >>>> sorry. If the main thread is considered a JNI-attached thread then >>>> my suggestion wont work. If it isn't then my suggestion should work >>>> (but it means we have an inconsistency in our treatment of >>>> JNI-attached threads :( ) >>> >>> I ran following program on JDK 9 EA b112, and I confirmed native >>> thread name (test) was set. >>> --------- >>> public class Sleep{ >>> public static void main(String[] args) throws Exception{ >>> Thread.currentThread().setName("test"); >>> Thread.sleep(3600000); >>> } >>> } >>> --------- >>> >>> >>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>> a new JVM function this way. >>> >>> I will update webrev after hearing Kumar's comment. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/14 21:32, David Holmes wrote: >>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>> Hi, >>>>> >>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>> Hi, >>>>>> >>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for your comment. >>>>>>> >>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>> uses it >>>>>>> in new webrev. >>>>>> >>>>>> First the launcher belongs to another team so core-libs will need to >>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>> >>>>> Thanks! >>>>> I'm waiting to review :-) >>>>> >>>>> >>>>>> Personally I would have used a Java upcall to Thread.setName rather >>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes needed in >>>>>> that case. >>>>> >>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>> Thread#init(), >>>>> but I could not change native thread name. >>>> >>>> At Thread.init time the thread is not alive, which is why the native >>>> name is not set. >>>> >>>>> I guess that caller of main() is JNI attached thread. >>>> >>>> That is an interesting question which I haven't had time to check - >>>> sorry. If the main thread is considered a JNI-attached thread then >>>> my suggestion wont work. If it isn't then my suggestion should work >>>> (but it means we have an inconsistency in our treatment of >>>> JNI-attached threads :( ) >>>> >>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>> a new JVM function this way. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Thus I think that we have to provide a function to set native >>>>> thread name. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Could you review again? >>>>>>> >>>>>>> - hotspot: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>> >>>>>>> - jdk: >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>> I'll answer on this original thread as well ... >>>>>>>> >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> Please see my updates to the bug (sorry have been on vacation). >>>>>>>> This >>>>>>>> needs to be done in the launcher to be correct as we do not set the >>>>>>>> name of threads that attach via JNI, which includes the "main" >>>>>>>> thread. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>> Thanks Robbin, >>>>>>>>> >>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>> >>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>> >>>>>>>>>> /Robbin >>>>>>>>>> >>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>> >>>>>>>>>>> Thanks, looks good. >>>>>>>>>>> >>>>>>>>>>> /Robbin >>>>>>>>>>> >>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>> Could you review it? >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>> >: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>> >>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Native thread name is the same to thread name in Thread >>>>>>>>>>>>>> class. >>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>>>>>>>> will be >>>>>>>>>>>>>> set at >>>>>>>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>> >> I think that the place of setting thrrad name should >>>>>>>>>>>>>> be the >>>>>>>>>>>>>> same. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>> thread, >>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>> >>>>>>>>>>>>>> true, >>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>> > - >>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>> > + >>>>>>>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>> > + >>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and naming >>>>>>>>>>>>>> this >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> just >>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>>>>> process) is >>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> The native main thread in the process is not JavaThread. >>>>>>>>>>>>>> It is >>>>>>>>>>>>>> waiting >>>>>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>> think that >>>>>>>>>>>>>> we do >>>>>>>>>>>>>> not >>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>> java and >>>>>>>>>>>>>> native >>>>>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>> that we >>>>>>>>>>>>>> have to >>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> No >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>> >>>>>>>>>>>>> /Robbin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>> >> > > For consistency, main thread should have native >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> name. >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> From goetz.lindenmaier at sap.com Fri Apr 15 06:41:37 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Apr 2016 06:41:37 +0000 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. In-Reply-To: <932CC317-7EEB-49A2-A74F-6371E137F4A6@oracle.com> References: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> <077a096cb4dd406997636081fd939f92@DEWDFE13DE09.global.corp.sap> <932CC317-7EEB-49A2-A74F-6371E137F4A6@oracle.com> Message-ID: Hi Gerard, that's fine, assign it to yourself. Also, you can consider it reviewed. Best regards and thanks for your help, Goetz. > -----Original Message----- > From: Gerard Ziemski [mailto:gerard.ziemski at oracle.com] > Sent: Donnerstag, 14. April 2016 21:38 > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which > is parsed at jlong. > > hi Goetz, > > It appears to work as expected on 32bit - the value gets parsed into "java > long?, so that?s what the max range supplies. > > I will test it out using our internal testing, then ask for final review. > > Do you mind if I assign the issue to myself, so that you can then officially > review the fix? > > > cheers > > > On Apr 14, 2016, at 5:23 AM, Lindenmaier, Goetz > wrote: > > > > Oh, sorry, I missed the upper bound you are using. Max_jlong fixes the > > Java exception. > > > > Is it ok on 32-bit if you increase the bound from max_uint32 to max_int64? > > If so, your fix is fine for me. > > > > Best regards, > > Goetz. > > > > > > > > > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Donnerstag, 14. April 2016 12:14 > >> To: 'Gerard Ziemski' > >> Cc: hotspot-runtime-dev at openjdk.java.net > >> Subject: RE: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize > which > >> is parsed at jlong. > >> > >> Hi Gerard, > >> > >> The code you change is not the problem. The value is passed to Java code, > >> and java code can't handle it: > >> > >> java.lang.NumberFormatException: For input string: > >> "18446744073709551615" > >> at > >> > java.lang.NumberFormatException.forInputString(java.base/NumberFormat > >> Exception.java:65) > >> at java.lang.Long.parseLong(java.base/Long.java:747) > >> at java.lang.Long.parseLong(java.base/Long.java:872) > >> at > >> jdk.internal.misc.VM.saveAndRemoveProperties(java.base/VM.java:290) > >> at java.lang.System.initPhase1(java.base/System.java:1865) > >> > >> We could change the flag to jlong / int64_t with a positive range. But I > think > >> size_t is best for a flag giving a memory size. > >> > >> Best regards, > >> Goetz. > >> > >> > >> > >>> -----Original Message----- > >>> From: Gerard Ziemski [mailto:gerard.ziemski at oracle.com] > >>> Sent: Mittwoch, 13. April 2016 18:30 > >>> To: Lindenmaier, Goetz > >>> Cc: hotspot-runtime-dev at openjdk.java.net > >>> Subject: Re: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize > >> which > >>> is parsed at jlong. > >>> > >>> hi Goetz, > >>> > >>> How about if we just change the MaxDirectMemorySize type to > uint64_t, > >> like > >>> so: > >>> > >>> http://cr.openjdk.java.net/~gziemski/8153835_rev1/ > >>> > >>> > >>> cheers > >>> > >>> > >>>> On Apr 13, 2016, at 8:25 AM, Lindenmaier, Goetz > >>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> could someone please have a look at this tiny issue? And sponsor? > >>>> > >>>> Thanks, > >>>> Goetz. > >>>> > >>>>> -----Original Message----- > >>>>> From: Lindenmaier, Goetz > >>>>> Sent: Freitag, 8. April 2016 10:53 > >>>>> To: hotspot-runtime-dev at openjdk.java.net > >>>>> Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize > >> which > >>> is > >>>>> parsed at jlong. > >>>>> > >>>>> Hi, > >>>>> > >>>>> > >>>>> > >>>>> The upper limit of the range for flag MaxDirectMemorySize is > >>> MAX_SIZE_T. > >>>>> > >>>>> The flag is used to set a property that is parsed into a long. Thus, the > >> max > >>>>> > >>>>> value on 64-bit platforms is too large. > >>>>> > >>>>> Fix: Limit the range to max_jlong, too. > >>>>> > >>>>> > >>>>> > >>>>> Please review this change. I please need a sponsor. > >>>>> > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8153835- > >> MaxDMSz/webrev.01/ > >>>>> > >>>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > > From robbin.ehn at oracle.com Fri Apr 15 07:10:29 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 15 Apr 2016 09:10:29 +0200 Subject: RFR: 8154235: Using deprecated flags converted to UL shows wrong hint In-Reply-To: <570FDEA8.9020504@oracle.com> References: <570F8C76.6020909@oracle.com> <570FDEA8.9020504@oracle.com> Message-ID: <571093E5.2030401@oracle.com> Thanks Coleen! /Robbin On 04/14/2016 08:17 PM, Coleen Phillimore wrote: > Looks good. > Coleen > > On 4/14/16 8:26 AM, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> When using a deprecated flag that have been converted to UL, >> we print the wrong hint when it contains more than one tag. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154235 >> >> Thanks! >> >> /Robbin >> >> diff -r 6acb563d8621 src/share/vm/runtime/arguments.cpp >> --- a/src/share/vm/runtime/arguments.cpp Thu Apr 14 08:30:37 2016 >> +0200 >> +++ b/src/share/vm/runtime/arguments.cpp Thu Apr 14 14:18:30 2016 >> +0200 >> @@ -998,7 +998,7 @@ >> int max_tags = sizeof(tagSet)/sizeof(tagSet[0]); >> for (int i = 0; i < max_tags && tagSet[i] != LogTag::__NO_TAG; i++) { >> if (i > 0) { >> - strncat(tagset_buffer, ",", max_tagset_len - >> strlen(tagset_buffer)); >> + strncat(tagset_buffer, "+", max_tagset_len - >> strlen(tagset_buffer)); >> } >> strncat(tagset_buffer, LogTag::name(tagSet[i]), max_tagset_len - >> strlen(tagset_buffer)); >> } > From marcus.larsson at oracle.com Fri Apr 15 07:54:33 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 15 Apr 2016 09:54:33 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570FC3B2.4040805@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> Message-ID: <57109E39.4000404@oracle.com> Hi, On 04/14/2016 06:22 PM, Max Ockner wrote: > new webrev: > http://cr.openjdk.java.net/~mockner/8151526.05/ logConfiguration.cpp: unnecessary #include on line 39 logConfiguration.hpp: typo in comment, 'ad' -> 'and' I don't need to see a new webrev for this. Thanks for fixing! Marcus > - new describe_* methods are now private > - VMError is now a friend class in logConfiguration. > > Thanks, > Max > > On 4/14/2016 4:30 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/13/2016 09:33 PM, Max Ockner wrote: >>> Hello, >>> I have made these changes. >>> - refactored describe into a portion which uses locking and one >>> that does not. >>> - in the print_vm_info function in vmError.cpp, describe() is used, >>> since this function is called while the program is running. >>> - in the report function, the describe_no_lock and >>> describe_with_lock functions are both used without taking a lock. If >>> it doesnt crash, then fantastic. If it does crash, the error handler >>> will skip this step anyway. >>> >>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >> >> I suggest making the new two functions private in LogConfiguration, >> and friending VMError, instead of keeping them public. That should >> reduce confusion about which describe-method to use, and prevent >> misuse of the describe_with_lock in other places. >> >> Otherwise this looks good. >> >> Thanks, >> Marcus >> >>> >>> Thanks, >>> Max >>> >>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>> Hey, >>>> >>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>> Marcus, >>>>> >>>>> I just spoke with Coleen about this. If I attempt to print >>>>> configuration during a crash without lock and it crashes, the >>>>> error handler will eat it up and start at the next step. It would >>>>> be fun to write a locking mechanism, but this seems better to me. >>>>> >>>>> I will continue to call describe() from VM.info, but I will >>>>> refactor the code in describe so that all of the information can >>>>> be printed easily without taking a lock. For a crash, I'll use the >>>>> refactored print functions to print all the necessary information >>>>> without taking a lock. Even if the vm crashes during this step it >>>>> is not such a bad thing because of the robust error handler. >>>> >>>> Alright, that sounds good! >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>> Hi Max, >>>>>> >>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>> Hello again, >>>>>>> >>>>>>> I have looked into this and I see a possible workaround to the >>>>>>> issue raised by Marcus: >>>>>>> >>>>>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>>>>> might be problematic for the error handler. I suppose the error >>>>>>> handler could potentially deadlock if its thread already holds >>>>>>> the lock. Unsure how to resolve this, because skipping to take >>>>>>> the lock means that we might crash due to another thread >>>>>>> changing the configuration as we read it. >>>>>>> >>>>>>> >>>>>>> My proposed solution is this: >>>>>>> >>>>>>> If the ConfigurationLock is held by another thread during the >>>>>>> crash, then I think we could print "Log configuration can not be >>>>>>> accessed because ConfigurationLock is currently held by another >>>>>>> thread" or something similar. If the ConfigurationLock can be >>>>>>> taken by the current thread, then print the configuration. >>>>>>> >>>>>>> We can accomplish this as follows: >>>>>>> >>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe >>>>>>> class extending ConfigurationLock. >>>>>>> >>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>> private: >>>>>>> bool _success; >>>>>>> public: >>>>>>> ConfigurationLockMaybe() { >>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>> } >>>>>>> ~ConfigurationLock() { >>>>>>> if(_success){_semaphore.signal();} >>>>>>> } >>>>>>> bool has_lock(){return _success;} >>>>>>> }; >>>>>>> >>>>>>> _semaphore is a static var in ConfigurationLock, so the same >>>>>>> copy is accessed in child classes. >>>>>>> >>>>>>> Another method LogConfiguration::describe_on_crash(outputStream* >>>>>>> out) can use ConfigurationLockMaybe to attempt to print the >>>>>>> configuration. >>>>>>> >>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>> LogConfiguration::describe_on_crash. >>>>>> >>>>>> Sounds good to me. >>>>>> >>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>> better suggestion. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> Max >>>>>>> >>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>> I missed this before. I'm going to investigate. >>>>>>>> Max >>>>>>>> >>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> I forgot to respond to this: >>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>> (Replies in line) >>>>>>>>>>>> >>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>> >>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>> >>>>>>>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>>>>>>> >>>>>>>>>>>> Just going by what we currently put in the hs_err file, >>>>>>>>>>>> I think >>>>>>>>>>>> this may be the first "Do we really need" we've ever >>>>>>>>>>>> asked for >>>>>>>>>>>> this type of change. >>>>>>>>>>>> >>>>>>>>>>>> All joking aside, I think it is a good idea to direct >>>>>>>>>>>> users >>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>> >>>>>>>>>>>>> Also: I assume what you print is the Log state as it >>>>>>>>>>>>> is at the >>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. with >>>>>>>>>>>>> jcmd, >>>>>>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>> >>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>> require a >>>>>>>>>>>> framework change. It does not look like any marks are >>>>>>>>>>>> made when >>>>>>>>>>>> the LogConfiguration changes during runtime, and we >>>>>>>>>>>> would need >>>>>>>>>>>> to record that in order to know what to print when we >>>>>>>>>>>> dump into >>>>>>>>>>>> hs_err. >>>>>>>>>>> >>>>>>>>>>> Yes, this would required the framework to keep some sort >>>>>>>>>>> of log >>>>>>>>>>> of configuration changes. Is there value in knowing that >>>>>>>>>>> the log >>>>>>>>>>> configuration changed since startup? >>>>>>>>>> >>>>>>>>>> I think it is useful along with other information. An >>>>>>>>>> example case: >>>>>>>>>> >>>>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>>>> acquired or >>>>>>>>>> released. In a subsystem like this, the action which >>>>>>>>>> dooms the vm >>>>>>>>>> may not cause an immediate crash. This leaves time for >>>>>>>>>> logging to >>>>>>>>>> turn on or off in between the bad action and the crash. >>>>>>>>>> If you >>>>>>>>>> don't know when logging was active and when it was not, >>>>>>>>>> then the >>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>> information. You may not see the message that has the >>>>>>>>>> answer for >>>>>>>>>> you because it was not logged, though the action may have >>>>>>>>>> occurred. >>>>>>>>>> >>>>>>>>>> However, if we don't have the framework support for this >>>>>>>>>> then I >>>>>>>>>> believe it should be added later. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is a good example. A small easy solution, as I mentioned >>>>>>>>>> before, could be just to distinguish between "logging >>>>>>>>>> parameters stable since startup" and "logging parameters >>>>>>>>>> changed at some time". That way you would at least know >>>>>>>>>> whether to trust the logging output. >>>>>>>>>> >>>>>>>>>> But you are right, this can be added later. >>>>>>>>> >>>>>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 >>>>>>>>> for this. >>>>>>>>> >>>>>>>>> Max: Did you see my comments about the ConfigurationLock? It >>>>>>>>> was an inline reply to your first mail. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Kind Regards, Thomas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max >>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>> > >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> Please review another Unified Logging change. They >>>>>>>>>>>>> are >>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>> the error >>>>>>>>>>> handler could potentially deadlock if its thread already >>>>>>>>>>> holds >>>>>>>>>>> the lock. Unsure how to resolve this, because skipping >>>>>>>>>>> to take >>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Marcus >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The logging configuration is now printed in each >>>>>>>>>>>>> hs_err >>>>>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>> >>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>> Logging info >>>>>>>>>>>>> is printed after VM Arguments and Whitebox, and >>>>>>>>>>>>> before >>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>> >>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>> >>>>>>>>>>>>> Logging: >>>>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>>>> warning, error >>>>>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>>>>> timemillis >>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags >>>>>>>>>>>>> (tg) >>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>> exceptions, >>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>>>> preorder, >>>>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>>>> safepoint, >>>>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>>>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>> >>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>> >>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>> >>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From yasuenag at gmail.com Fri Apr 15 08:53:24 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 15 Apr 2016 17:53:24 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57106ED3.5090002@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> Message-ID: <5710AC04.3080909@gmail.com> Hi David, > The fact that the "main" thread is not tagged as being a JNI-attached thread seems accidental to me Should I file it to JBS? I think that we can fix as below: --------------- diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 @@ -3592,7 +3592,7 @@ #endif // INCLUDE_JVMCI // Attach the main thread to this os thread - JavaThread* main_thread = new JavaThread(); + JavaThread* main_thread = new JavaThread(true); main_thread->set_thread_state(_thread_in_vm); main_thread->initialize_thread_current(); // must do this before set_active_handles @@ -3776,6 +3776,9 @@ // Notify JVMTI agents that VM initialization is complete - nop if no agents. JvmtiExport::post_vm_initialized(); + // Change attach status to "attached" + main_thread->set_done_attaching_via_jni(); + if (TRACE_START() != JNI_OK) { vm_exit_during_initialization("Failed to start tracing backend."); } --------------- > If it wants to name its native threads then it is free to do so, Currently, JVM_SetNativeThreadName() cannot change native thread name when the caller thread is JNI-attached thread. However, I think that it should be changed if Java developer calls Thread#setName() explicitly. It is not the same of changing native thread name at Threads::create_vm(). If it is allowed, I want to fix SetNativeThreadName() as below. What do you think about this? --------------- --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 @@ -3187,7 +3187,7 @@ JavaThread* thr = java_lang_Thread::thread(java_thread); // Thread naming only supported for the current thread, doesn't work for // target threads. - if (Thread::current() == thr && !thr->has_attached_via_jni()) { + if (Thread::current() == thr) { // we don't set the name of an attached thread to avoid stepping // on other programs const char *thread_name = java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); --------------- Thanks, Yasumasa On 2016/04/15 13:32, David Holmes wrote: > > > On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >> Roger, >> Thanks for your comment! >> >> David, >> >>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>> a new JVM function this way. >> >> I tried to call Thread#setName() after initializing VM (before calling >> main method), >> I could set native thread name. >> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't set >> native thread name for DestroyJavaVM. > > Right - I came to the same realization earlier this morning. Which, unfortunately, takes me back to the basic premise here that we don't set the name of threads not created by the JVM. The fact that the "main" thread is not tagged as being a JNI-attached thread seems accidental to me - so JVM_SetNativeThreadName is only working by accident for the initial attach, and can't be used for the DestroyJavaVM part - which leaves the thread inconsistently named at the native level. > > I'm afraid my view here is that the launcher has to be treated like any other process that might host a JVM. If it wants to name its native threads then it is free to do so, but I would not be exporting a function from the JVM to do that - it would have to use the OS specific API's for that on a platform-by-platform basis. > > Sorry. > > David > ----- > > >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/14 23:24, Roger Riggs wrote: >>> Hi, >>> >>> Comments: >>> >>> jvm.h: The function names are too similar but perform different >>> functions: >>> >>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>> >>> - The first function applies to the current thread, the second one a >>> specific java thread. >>> It would seem useful for there to be a comment somewhere about what >>> the new function does. >>> >>> windows/native/libjli/java_md.c: line 408 casts to (void*) instead of >>> (SetNativeThreadName0_t) >>> as is done on unix and mac. >>> >>> - macosx/native/libjli/java_md_macosx.c: >>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at line 730 >>> - 738 Incorrect indentation; if possible keep the cast on the same >>> line as dlsym... >>> >>> $.02, Roger >>> >>> >>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>> That is an interesting question which I haven't had time to check - >>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>> (but it means we have an inconsistency in our treatment of >>>>> JNI-attached threads :( ) >>>> >>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>> thread name (test) was set. >>>> --------- >>>> public class Sleep{ >>>> public static void main(String[] args) throws Exception{ >>>> Thread.currentThread().setName("test"); >>>> Thread.sleep(3600000); >>>> } >>>> } >>>> --------- >>>> >>>> >>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>> a new JVM function this way. >>>> >>>> I will update webrev after hearing Kumar's comment. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/14 21:32, David Holmes wrote: >>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>> Hi, >>>>>> >>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for your comment. >>>>>>>> >>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>> uses it >>>>>>>> in new webrev. >>>>>>> >>>>>>> First the launcher belongs to another team so core-libs will need to >>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>> >>>>>> Thanks! >>>>>> I'm waiting to review :-) >>>>>> >>>>>> >>>>>>> Personally I would have used a Java upcall to Thread.setName rather >>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes needed in >>>>>>> that case. >>>>>> >>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>> Thread#init(), >>>>>> but I could not change native thread name. >>>>> >>>>> At Thread.init time the thread is not alive, which is why the native >>>>> name is not set. >>>>> >>>>>> I guess that caller of main() is JNI attached thread. >>>>> >>>>> That is an interesting question which I haven't had time to check - >>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>> (but it means we have an inconsistency in our treatment of >>>>> JNI-attached threads :( ) >>>>> >>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>> a new JVM function this way. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Thus I think that we have to provide a function to set native >>>>>> thread name. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>> >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Could you review again? >>>>>>>> >>>>>>>> - hotspot: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>> >>>>>>>> - jdk: >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>> >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> Please see my updates to the bug (sorry have been on vacation). >>>>>>>>> This >>>>>>>>> needs to be done in the launcher to be correct as we do not set the >>>>>>>>> name of threads that attach via JNI, which includes the "main" >>>>>>>>> thread. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Thanks Robbin, >>>>>>>>>> >>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>> >>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>> >>>>>>>>>>> /Robbin >>>>>>>>>>> >>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>> >>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>> >>>>>>>>>>>> /Robbin >>>>>>>>>>>> >>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>> >: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Native thread name is the same to thread name in Thread >>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>> >> If you create new thread in Java app, native thread name >>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>> >> I think that the place of setting thrrad name should >>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and naming >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> just >>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> The native main thread in the process is not JavaThread. >>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > It would be nice with something like 'Java Main Thread'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. Apache >>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> No >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main thread is >>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>> >> > > For consistency, main thread should have native >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> From david.holmes at oracle.com Fri Apr 15 10:16:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Apr 2016 20:16:30 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5710AC04.3080909@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> Message-ID: <5710BF7E.6090206@oracle.com> Hi Yasumasa, On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: > Hi David, > >> The fact that the "main" thread is not tagged as being a JNI-attached >> thread seems accidental to me > > Should I file it to JBS? I think it is a bug based on the comment here: JavaThread(bool is_attaching_via_jni = false); // for main thread and JNI attached threads Though that will introduce a change in behaviour by itself as setName will no longer set the native name for the main thread. > I think that we can fix as below: > --------------- > diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp > --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 > +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 > @@ -3592,7 +3592,7 @@ > #endif // INCLUDE_JVMCI > > // Attach the main thread to this os thread > - JavaThread* main_thread = new JavaThread(); > + JavaThread* main_thread = new JavaThread(true); > main_thread->set_thread_state(_thread_in_vm); > main_thread->initialize_thread_current(); > // must do this before set_active_handles > @@ -3776,6 +3776,9 @@ > // Notify JVMTI agents that VM initialization is complete - nop if > no agents. > JvmtiExport::post_vm_initialized(); > > + // Change attach status to "attached" > + main_thread->set_done_attaching_via_jni(); > + I think we can do this straight after the JavaThread constructor. > if (TRACE_START() != JNI_OK) { > vm_exit_during_initialization("Failed to start tracing backend."); > } > --------------- > > >> If it wants to name its native threads then it is free to do so, > > Currently, JVM_SetNativeThreadName() cannot change native thread name > when the caller thread is JNI-attached thread. > However, I think that it should be changed if Java developer calls > Thread#setName() explicitly. > It is not the same of changing native thread name at Threads::create_vm(). > > If it is allowed, I want to fix SetNativeThreadName() as below. > What do you think about this? The decision to not change the name of JNI-attached threads was a deliberate one** - this functionality originated with the OSX port and it was reported that the initial feedback with this feature was to ensure it didn't mess with thread names that had been set by the host process. If we do as you propose then we will just have an inconsistency for people to complain about: "why does my native thread only have a name if I call cur.setName(cur.getName()) ?" ** If you follow the bugs and related discussions on this, the semantics and limitations (truncation, current thread only, non-JNI threads only) of setting the native thread name were supposed to be documented in the release notes - but as far as I can see that never happened. :( My position on this remains that if it is desirable for the main thread (and DestroyJavaVM thread) to have native names then the launcher needs to be setting them using the available platform APIs. Unfortunately this is complicated - as evidenced by the VM code for this - due to the need to verify API availability. Any change in behaviour in relation to Thread.setName would have to go through our CCC process I think. But a change in the launcher would not. Sorry. David ----- > --------------- > --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 > +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 > @@ -3187,7 +3187,7 @@ > JavaThread* thr = java_lang_Thread::thread(java_thread); > // Thread naming only supported for the current thread, doesn't work > for > // target threads. > - if (Thread::current() == thr && !thr->has_attached_via_jni()) { > + if (Thread::current() == thr) { > // we don't set the name of an attached thread to avoid stepping > // on other programs > const char *thread_name = > java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); > --------------- > > > Thanks, > > Yasumasa > > > On 2016/04/15 13:32, David Holmes wrote: >> >> >> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>> Roger, >>> Thanks for your comment! >>> >>> David, >>> >>>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>>> a new JVM function this way. >>> >>> I tried to call Thread#setName() after initializing VM (before calling >>> main method), >>> I could set native thread name. >>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't set >>> native thread name for DestroyJavaVM. >> >> Right - I came to the same realization earlier this morning. Which, >> unfortunately, takes me back to the basic premise here that we don't >> set the name of threads not created by the JVM. The fact that the >> "main" thread is not tagged as being a JNI-attached thread seems >> accidental to me - so JVM_SetNativeThreadName is only working by >> accident for the initial attach, and can't be used for the >> DestroyJavaVM part - which leaves the thread inconsistently named at >> the native level. >> >> I'm afraid my view here is that the launcher has to be treated like >> any other process that might host a JVM. If it wants to name its >> native threads then it is free to do so, but I would not be exporting >> a function from the JVM to do that - it would have to use the OS >> specific API's for that on a platform-by-platform basis. >> >> Sorry. >> >> David >> ----- >> >> >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/14 23:24, Roger Riggs wrote: >>>> Hi, >>>> >>>> Comments: >>>> >>>> jvm.h: The function names are too similar but perform different >>>> functions: >>>> >>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>> >>>> - The first function applies to the current thread, the second one a >>>> specific java thread. >>>> It would seem useful for there to be a comment somewhere about what >>>> the new function does. >>>> >>>> windows/native/libjli/java_md.c: line 408 casts to (void*) instead of >>>> (SetNativeThreadName0_t) >>>> as is done on unix and mac. >>>> >>>> - macosx/native/libjli/java_md_macosx.c: >>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>> line 730 >>>> - 738 Incorrect indentation; if possible keep the cast on the same >>>> line as dlsym... >>>> >>>> $.02, Roger >>>> >>>> >>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>> That is an interesting question which I haven't had time to check - >>>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>>> (but it means we have an inconsistency in our treatment of >>>>>> JNI-attached threads :( ) >>>>> >>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>> thread name (test) was set. >>>>> --------- >>>>> public class Sleep{ >>>>> public static void main(String[] args) throws Exception{ >>>>> Thread.currentThread().setName("test"); >>>>> Thread.sleep(3600000); >>>>> } >>>>> } >>>>> --------- >>>>> >>>>> >>>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>>> a new JVM function this way. >>>>> >>>>> I will update webrev after hearing Kumar's comment. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thanks for your comment. >>>>>>>>> >>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>> uses it >>>>>>>>> in new webrev. >>>>>>>> >>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>> need to >>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>> >>>>>>> Thanks! >>>>>>> I'm waiting to review :-) >>>>>>> >>>>>>> >>>>>>>> Personally I would have used a Java upcall to Thread.setName rather >>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>> needed in >>>>>>>> that case. >>>>>>> >>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>> Thread#init(), >>>>>>> but I could not change native thread name. >>>>>> >>>>>> At Thread.init time the thread is not alive, which is why the native >>>>>> name is not set. >>>>>> >>>>>>> I guess that caller of main() is JNI attached thread. >>>>>> >>>>>> That is an interesting question which I haven't had time to check - >>>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>>> (but it means we have an inconsistency in our treatment of >>>>>> JNI-attached threads :( ) >>>>>> >>>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>>> a new JVM function this way. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Thus I think that we have to provide a function to set native >>>>>>> thread name. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Could you review again? >>>>>>>>> >>>>>>>>> - hotspot: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>> >>>>>>>>> >>>>>>>>> - jdk: >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>> >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> Please see my updates to the bug (sorry have been on vacation). >>>>>>>>>> This >>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>> set the >>>>>>>>>> name of threads that attach via JNI, which includes the "main" >>>>>>>>>> thread. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> Thanks Robbin, >>>>>>>>>>> >>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>> >>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>> >>>>>>>>>>>> /Robbin >>>>>>>>>>>> >>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>> >>>>>>>>>>>>> /Robbin >>>>>>>>>>>>> >>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>> >> If you create new thread in Java app, native thread >>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name should >>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and naming >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>> >> > > For consistency, main thread should have native >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>> From yasuenag at gmail.com Fri Apr 15 13:20:06 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 15 Apr 2016 22:20:06 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5710BF7E.6090206@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> Message-ID: <5710EA86.6010400@gmail.com> Hi David, > I think it is a bug based on the comment here: > > JavaThread(bool is_attaching_via_jni = false); // for main thread and JNI attached threads I filed it to JBS as JDK-8154331. I will send review request to hotspot-runtime-dev. > Though that will introduce a change in behaviour by itself as setName will no longer set the native name for the main thread. I know. I checked changeset history. JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is backported JDK 8. However, this function seems to be called from Thread#setNativeName() only. In addition, Thread#setNativeName() is private method. Thus I think that we can add an argument to JVM_SetNativeThreadName() for force setting. (e.g. "bool forced") It makes a change of JVM API. However, this function is NOT public, so I think we can add one more argument. What do you think about this? If it is accepted, we can set native thread name from Java launcher. Thanks, Yasumasa On 2016/04/15 19:16, David Holmes wrote: > Hi Yasumasa, > > On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >> Hi David, >> >>> The fact that the "main" thread is not tagged as being a JNI-attached >>> thread seems accidental to me >> >> Should I file it to JBS? > > I think it is a bug based on the comment here: > > JavaThread(bool is_attaching_via_jni = false); // for main thread and JNI attached threads > > Though that will introduce a change in behaviour by itself as setName will no longer set the native name for the main thread. > >> I think that we can fix as below: >> --------------- >> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 >> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 >> @@ -3592,7 +3592,7 @@ >> #endif // INCLUDE_JVMCI >> >> // Attach the main thread to this os thread >> - JavaThread* main_thread = new JavaThread(); >> + JavaThread* main_thread = new JavaThread(true); >> main_thread->set_thread_state(_thread_in_vm); >> main_thread->initialize_thread_current(); >> // must do this before set_active_handles >> @@ -3776,6 +3776,9 @@ >> // Notify JVMTI agents that VM initialization is complete - nop if >> no agents. >> JvmtiExport::post_vm_initialized(); >> >> + // Change attach status to "attached" >> + main_thread->set_done_attaching_via_jni(); >> + > > I think we can do this straight after the JavaThread constructor. > >> if (TRACE_START() != JNI_OK) { >> vm_exit_during_initialization("Failed to start tracing backend."); >> } >> --------------- >> >> >>> If it wants to name its native threads then it is free to do so, >> >> Currently, JVM_SetNativeThreadName() cannot change native thread name >> when the caller thread is JNI-attached thread. >> However, I think that it should be changed if Java developer calls >> Thread#setName() explicitly. >> It is not the same of changing native thread name at Threads::create_vm(). >> >> If it is allowed, I want to fix SetNativeThreadName() as below. >> What do you think about this? > > The decision to not change the name of JNI-attached threads was a deliberate one** - this functionality originated with the OSX port and it was reported that the initial feedback with this feature was to ensure it didn't mess with thread names that had been set by the host process. If we do as you propose then we will just have an inconsistency for people to complain about: "why does my native thread only have a name if I call cur.setName(cur.getName()) ?" > > ** If you follow the bugs and related discussions on this, the semantics and limitations (truncation, current thread only, non-JNI threads only) of setting the native thread name were supposed to be documented in the release notes - but as far as I can see that never happened. :( > > My position on this remains that if it is desirable for the main thread (and DestroyJavaVM thread) to have native names then the launcher needs to be setting them using the available platform APIs. Unfortunately this is complicated - as evidenced by the VM code for this - due to the need to verify API availability. > > Any change in behaviour in relation to Thread.setName would have to go through our CCC process I think. But a change in the launcher would not. > > Sorry. > > David > ----- > >> --------------- >> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 >> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 >> @@ -3187,7 +3187,7 @@ >> JavaThread* thr = java_lang_Thread::thread(java_thread); >> // Thread naming only supported for the current thread, doesn't work >> for >> // target threads. >> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >> + if (Thread::current() == thr) { >> // we don't set the name of an attached thread to avoid stepping >> // on other programs >> const char *thread_name = >> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >> --------------- >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/15 13:32, David Holmes wrote: >>> >>> >>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>> Roger, >>>> Thanks for your comment! >>>> >>>> David, >>>> >>>>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>>>> a new JVM function this way. >>>> >>>> I tried to call Thread#setName() after initializing VM (before calling >>>> main method), >>>> I could set native thread name. >>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't set >>>> native thread name for DestroyJavaVM. >>> >>> Right - I came to the same realization earlier this morning. Which, >>> unfortunately, takes me back to the basic premise here that we don't >>> set the name of threads not created by the JVM. The fact that the >>> "main" thread is not tagged as being a JNI-attached thread seems >>> accidental to me - so JVM_SetNativeThreadName is only working by >>> accident for the initial attach, and can't be used for the >>> DestroyJavaVM part - which leaves the thread inconsistently named at >>> the native level. >>> >>> I'm afraid my view here is that the launcher has to be treated like >>> any other process that might host a JVM. If it wants to name its >>> native threads then it is free to do so, but I would not be exporting >>> a function from the JVM to do that - it would have to use the OS >>> specific API's for that on a platform-by-platform basis. >>> >>> Sorry. >>> >>> David >>> ----- >>> >>> >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>> Hi, >>>>> >>>>> Comments: >>>>> >>>>> jvm.h: The function names are too similar but perform different >>>>> functions: >>>>> >>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>> >>>>> - The first function applies to the current thread, the second one a >>>>> specific java thread. >>>>> It would seem useful for there to be a comment somewhere about what >>>>> the new function does. >>>>> >>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) instead of >>>>> (SetNativeThreadName0_t) >>>>> as is done on unix and mac. >>>>> >>>>> - macosx/native/libjli/java_md_macosx.c: >>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>> line 730 >>>>> - 738 Incorrect indentation; if possible keep the cast on the same >>>>> line as dlsym... >>>>> >>>>> $.02, Roger >>>>> >>>>> >>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>> That is an interesting question which I haven't had time to check - >>>>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>> JNI-attached threads :( ) >>>>>> >>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>> thread name (test) was set. >>>>>> --------- >>>>>> public class Sleep{ >>>>>> public static void main(String[] args) throws Exception{ >>>>>> Thread.currentThread().setName("test"); >>>>>> Thread.sleep(3600000); >>>>>> } >>>>>> } >>>>>> --------- >>>>>> >>>>>> >>>>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>>>> a new JVM function this way. >>>>>> >>>>>> I will update webrev after hearing Kumar's comment. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thanks for your comment. >>>>>>>>>> >>>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>>> uses it >>>>>>>>>> in new webrev. >>>>>>>>> >>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>> need to >>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> I'm waiting to review :-) >>>>>>>> >>>>>>>> >>>>>>>>> Personally I would have used a Java upcall to Thread.setName rather >>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>> needed in >>>>>>>>> that case. >>>>>>>> >>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>> Thread#init(), >>>>>>>> but I could not change native thread name. >>>>>>> >>>>>>> At Thread.init time the thread is not alive, which is why the native >>>>>>> name is not set. >>>>>>> >>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>> >>>>>>> That is an interesting question which I haven't had time to check - >>>>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>> JNI-attached threads :( ) >>>>>>> >>>>>>> I'll wait to see what Kumar thinks about this. I don't like exposing >>>>>>> a new JVM function this way. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>> thread name. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Could you review again? >>>>>>>>>> >>>>>>>>>> - hotspot: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - jdk: >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>> >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> Please see my updates to the bug (sorry have been on vacation). >>>>>>>>>>> This >>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>> set the >>>>>>>>>>> name of threads that attach via JNI, which includes the "main" >>>>>>>>>>> thread. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>> >>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>> >>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>> >>>>>>>>>>>>> /Robbin >>>>>>>>>>>>> >>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu Mar 24 >>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native thread >>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte in VM. >>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name should >>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like this is >>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle thread_group, >>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>> > + thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and naming >>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have native >>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>> From yasuenag at gmail.com Fri Apr 15 13:23:52 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 15 Apr 2016 22:23:52 +0900 Subject: RFR: JDK-8154331: main thread should be treated as JNI-attached thread. Message-ID: <5710EB68.2080308@gmail.com> Hi all, In discussion about JDK-8152690 [1], we were found a bug. Java main thread which is started by Java launcher is not treated as JNI-attached thread. I uploaded a webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8154331/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040251.html From yasuenag at gmail.com Fri Apr 15 13:28:30 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 15 Apr 2016 22:28:30 +0900 Subject: PING: RFR: JDK-8153743: AllocateHeap() and ReallocateHeap() should use ALWAYSINLINE macro In-Reply-To: <57066B05.3030906@gmail.com> References: <57066B05.3030906@gmail.com> Message-ID: <5710EC7E.3020108@gmail.com> PING: Could you review and sponsor it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8153743/webrev.00/ Yasumasa On 2016/04/07 23:13, Yasumasa Suenaga wrote: > For force inlining, JDK-8076212 uses always_inline attribute to them. > JDK-8151593 added ALWAYSINLINE macro for force inlining. > > For consistency, and for other compiler support, AllocateHeap() and > ReallocateHeap() should use ALWAYSINLINE. > > I used ALWAYSINLINE to them, but I got error message as below; > ------------------------------ > Building target 'images' in configuration 'linux-x86_64-normal-server-release' > In file included from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/utilities/array.hpp:29:0, > from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/memory/universe.hpp:29, > from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/code/oopRecorder.hpp:28, > from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/asm/codeBuffer.hpp:28, > from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/asm/assembler.hpp:28, > from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/precompiled/precompiled.hpp:29: > /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/memory/allocation.inline.hpp:72:20: ???: always_inline function might not be inlinable [-Werror=attributes] > ALWAYSINLINE char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, > ^ > ------------------------------ > * This message includes Japanese because my environment is Japanese locale :-) > > According to GCC manual [1], non-static inline function is always compiled > on its own in the usual fashion. > However, we can compile as inline function with "inline" and "always_inline". > always_inline attribute does not imply inlining [2]. > GCC testcase [3] uses both "inline" and "always_inline" actually. > > I uploaded webrev. Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8153743/webrev.00/ > > I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html > [2] https://chromiumcodereview.appspot.com/14820003/ > [3] https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/vmx/gcc-bug-i.c?view=markup&pathrev=178730 > From coleen.phillimore at oracle.com Fri Apr 15 14:29:57 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 15 Apr 2016 10:29:57 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <57109E39.4000404@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57109E39.4000404@oracle.com> Message-ID: <5710FAE5.7090000@oracle.com> Max, I got this confused when looking at this because of the names. *+ STEP(395, "(printing log configuration)")* *+ if (_verbose){* *+ st->print_cr("Logging:");* *+ LogConfiguration::describe_no_lock(st);* *+ LogConfiguration::describe_with_lock(st);* *+ st->cr();* *+ }* *+ * I was thinking "wait, you don't want the lock here!" I think describe_no_lock() should be named describe_available_log_levels() describe_with_lock() should be names describe_log_configuration(). describe() should call these with the lock for the latter. Thanks, Coleen On 4/15/16 3:54 AM, Marcus Larsson wrote: > Hi, > > On 04/14/2016 06:22 PM, Max Ockner wrote: >> new webrev: >> http://cr.openjdk.java.net/~mockner/8151526.05/ > > logConfiguration.cpp: > unnecessary #include on line 39 > > logConfiguration.hpp: > typo in comment, 'ad' -> 'and' > > I don't need to see a new webrev for this. Thanks for fixing! > > Marcus > >> - new describe_* methods are now private >> - VMError is now a friend class in logConfiguration. >> >> Thanks, >> Max >> >> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>> Hello, >>>> I have made these changes. >>>> - refactored describe into a portion which uses locking and one >>>> that does not. >>>> - in the print_vm_info function in vmError.cpp, describe() is >>>> used, since this function is called while the program is running. >>>> - in the report function, the describe_no_lock and >>>> describe_with_lock functions are both used without taking a lock. >>>> If it doesnt crash, then fantastic. If it does crash, the error >>>> handler will skip this step anyway. >>>> >>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>> >>> I suggest making the new two functions private in LogConfiguration, >>> and friending VMError, instead of keeping them public. That should >>> reduce confusion about which describe-method to use, and prevent >>> misuse of the describe_with_lock in other places. >>> >>> Otherwise this looks good. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> Thanks, >>>> Max >>>> >>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>> Hey, >>>>> >>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>> Marcus, >>>>>> >>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>> configuration during a crash without lock and it crashes, the >>>>>> error handler will eat it up and start at the next step. It >>>>>> would be fun to write a locking mechanism, but this seems better >>>>>> to me. >>>>>> >>>>>> I will continue to call describe() from VM.info, but I will >>>>>> refactor the code in describe so that all of the information can >>>>>> be printed easily without taking a lock. For a crash, I'll use >>>>>> the refactored print functions to print all the necessary >>>>>> information without taking a lock. Even if the vm crashes during >>>>>> this step it is not such a bad thing because of the robust error >>>>>> handler. >>>>> >>>>> Alright, that sounds good! >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I have looked into this and I see a possible workaround to the >>>>>>>> issue raised by Marcus: >>>>>>>> >>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>> which >>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>> error >>>>>>>> handler could potentially deadlock if its thread already holds >>>>>>>> the lock. Unsure how to resolve this, because skipping to take >>>>>>>> the lock means that we might crash due to another thread >>>>>>>> changing the configuration as we read it. >>>>>>>> >>>>>>>> >>>>>>>> My proposed solution is this: >>>>>>>> >>>>>>>> If the ConfigurationLock is held by another thread during the >>>>>>>> crash, then I think we could print "Log configuration can not >>>>>>>> be accessed because ConfigurationLock is currently held by >>>>>>>> another thread" or something similar. If the ConfigurationLock >>>>>>>> can be taken by the current thread, then print the configuration. >>>>>>>> >>>>>>>> We can accomplish this as follows: >>>>>>>> >>>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe >>>>>>>> class extending ConfigurationLock. >>>>>>>> >>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>> private: >>>>>>>> bool _success; >>>>>>>> public: >>>>>>>> ConfigurationLockMaybe() { >>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>> } >>>>>>>> ~ConfigurationLock() { >>>>>>>> if(_success){_semaphore.signal();} >>>>>>>> } >>>>>>>> bool has_lock(){return _success;} >>>>>>>> }; >>>>>>>> >>>>>>>> _semaphore is a static var in ConfigurationLock, so the same >>>>>>>> copy is accessed in child classes. >>>>>>>> >>>>>>>> Another method >>>>>>>> LogConfiguration::describe_on_crash(outputStream* out) can use >>>>>>>> ConfigurationLockMaybe to attempt to print the configuration. >>>>>>>> >>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>> LogConfiguration::describe_on_crash. >>>>>>> >>>>>>> Sounds good to me. >>>>>>> >>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>>> better suggestion. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>> >>>>>>>> Max >>>>>>>> >>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>>>>>>>> >>>>>>>>>>>>> Just going by what we currently put in the hs_err >>>>>>>>>>>>> file, I think >>>>>>>>>>>>> this may be the first "Do we really need" we've ever >>>>>>>>>>>>> asked for >>>>>>>>>>>>> this type of change. >>>>>>>>>>>>> >>>>>>>>>>>>> All joking aside, I think it is a good idea to direct >>>>>>>>>>>>> users >>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>> >>>>>>>>>>>>>> Also: I assume what you print is the Log state as it >>>>>>>>>>>>>> is at the >>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. with >>>>>>>>>>>>>> jcmd, >>>>>>>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>> >>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>> require a >>>>>>>>>>>>> framework change. It does not look like any marks are >>>>>>>>>>>>> made when >>>>>>>>>>>>> the LogConfiguration changes during runtime, and we >>>>>>>>>>>>> would need >>>>>>>>>>>>> to record that in order to know what to print when we >>>>>>>>>>>>> dump into >>>>>>>>>>>>> hs_err. >>>>>>>>>>>> >>>>>>>>>>>> Yes, this would required the framework to keep some >>>>>>>>>>>> sort of log >>>>>>>>>>>> of configuration changes. Is there value in knowing >>>>>>>>>>>> that the log >>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>> >>>>>>>>>>> I think it is useful along with other information. An >>>>>>>>>>> example case: >>>>>>>>>>> >>>>>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>>>>> acquired or >>>>>>>>>>> released. In a subsystem like this, the action which >>>>>>>>>>> dooms the vm >>>>>>>>>>> may not cause an immediate crash. This leaves time for >>>>>>>>>>> logging to >>>>>>>>>>> turn on or off in between the bad action and the crash. >>>>>>>>>>> If you >>>>>>>>>>> don't know when logging was active and when it was not, >>>>>>>>>>> then the >>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>> information. You may not see the message that has the >>>>>>>>>>> answer for >>>>>>>>>>> you because it was not logged, though the action may >>>>>>>>>>> have occurred. >>>>>>>>>>> >>>>>>>>>>> However, if we don't have the framework support for this >>>>>>>>>>> then I >>>>>>>>>>> believe it should be added later. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is a good example. A small easy solution, as I >>>>>>>>>>> mentioned before, could be just to distinguish between >>>>>>>>>>> "logging parameters stable since startup" and "logging >>>>>>>>>>> parameters changed at some time". That way you would at >>>>>>>>>>> least know whether to trust the logging output. >>>>>>>>>>> >>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>> >>>>>>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 >>>>>>>>>> for this. >>>>>>>>>> >>>>>>>>>> Max: Did you see my comments about the ConfigurationLock? It >>>>>>>>>> was an inline reply to your first mail. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Max >>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>> >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> Please review another Unified Logging change. >>>>>>>>>>>>>> They are >>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>>> the error >>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>> already holds >>>>>>>>>>>> the lock. Unsure how to resolve this, because skipping >>>>>>>>>>>> to take >>>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Marcus >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The logging configuration is now printed in each >>>>>>>>>>>>>> hs_err >>>>>>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>>> Logging info >>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, and >>>>>>>>>>>>>> before >>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>> >>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>> >>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>>>>> warning, error >>>>>>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>>>>>> timemillis >>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags >>>>>>>>>>>>>> (tg) >>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>>>>> preorder, >>>>>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>>>>> safepoint, >>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, >>>>>>>>>>>>>> start, >>>>>>>>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>> >>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>> >>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From marcus.larsson at oracle.com Fri Apr 15 14:37:30 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Fri, 15 Apr 2016 16:37:30 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5710FAE5.7090000@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57109E39.4000404@oracle.com> <5710FAE5.7090000@oracle.com> Message-ID: <5710FCAA.8080107@oracle.com> Hi, On 04/15/2016 04:29 PM, Coleen Phillimore wrote: > > Max, > > I got this confused when looking at this because of the names. > > *+ STEP(395, "(printing log configuration)")* > *+ if (_verbose){* > *+ st->print_cr("Logging:");* > *+ LogConfiguration::describe_no_lock(st);* > *+ LogConfiguration::describe_with_lock(st);* > *+ st->cr();* > *+ }* > *+ * > > I was thinking "wait, you don't want the lock here!" > > I think describe_no_lock() should be named > describe_available_log_levels() > > describe_with_lock() should be names describe_log_configuration(). > > describe() should call these with the lock for the latter. In that case, can we make it describe_available() and describe_outputs()? The first function doesn't only describe levels. Thanks, Marcus > > Thanks, > Coleen > > > On 4/15/16 3:54 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/14/2016 06:22 PM, Max Ockner wrote: >>> new webrev: >>> http://cr.openjdk.java.net/~mockner/8151526.05/ >> >> logConfiguration.cpp: >> unnecessary #include on line 39 >> >> logConfiguration.hpp: >> typo in comment, 'ad' -> 'and' >> >> I don't need to see a new webrev for this. Thanks for fixing! >> >> Marcus >> >>> - new describe_* methods are now private >>> - VMError is now a friend class in logConfiguration. >>> >>> Thanks, >>> Max >>> >>> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>>> Hello, >>>>> I have made these changes. >>>>> - refactored describe into a portion which uses locking and one >>>>> that does not. >>>>> - in the print_vm_info function in vmError.cpp, describe() is >>>>> used, since this function is called while the program is running. >>>>> - in the report function, the describe_no_lock and >>>>> describe_with_lock functions are both used without taking a lock. >>>>> If it doesnt crash, then fantastic. If it does crash, the error >>>>> handler will skip this step anyway. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>>> >>>> I suggest making the new two functions private in LogConfiguration, >>>> and friending VMError, instead of keeping them public. That should >>>> reduce confusion about which describe-method to use, and prevent >>>> misuse of the describe_with_lock in other places. >>>> >>>> Otherwise this looks good. >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>>> Hey, >>>>>> >>>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>>> Marcus, >>>>>>> >>>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>>> configuration during a crash without lock and it crashes, the >>>>>>> error handler will eat it up and start at the next step. It >>>>>>> would be fun to write a locking mechanism, but this seems better >>>>>>> to me. >>>>>>> >>>>>>> I will continue to call describe() from VM.info, but I will >>>>>>> refactor the code in describe so that all of the information can >>>>>>> be printed easily without taking a lock. For a crash, I'll use >>>>>>> the refactored print functions to print all the necessary >>>>>>> information without taking a lock. Even if the vm crashes during >>>>>>> this step it is not such a bad thing because of the robust error >>>>>>> handler. >>>>>> >>>>>> Alright, that sounds good! >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>>> Hello again, >>>>>>>>> >>>>>>>>> I have looked into this and I see a possible workaround to the >>>>>>>>> issue raised by Marcus: >>>>>>>>> >>>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>>> which >>>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>>> error >>>>>>>>> handler could potentially deadlock if its thread already >>>>>>>>> holds >>>>>>>>> the lock. Unsure how to resolve this, because skipping to >>>>>>>>> take >>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>> changing the configuration as we read it. >>>>>>>>> >>>>>>>>> >>>>>>>>> My proposed solution is this: >>>>>>>>> >>>>>>>>> If the ConfigurationLock is held by another thread during the >>>>>>>>> crash, then I think we could print "Log configuration can not >>>>>>>>> be accessed because ConfigurationLock is currently held by >>>>>>>>> another thread" or something similar. If the >>>>>>>>> ConfigurationLock can be taken by the current thread, then >>>>>>>>> print the configuration. >>>>>>>>> >>>>>>>>> We can accomplish this as follows: >>>>>>>>> >>>>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe >>>>>>>>> class extending ConfigurationLock. >>>>>>>>> >>>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>>> private: >>>>>>>>> bool _success; >>>>>>>>> public: >>>>>>>>> ConfigurationLockMaybe() { >>>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>>> } >>>>>>>>> ~ConfigurationLock() { >>>>>>>>> if(_success){_semaphore.signal();} >>>>>>>>> } >>>>>>>>> bool has_lock(){return _success;} >>>>>>>>> }; >>>>>>>>> >>>>>>>>> _semaphore is a static var in ConfigurationLock, so the same >>>>>>>>> copy is accessed in child classes. >>>>>>>>> >>>>>>>>> Another method >>>>>>>>> LogConfiguration::describe_on_crash(outputStream* out) can use >>>>>>>>> ConfigurationLockMaybe to attempt to print the configuration. >>>>>>>>> >>>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>>> LogConfiguration::describe_on_crash. >>>>>>>> >>>>>>>> Sounds good to me. >>>>>>>> >>>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>>>> better suggestion. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>>> >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do we really need a list of all tags and all >>>>>>>>>>>>>>> decorators? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Just going by what we currently put in the hs_err >>>>>>>>>>>>>> file, I think >>>>>>>>>>>>>> this may be the first "Do we really need" we've ever >>>>>>>>>>>>>> asked for >>>>>>>>>>>>>> this type of change. >>>>>>>>>>>>>> >>>>>>>>>>>>>> All joking aside, I think it is a good idea to direct >>>>>>>>>>>>>> users >>>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also: I assume what you print is the Log state as it >>>>>>>>>>>>>>> is at the >>>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. with >>>>>>>>>>>>>>> jcmd, >>>>>>>>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>>> require a >>>>>>>>>>>>>> framework change. It does not look like any marks are >>>>>>>>>>>>>> made when >>>>>>>>>>>>>> the LogConfiguration changes during runtime, and we >>>>>>>>>>>>>> would need >>>>>>>>>>>>>> to record that in order to know what to print when we >>>>>>>>>>>>>> dump into >>>>>>>>>>>>>> hs_err. >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, this would required the framework to keep some >>>>>>>>>>>>> sort of log >>>>>>>>>>>>> of configuration changes. Is there value in knowing >>>>>>>>>>>>> that the log >>>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>>> >>>>>>>>>>>> I think it is useful along with other information. An >>>>>>>>>>>> example case: >>>>>>>>>>>> >>>>>>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>>>>>> acquired or >>>>>>>>>>>> released. In a subsystem like this, the action which >>>>>>>>>>>> dooms the vm >>>>>>>>>>>> may not cause an immediate crash. This leaves time for >>>>>>>>>>>> logging to >>>>>>>>>>>> turn on or off in between the bad action and the crash. >>>>>>>>>>>> If you >>>>>>>>>>>> don't know when logging was active and when it was not, >>>>>>>>>>>> then the >>>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>>> information. You may not see the message that has the >>>>>>>>>>>> answer for >>>>>>>>>>>> you because it was not logged, though the action may >>>>>>>>>>>> have occurred. >>>>>>>>>>>> >>>>>>>>>>>> However, if we don't have the framework support for >>>>>>>>>>>> this then I >>>>>>>>>>>> believe it should be added later. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This is a good example. A small easy solution, as I >>>>>>>>>>>> mentioned before, could be just to distinguish between >>>>>>>>>>>> "logging parameters stable since startup" and "logging >>>>>>>>>>>> parameters changed at some time". That way you would at >>>>>>>>>>>> least know whether to trust the logging output. >>>>>>>>>>>> >>>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>>> >>>>>>>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 >>>>>>>>>>> for this. >>>>>>>>>>> >>>>>>>>>>> Max: Did you see my comments about the ConfigurationLock? It >>>>>>>>>>> was an inline reply to your first mail. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Marcus >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Max >>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>>> >>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> Please review another Unified Logging change. >>>>>>>>>>>>>>> They are >>>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>>>> the error >>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>> already holds >>>>>>>>>>>>> the lock. Unsure how to resolve this, because skipping >>>>>>>>>>>>> to take >>>>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Marcus >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The logging configuration is now printed in each >>>>>>>>>>>>>>> hs_err >>>>>>>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>>>> Logging info >>>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, and >>>>>>>>>>>>>>> before >>>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>>>>>> warning, error >>>>>>>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>>>>>>> timemillis >>>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), >>>>>>>>>>>>>>> tags (tg) >>>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>>>>>> preorder, >>>>>>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>>>>>> safepoint, >>>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, >>>>>>>>>>>>>>> start, >>>>>>>>>>>>>>> startuptime, state, stats, stringdedup, >>>>>>>>>>>>>>> stringtable, >>>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From harold.seigel at oracle.com Fri Apr 15 15:20:34 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 15 Apr 2016 11:20:34 -0400 Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules Message-ID: <571106C2.7090305@oracle.com> Hi, Please review this small change to fix test bug 8154268. The change fixes the test's compilation error by adding @modules to the test. Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154268/ JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154268 Thanks, Harold From daniel.daugherty at oracle.com Fri Apr 15 16:10:59 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Apr 2016 10:10:59 -0600 Subject: PING: RFR: JDK-8153743: AllocateHeap() and ReallocateHeap() should use ALWAYSINLINE macro In-Reply-To: <5710EC7E.3020108@gmail.com> References: <57066B05.3030906@gmail.com> <5710EC7E.3020108@gmail.com> Message-ID: <57111293.8070209@oracle.com> JDK9-hs and JDK9-hs-rt are currently locked down due to the merge. Please see the "Merging jdk9/hs-rt with jdk9/hs" e-mail thread on the hotspot-dev at openjdk.java.net alias. Dan On 4/15/16 7:28 AM, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153743/webrev.00/ > Yasumasa > > > On 2016/04/07 23:13, Yasumasa Suenaga wrote: >> For force inlining, JDK-8076212 uses always_inline attribute to them. >> JDK-8151593 added ALWAYSINLINE macro for force inlining. >> >> For consistency, and for other compiler support, AllocateHeap() and >> ReallocateHeap() should use ALWAYSINLINE. >> >> I used ALWAYSINLINE to them, but I got error message as below; >> ------------------------------ >> Building target 'images' in configuration 'linux-x86_64-normal-server-release' >> In file included from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/utilities/array.hpp:29:0, >> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/memory/universe.hpp:29, >> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/code/oopRecorder.hpp:28, >> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/asm/codeBuffer.hpp:28, >> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/asm/assembler.hpp:28, >> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/precompiled/precompiled.hpp:29: >> /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/memory/allocation.inline.hpp:72:20: ???: always_inline function might not be inlinable [-Werror=attributes] >> ALWAYSINLINE char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, >> ^ >> ------------------------------ >> * This message includes Japanese because my environment is Japanese locale :-) >> >> According to GCC manual [1], non-static inline function is always compiled >> on its own in the usual fashion. >> However, we can compile as inline function with "inline" and "always_inline". >> always_inline attribute does not imply inlining [2]. >> GCC testcase [3] uses both "inline" and "always_inline" actually. >> >> I uploaded webrev. Could you review it? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8153743/webrev.00/ >> >> I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html >> [2] https://chromiumcodereview.appspot.com/14820003/ >> [3] https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/vmx/gcc-bug-i.c?view=markup&pathrev=178730 >> From lois.foltan at oracle.com Fri Apr 15 17:36:28 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 15 Apr 2016 13:36:28 -0400 Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules In-Reply-To: <571106C2.7090305@oracle.com> References: <571106C2.7090305@oracle.com> Message-ID: <5711269C.7000004@oracle.com> Looks good. Lois On 4/15/2016 11:20 AM, harold seigel wrote: > Hi, > > Please review this small change to fix test bug 8154268. > > The change fixes the test's compilation error by adding @modules to > the test. > > Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154268/ > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154268 > > Thanks, Harold From harold.seigel at oracle.com Fri Apr 15 17:41:44 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 15 Apr 2016 13:41:44 -0400 Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules In-Reply-To: <5711269C.7000004@oracle.com> References: <571106C2.7090305@oracle.com> <5711269C.7000004@oracle.com> Message-ID: <571127D8.9070103@oracle.com> Thanks Lois! Harold On 4/15/2016 1:36 PM, Lois Foltan wrote: > Looks good. > Lois > > On 4/15/2016 11:20 AM, harold seigel wrote: >> Hi, >> >> Please review this small change to fix test bug 8154268. >> >> The change fixes the test's compilation error by adding @modules to >> the test. >> >> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154268/ >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154268 >> >> Thanks, Harold > From george.triantafillou at oracle.com Fri Apr 15 18:35:53 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 15 Apr 2016 14:35:53 -0400 Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules In-Reply-To: <5711269C.7000004@oracle.com> References: <571106C2.7090305@oracle.com> <5711269C.7000004@oracle.com> Message-ID: <57113489.4060500@oracle.com> +1 -George On 4/15/2016 1:36 PM, Lois Foltan wrote: > Looks good. > Lois > > On 4/15/2016 11:20 AM, harold seigel wrote: >> Hi, >> >> Please review this small change to fix test bug 8154268. >> >> The change fixes the test's compilation error by adding @modules to >> the test. >> >> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154268/ >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154268 >> >> Thanks, Harold > From harold.seigel at oracle.com Fri Apr 15 18:42:58 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 15 Apr 2016 14:42:58 -0400 Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules In-Reply-To: <57113489.4060500@oracle.com> References: <571106C2.7090305@oracle.com> <5711269C.7000004@oracle.com> <57113489.4060500@oracle.com> Message-ID: <57113632.9070302@oracle.com> Thanks George! Harold On 4/15/2016 2:35 PM, George Triantafillou wrote: > +1 > > -George > > On 4/15/2016 1:36 PM, Lois Foltan wrote: >> Looks good. >> Lois >> >> On 4/15/2016 11:20 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this small change to fix test bug 8154268. >>> >>> The change fixes the test's compilation error by adding @modules to >>> the test. >>> >>> Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154268/ >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154268 >>> >>> Thanks, Harold >> > From david.holmes at oracle.com Fri Apr 15 22:26:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 08:26:38 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5710EA86.6010400@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> Message-ID: <57116A9E.9070003@oracle.com> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: > Hi David, > >> I think it is a bug based on the comment here: >> >> JavaThread(bool is_attaching_via_jni = false); // for main thread and >> JNI attached threads > > I filed it to JBS as JDK-8154331. > I will send review request to hotspot-runtime-dev. > > >> Though that will introduce a change in behaviour by itself as setName >> will no longer set the native name for the main thread. > > I know. That change in behaviour may be a problem, it could be considered a regression that setName stops setting the native thread main, even though we never really intended it to work in the first place. :( Such a change needs to go through CCC. > I checked changeset history. > JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is > backported JDK 8. Yes this all came in as part of the OSX port in 7u2. > However, this function seems to be called from Thread#setNativeName() only. > In addition, Thread#setNativeName() is private method. > > Thus I think that we can add an argument to JVM_SetNativeThreadName() > for force setting. > (e.g. "bool forced") > > It makes a change of JVM API. > However, this function is NOT public, so I think we can add one more > argument. > > What do you think about this? > If it is accepted, we can set native thread name from Java launcher. The private/public aspect of the Java API is not really at issue. Yes we would add another arg to the JVM function to allow it to apply to JNI-attached threads as well (I'd prefer the arg reflect that not just "force"). However this is still a change to the exported JVM interface and so has to be approved. Further, we expect the launcher to use the supported JNI interface (as other processes would), not the internal JVM interface that exists for the JDK sources to communicate with the JVM. David ----- > > Thanks, > > Yasumasa > > > On 2016/04/15 19:16, David Holmes wrote: >> Hi Yasumasa, >> >> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> The fact that the "main" thread is not tagged as being a JNI-attached >>>> thread seems accidental to me >>> >>> Should I file it to JBS? >> >> I think it is a bug based on the comment here: >> >> JavaThread(bool is_attaching_via_jni = false); // for main thread and >> JNI attached threads >> >> Though that will introduce a change in behaviour by itself as setName >> will no longer set the native name for the main thread. >> >>> I think that we can fix as below: >>> --------------- >>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 >>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 >>> @@ -3592,7 +3592,7 @@ >>> #endif // INCLUDE_JVMCI >>> >>> // Attach the main thread to this os thread >>> - JavaThread* main_thread = new JavaThread(); >>> + JavaThread* main_thread = new JavaThread(true); >>> main_thread->set_thread_state(_thread_in_vm); >>> main_thread->initialize_thread_current(); >>> // must do this before set_active_handles >>> @@ -3776,6 +3776,9 @@ >>> // Notify JVMTI agents that VM initialization is complete - nop if >>> no agents. >>> JvmtiExport::post_vm_initialized(); >>> >>> + // Change attach status to "attached" >>> + main_thread->set_done_attaching_via_jni(); >>> + >> >> I think we can do this straight after the JavaThread constructor. >> >>> if (TRACE_START() != JNI_OK) { >>> vm_exit_during_initialization("Failed to start tracing backend."); >>> } >>> --------------- >>> >>> >>>> If it wants to name its native threads then it is free to do so, >>> >>> Currently, JVM_SetNativeThreadName() cannot change native thread name >>> when the caller thread is JNI-attached thread. >>> However, I think that it should be changed if Java developer calls >>> Thread#setName() explicitly. >>> It is not the same of changing native thread name at >>> Threads::create_vm(). >>> >>> If it is allowed, I want to fix SetNativeThreadName() as below. >>> What do you think about this? >> >> The decision to not change the name of JNI-attached threads was a >> deliberate one** - this functionality originated with the OSX port and >> it was reported that the initial feedback with this feature was to >> ensure it didn't mess with thread names that had been set by the host >> process. If we do as you propose then we will just have an >> inconsistency for people to complain about: "why does my native thread >> only have a name if I call cur.setName(cur.getName()) ?" >> >> ** If you follow the bugs and related discussions on this, the >> semantics and limitations (truncation, current thread only, non-JNI >> threads only) of setting the native thread name were supposed to be >> documented in the release notes - but as far as I can see that never >> happened. :( >> >> My position on this remains that if it is desirable for the main >> thread (and DestroyJavaVM thread) to have native names then the >> launcher needs to be setting them using the available platform APIs. >> Unfortunately this is complicated - as evidenced by the VM code for >> this - due to the need to verify API availability. >> >> Any change in behaviour in relation to Thread.setName would have to go >> through our CCC process I think. But a change in the launcher would not. >> >> Sorry. >> >> David >> ----- >> >>> --------------- >>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 >>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 >>> @@ -3187,7 +3187,7 @@ >>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>> // Thread naming only supported for the current thread, doesn't work >>> for >>> // target threads. >>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>> + if (Thread::current() == thr) { >>> // we don't set the name of an attached thread to avoid stepping >>> // on other programs >>> const char *thread_name = >>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>> --------------- >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/15 13:32, David Holmes wrote: >>>> >>>> >>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>> Roger, >>>>> Thanks for your comment! >>>>> >>>>> David, >>>>> >>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>> exposing >>>>>>>> a new JVM function this way. >>>>> >>>>> I tried to call Thread#setName() after initializing VM (before calling >>>>> main method), >>>>> I could set native thread name. >>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't set >>>>> native thread name for DestroyJavaVM. >>>> >>>> Right - I came to the same realization earlier this morning. Which, >>>> unfortunately, takes me back to the basic premise here that we don't >>>> set the name of threads not created by the JVM. The fact that the >>>> "main" thread is not tagged as being a JNI-attached thread seems >>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>> accident for the initial attach, and can't be used for the >>>> DestroyJavaVM part - which leaves the thread inconsistently named at >>>> the native level. >>>> >>>> I'm afraid my view here is that the launcher has to be treated like >>>> any other process that might host a JVM. If it wants to name its >>>> native threads then it is free to do so, but I would not be exporting >>>> a function from the JVM to do that - it would have to use the OS >>>> specific API's for that on a platform-by-platform basis. >>>> >>>> Sorry. >>>> >>>> David >>>> ----- >>>> >>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>> Hi, >>>>>> >>>>>> Comments: >>>>>> >>>>>> jvm.h: The function names are too similar but perform different >>>>>> functions: >>>>>> >>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>> >>>>>> - The first function applies to the current thread, the second one a >>>>>> specific java thread. >>>>>> It would seem useful for there to be a comment somewhere about what >>>>>> the new function does. >>>>>> >>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) instead of >>>>>> (SetNativeThreadName0_t) >>>>>> as is done on unix and mac. >>>>>> >>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>> line 730 >>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>> same >>>>>> line as dlsym... >>>>>> >>>>>> $.02, Roger >>>>>> >>>>>> >>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>> That is an interesting question which I haven't had time to check - >>>>>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>> JNI-attached threads :( ) >>>>>>> >>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>> thread name (test) was set. >>>>>>> --------- >>>>>>> public class Sleep{ >>>>>>> public static void main(String[] args) throws Exception{ >>>>>>> Thread.currentThread().setName("test"); >>>>>>> Thread.sleep(3600000); >>>>>>> } >>>>>>> } >>>>>>> --------- >>>>>>> >>>>>>> >>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>> exposing >>>>>>>> a new JVM function this way. >>>>>>> >>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> Thanks for your comment. >>>>>>>>>>> >>>>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>>>> uses it >>>>>>>>>>> in new webrev. >>>>>>>>>> >>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>> need to >>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> I'm waiting to review :-) >>>>>>>>> >>>>>>>>> >>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>> rather >>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>> needed in >>>>>>>>>> that case. >>>>>>>>> >>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>> Thread#init(), >>>>>>>>> but I could not change native thread name. >>>>>>>> >>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>> native >>>>>>>> name is not set. >>>>>>>> >>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>> >>>>>>>> That is an interesting question which I haven't had time to check - >>>>>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>> JNI-attached threads :( ) >>>>>>>> >>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>> exposing >>>>>>>> a new JVM function this way. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>> thread name. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Could you review again? >>>>>>>>>>> >>>>>>>>>>> - hotspot: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - jdk: >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>> >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> Please see my updates to the bug (sorry have been on vacation). >>>>>>>>>>>> This >>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>> set the >>>>>>>>>>>> name of threads that attach via JNI, which includes the "main" >>>>>>>>>>>> thread. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>> >>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native thread >>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name should >>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have native >>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>> From yasuenag at gmail.com Sat Apr 16 05:27:36 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 16 Apr 2016 14:27:36 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57116A9E.9070003@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> Message-ID: <5711CD48.7010403@gmail.com> Hi David, > That change in behaviour may be a problem, it could be considered a regression that setName stops setting the native thread main, even though we never really intended it to work in the first place. :( Such a change needs to go through CCC. I understood. Can I send CCC request? (I'm jdk 9 commiter, but I'm not employee at Oracle.) I want to continue to discuss about it on JDK-8154331 [1]. > Further, we expect the launcher to use the supported JNI interface (as other processes would), not the internal JVM interface that exists for the JDK sources to communicate with the JVM. I think that we do not use JVM interface if we add new method in LauncherHelper as below: ---------------- diff -r f02139a1ac84 src/java.base/share/classes/sun/launcher/LauncherHelper.java --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java Wed Apr 13 14:19:30 2016 +0000 +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java Sat Apr 16 11:25:53 2016 +0900 @@ -960,4 +960,8 @@ else return md.toNameAndVersion() + " (" + loc + ")"; } + + static void setNativeThreadName(String name) { + Thread.currentThread().setName(name); + } } diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 2016 +0000 +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 2016 +0900 @@ -125,6 +125,7 @@ static void PrintUsage(JNIEnv* env, jboolean doXUsage); static void ShowSettings(JNIEnv* env, char *optString); static void ListModules(JNIEnv* env, char *optString); +static void SetNativeThreadName(JNIEnv* env, char *name); static void SetPaths(int argc, char **argv); @@ -325,6 +326,7 @@ * mainThread.isAlive() to work as expected. */ #define LEAVE() \ + SetNativeThreadName(env, "DestroyJavaVM"); \ do { \ if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ JLI_ReportErrorMessage(JVM_ERROR2); \ @@ -488,6 +490,9 @@ mainArgs = CreateApplicationArgs(env, argv, argc); CHECK_EXCEPTION_NULL_LEAVE(mainArgs); + /* Set native thread name. */ + SetNativeThreadName(env, "main"); + /* Invoke main method. */ (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); @@ -1686,6 +1691,22 @@ joptString); } +/** + * Set native thread name as possible. + */ +static void +SetNativeThreadName(JNIEnv *env, char *name) +{ + jmethodID setNativeThreadNameID; + jstring nameString; + jclass cls = GetLauncherHelperClass(env); + NULL_CHECK(cls); + NULL_CHECK(setNativeThreadNameID = (*env)->GetStaticMethodID(env, cls, + "setNativeThreadName", "(Ljava/lang/String;)V")); + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, nameString); +} + /* * Prints default usage or the Xusage message, see sun.launcher.LauncherHelper.java */ ---------------- So I want to add new arg to JVM_SetNativeThreadName(). > However this is still a change to the exported JVM interface and so has to be approved. Do you mean that this change needs CCC? Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html On 2016/04/16 7:26, David Holmes wrote: > On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >> Hi David, >> >>> I think it is a bug based on the comment here: >>> >>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>> JNI attached threads >> >> I filed it to JBS as JDK-8154331. >> I will send review request to hotspot-runtime-dev. >> >> >>> Though that will introduce a change in behaviour by itself as setName >>> will no longer set the native name for the main thread. >> >> I know. > > That change in behaviour may be a problem, it could be considered a regression that setName stops setting the native thread main, even though we never really intended it to work in the first place. :( Such a change needs to go through CCC. > >> I checked changeset history. >> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >> backported JDK 8. > > Yes this all came in as part of the OSX port in 7u2. > >> However, this function seems to be called from Thread#setNativeName() only. >> In addition, Thread#setNativeName() is private method. >> >> Thus I think that we can add an argument to JVM_SetNativeThreadName() >> for force setting. >> (e.g. "bool forced") >> >> It makes a change of JVM API. >> However, this function is NOT public, so I think we can add one more >> argument. >> >> What do you think about this? >> If it is accepted, we can set native thread name from Java launcher. > > The private/public aspect of the Java API is not really at issue. Yes we would add another arg to the JVM function to allow it to apply to JNI-attached threads as well (I'd prefer the arg reflect that not just "force"). However this is still a change to the exported JVM interface and so has to be approved. Further, we expect the launcher to use the supported JNI interface (as other processes would), not the internal JVM interface that exists for the JDK sources to communicate with the JVM. > > David > ----- > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/15 19:16, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> The fact that the "main" thread is not tagged as being a JNI-attached >>>>> thread seems accidental to me >>>> >>>> Should I file it to JBS? >>> >>> I think it is a bug based on the comment here: >>> >>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>> JNI attached threads >>> >>> Though that will introduce a change in behaviour by itself as setName >>> will no longer set the native name for the main thread. >>> >>>> I think that we can fix as below: >>>> --------------- >>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 >>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 >>>> @@ -3592,7 +3592,7 @@ >>>> #endif // INCLUDE_JVMCI >>>> >>>> // Attach the main thread to this os thread >>>> - JavaThread* main_thread = new JavaThread(); >>>> + JavaThread* main_thread = new JavaThread(true); >>>> main_thread->set_thread_state(_thread_in_vm); >>>> main_thread->initialize_thread_current(); >>>> // must do this before set_active_handles >>>> @@ -3776,6 +3776,9 @@ >>>> // Notify JVMTI agents that VM initialization is complete - nop if >>>> no agents. >>>> JvmtiExport::post_vm_initialized(); >>>> >>>> + // Change attach status to "attached" >>>> + main_thread->set_done_attaching_via_jni(); >>>> + >>> >>> I think we can do this straight after the JavaThread constructor. >>> >>>> if (TRACE_START() != JNI_OK) { >>>> vm_exit_during_initialization("Failed to start tracing backend."); >>>> } >>>> --------------- >>>> >>>> >>>>> If it wants to name its native threads then it is free to do so, >>>> >>>> Currently, JVM_SetNativeThreadName() cannot change native thread name >>>> when the caller thread is JNI-attached thread. >>>> However, I think that it should be changed if Java developer calls >>>> Thread#setName() explicitly. >>>> It is not the same of changing native thread name at >>>> Threads::create_vm(). >>>> >>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>> What do you think about this? >>> >>> The decision to not change the name of JNI-attached threads was a >>> deliberate one** - this functionality originated with the OSX port and >>> it was reported that the initial feedback with this feature was to >>> ensure it didn't mess with thread names that had been set by the host >>> process. If we do as you propose then we will just have an >>> inconsistency for people to complain about: "why does my native thread >>> only have a name if I call cur.setName(cur.getName()) ?" >>> >>> ** If you follow the bugs and related discussions on this, the >>> semantics and limitations (truncation, current thread only, non-JNI >>> threads only) of setting the native thread name were supposed to be >>> documented in the release notes - but as far as I can see that never >>> happened. :( >>> >>> My position on this remains that if it is desirable for the main >>> thread (and DestroyJavaVM thread) to have native names then the >>> launcher needs to be setting them using the available platform APIs. >>> Unfortunately this is complicated - as evidenced by the VM code for >>> this - due to the need to verify API availability. >>> >>> Any change in behaviour in relation to Thread.setName would have to go >>> through our CCC process I think. But a change in the launcher would not. >>> >>> Sorry. >>> >>> David >>> ----- >>> >>>> --------------- >>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 >>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 >>>> @@ -3187,7 +3187,7 @@ >>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>> // Thread naming only supported for the current thread, doesn't work >>>> for >>>> // target threads. >>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>> + if (Thread::current() == thr) { >>>> // we don't set the name of an attached thread to avoid stepping >>>> // on other programs >>>> const char *thread_name = >>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>> --------------- >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/15 13:32, David Holmes wrote: >>>>> >>>>> >>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>> Roger, >>>>>> Thanks for your comment! >>>>>> >>>>>> David, >>>>>> >>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>> exposing >>>>>>>>> a new JVM function this way. >>>>>> >>>>>> I tried to call Thread#setName() after initializing VM (before calling >>>>>> main method), >>>>>> I could set native thread name. >>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't set >>>>>> native thread name for DestroyJavaVM. >>>>> >>>>> Right - I came to the same realization earlier this morning. Which, >>>>> unfortunately, takes me back to the basic premise here that we don't >>>>> set the name of threads not created by the JVM. The fact that the >>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>> accident for the initial attach, and can't be used for the >>>>> DestroyJavaVM part - which leaves the thread inconsistently named at >>>>> the native level. >>>>> >>>>> I'm afraid my view here is that the launcher has to be treated like >>>>> any other process that might host a JVM. If it wants to name its >>>>> native threads then it is free to do so, but I would not be exporting >>>>> a function from the JVM to do that - it would have to use the OS >>>>> specific API's for that on a platform-by-platform basis. >>>>> >>>>> Sorry. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Comments: >>>>>>> >>>>>>> jvm.h: The function names are too similar but perform different >>>>>>> functions: >>>>>>> >>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>> >>>>>>> - The first function applies to the current thread, the second one a >>>>>>> specific java thread. >>>>>>> It would seem useful for there to be a comment somewhere about what >>>>>>> the new function does. >>>>>>> >>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) instead of >>>>>>> (SetNativeThreadName0_t) >>>>>>> as is done on unix and mac. >>>>>>> >>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>>> line 730 >>>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>>> same >>>>>>> line as dlsym... >>>>>>> >>>>>>> $.02, Roger >>>>>>> >>>>>>> >>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>> That is an interesting question which I haven't had time to check - >>>>>>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>>>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>> JNI-attached threads :( ) >>>>>>>> >>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>>> thread name (test) was set. >>>>>>>> --------- >>>>>>>> public class Sleep{ >>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>> Thread.currentThread().setName("test"); >>>>>>>> Thread.sleep(3600000); >>>>>>>> } >>>>>>>> } >>>>>>>> --------- >>>>>>>> >>>>>>>> >>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>> exposing >>>>>>>>> a new JVM function this way. >>>>>>>> >>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>> >>>>>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>>>>> uses it >>>>>>>>>>>> in new webrev. >>>>>>>>>>> >>>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>>> need to >>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> I'm waiting to review :-) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>>> rather >>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>> needed in >>>>>>>>>>> that case. >>>>>>>>>> >>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>> Thread#init(), >>>>>>>>>> but I could not change native thread name. >>>>>>>>> >>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>> native >>>>>>>>> name is not set. >>>>>>>>> >>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>> >>>>>>>>> That is an interesting question which I haven't had time to check - >>>>>>>>> sorry. If the main thread is considered a JNI-attached thread then >>>>>>>>> my suggestion wont work. If it isn't then my suggestion should work >>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>> JNI-attached threads :( ) >>>>>>>>> >>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>> exposing >>>>>>>>> a new JVM function this way. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>>> thread name. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Could you review again? >>>>>>>>>>>> >>>>>>>>>>>> - hotspot: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - jdk: >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> Please see my updates to the bug (sorry have been on vacation). >>>>>>>>>>>>> This >>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>>> set the >>>>>>>>>>>>> name of threads that attach via JNI, which includes the "main" >>>>>>>>>>>>> thread. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native thread >>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name should >>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus the >>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with pthread_join(). >>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have some >>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have native >>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>> From david.holmes at oracle.com Sat Apr 16 07:09:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 17:09:08 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5711CD48.7010403@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> Message-ID: <5711E514.3060408@oracle.com> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: > Hi David, > >> That change in behaviour may be a problem, it could be considered a >> regression that setName stops setting the native thread main, even >> though we never really intended it to work in the first place. :( Such >> a change needs to go through CCC. > > I understood. > Can I send CCC request? > (I'm jdk 9 commiter, but I'm not employee at Oracle.) Sorry you can't file a CCC request, you would need a sponsor for that. But at this stage I don't think I agree with the proposed change because of the change in behaviour - there's no way to restore the "broken" behaviour. > I want to continue to discuss about it on JDK-8154331 [1]. Okay we can do that. > >> Further, we expect the launcher to use the supported JNI interface (as >> other processes would), not the internal JVM interface that exists for >> the JDK sources to communicate with the JVM. > > I think that we do not use JVM interface if we add new method in > LauncherHelper as below: > ---------------- > diff -r f02139a1ac84 > src/java.base/share/classes/sun/launcher/LauncherHelper.java > --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java > Wed Apr 13 14:19:30 2016 +0000 > +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java > Sat Apr 16 11:25:53 2016 +0900 > @@ -960,4 +960,8 @@ > else > return md.toNameAndVersion() + " (" + loc + ")"; > } > + > + static void setNativeThreadName(String name) { > + Thread.currentThread().setName(name); > + } You could also make that call via JNI directly, so not sure the helper adds much here. But it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? David ----- > } > diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c > --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 > 2016 +0000 > +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 > 2016 +0900 > @@ -125,6 +125,7 @@ > static void PrintUsage(JNIEnv* env, jboolean doXUsage); > static void ShowSettings(JNIEnv* env, char *optString); > static void ListModules(JNIEnv* env, char *optString); > +static void SetNativeThreadName(JNIEnv* env, char *name); > > static void SetPaths(int argc, char **argv); > > @@ -325,6 +326,7 @@ > * mainThread.isAlive() to work as expected. > */ > #define LEAVE() \ > + SetNativeThreadName(env, "DestroyJavaVM"); \ > do { \ > if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ > JLI_ReportErrorMessage(JVM_ERROR2); \ > @@ -488,6 +490,9 @@ > mainArgs = CreateApplicationArgs(env, argv, argc); > CHECK_EXCEPTION_NULL_LEAVE(mainArgs); > > + /* Set native thread name. */ > + SetNativeThreadName(env, "main"); > + > /* Invoke main method. */ > (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); > > @@ -1686,6 +1691,22 @@ > joptString); > } > > +/** > + * Set native thread name as possible. > + */ > +static void > +SetNativeThreadName(JNIEnv *env, char *name) > +{ > + jmethodID setNativeThreadNameID; > + jstring nameString; > + jclass cls = GetLauncherHelperClass(env); > + NULL_CHECK(cls); > + NULL_CHECK(setNativeThreadNameID = (*env)->GetStaticMethodID(env, cls, > + "setNativeThreadName", "(Ljava/lang/String;)V")); > + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); > + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, > nameString); > +} > + > /* > * Prints default usage or the Xusage message, see > sun.launcher.LauncherHelper.java > */ > ---------------- > > So I want to add new arg to JVM_SetNativeThreadName(). > >> However this is still a change to the exported JVM interface and so >> has to be approved. > > Do you mean that this change needs CCC? > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html > > > > On 2016/04/16 7:26, David Holmes wrote: >> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> I think it is a bug based on the comment here: >>>> >>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>> JNI attached threads >>> >>> I filed it to JBS as JDK-8154331. >>> I will send review request to hotspot-runtime-dev. >>> >>> >>>> Though that will introduce a change in behaviour by itself as setName >>>> will no longer set the native name for the main thread. >>> >>> I know. >> >> That change in behaviour may be a problem, it could be considered a >> regression that setName stops setting the native thread main, even >> though we never really intended it to work in the first place. :( Such >> a change needs to go through CCC. >> >>> I checked changeset history. >>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>> backported JDK 8. >> >> Yes this all came in as part of the OSX port in 7u2. >> >>> However, this function seems to be called from Thread#setNativeName() >>> only. >>> In addition, Thread#setNativeName() is private method. >>> >>> Thus I think that we can add an argument to JVM_SetNativeThreadName() >>> for force setting. >>> (e.g. "bool forced") >>> >>> It makes a change of JVM API. >>> However, this function is NOT public, so I think we can add one more >>> argument. >>> >>> What do you think about this? >>> If it is accepted, we can set native thread name from Java launcher. >> >> The private/public aspect of the Java API is not really at issue. Yes >> we would add another arg to the JVM function to allow it to apply to >> JNI-attached threads as well (I'd prefer the arg reflect that not just >> "force"). However this is still a change to the exported JVM interface >> and so has to be approved. Further, we expect the launcher to use the >> supported JNI interface (as other processes would), not the internal >> JVM interface that exists for the JDK sources to communicate with the >> JVM. >> >> David >> ----- >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/15 19:16, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> The fact that the "main" thread is not tagged as being a JNI-attached >>>>>> thread seems accidental to me >>>>> >>>>> Should I file it to JBS? >>>> >>>> I think it is a bug based on the comment here: >>>> >>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>> JNI attached threads >>>> >>>> Though that will introduce a change in behaviour by itself as setName >>>> will no longer set the native name for the main thread. >>>> >>>>> I think that we can fix as below: >>>>> --------------- >>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>> @@ -3592,7 +3592,7 @@ >>>>> #endif // INCLUDE_JVMCI >>>>> >>>>> // Attach the main thread to this os thread >>>>> - JavaThread* main_thread = new JavaThread(); >>>>> + JavaThread* main_thread = new JavaThread(true); >>>>> main_thread->set_thread_state(_thread_in_vm); >>>>> main_thread->initialize_thread_current(); >>>>> // must do this before set_active_handles >>>>> @@ -3776,6 +3776,9 @@ >>>>> // Notify JVMTI agents that VM initialization is complete - nop if >>>>> no agents. >>>>> JvmtiExport::post_vm_initialized(); >>>>> >>>>> + // Change attach status to "attached" >>>>> + main_thread->set_done_attaching_via_jni(); >>>>> + >>>> >>>> I think we can do this straight after the JavaThread constructor. >>>> >>>>> if (TRACE_START() != JNI_OK) { >>>>> vm_exit_during_initialization("Failed to start tracing >>>>> backend."); >>>>> } >>>>> --------------- >>>>> >>>>> >>>>>> If it wants to name its native threads then it is free to do so, >>>>> >>>>> Currently, JVM_SetNativeThreadName() cannot change native thread name >>>>> when the caller thread is JNI-attached thread. >>>>> However, I think that it should be changed if Java developer calls >>>>> Thread#setName() explicitly. >>>>> It is not the same of changing native thread name at >>>>> Threads::create_vm(). >>>>> >>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>> What do you think about this? >>>> >>>> The decision to not change the name of JNI-attached threads was a >>>> deliberate one** - this functionality originated with the OSX port and >>>> it was reported that the initial feedback with this feature was to >>>> ensure it didn't mess with thread names that had been set by the host >>>> process. If we do as you propose then we will just have an >>>> inconsistency for people to complain about: "why does my native thread >>>> only have a name if I call cur.setName(cur.getName()) ?" >>>> >>>> ** If you follow the bugs and related discussions on this, the >>>> semantics and limitations (truncation, current thread only, non-JNI >>>> threads only) of setting the native thread name were supposed to be >>>> documented in the release notes - but as far as I can see that never >>>> happened. :( >>>> >>>> My position on this remains that if it is desirable for the main >>>> thread (and DestroyJavaVM thread) to have native names then the >>>> launcher needs to be setting them using the available platform APIs. >>>> Unfortunately this is complicated - as evidenced by the VM code for >>>> this - due to the need to verify API availability. >>>> >>>> Any change in behaviour in relation to Thread.setName would have to go >>>> through our CCC process I think. But a change in the launcher would >>>> not. >>>> >>>> Sorry. >>>> >>>> David >>>> ----- >>>> >>>>> --------------- >>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>> @@ -3187,7 +3187,7 @@ >>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>> // Thread naming only supported for the current thread, doesn't >>>>> work >>>>> for >>>>> // target threads. >>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>>> + if (Thread::current() == thr) { >>>>> // we don't set the name of an attached thread to avoid stepping >>>>> // on other programs >>>>> const char *thread_name = >>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>> --------------- >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>> >>>>>> >>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>> Roger, >>>>>>> Thanks for your comment! >>>>>>> >>>>>>> David, >>>>>>> >>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>> exposing >>>>>>>>>> a new JVM function this way. >>>>>>> >>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>> calling >>>>>>> main method), >>>>>>> I could set native thread name. >>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't >>>>>>> set >>>>>>> native thread name for DestroyJavaVM. >>>>>> >>>>>> Right - I came to the same realization earlier this morning. Which, >>>>>> unfortunately, takes me back to the basic premise here that we don't >>>>>> set the name of threads not created by the JVM. The fact that the >>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>> accident for the initial attach, and can't be used for the >>>>>> DestroyJavaVM part - which leaves the thread inconsistently named at >>>>>> the native level. >>>>>> >>>>>> I'm afraid my view here is that the launcher has to be treated like >>>>>> any other process that might host a JVM. If it wants to name its >>>>>> native threads then it is free to do so, but I would not be exporting >>>>>> a function from the JVM to do that - it would have to use the OS >>>>>> specific API's for that on a platform-by-platform basis. >>>>>> >>>>>> Sorry. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Comments: >>>>>>>> >>>>>>>> jvm.h: The function names are too similar but perform different >>>>>>>> functions: >>>>>>>> >>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>> >>>>>>>> - The first function applies to the current thread, the second >>>>>>>> one a >>>>>>>> specific java thread. >>>>>>>> It would seem useful for there to be a comment somewhere about >>>>>>>> what >>>>>>>> the new function does. >>>>>>>> >>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>> instead of >>>>>>>> (SetNativeThreadName0_t) >>>>>>>> as is done on unix and mac. >>>>>>>> >>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>>>> line 730 >>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>>>> same >>>>>>>> line as dlsym... >>>>>>>> >>>>>>>> $.02, Roger >>>>>>>> >>>>>>>> >>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>> check - >>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>> then >>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>> work >>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>> JNI-attached threads :( ) >>>>>>>>> >>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>>>> thread name (test) was set. >>>>>>>>> --------- >>>>>>>>> public class Sleep{ >>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>> Thread.sleep(3600000); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> >>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>> exposing >>>>>>>>>> a new JVM function this way. >>>>>>>>> >>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>> >>>>>>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>>>>>> uses it >>>>>>>>>>>>> in new webrev. >>>>>>>>>>>> >>>>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>>>> need to >>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>>>> rather >>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>> needed in >>>>>>>>>>>> that case. >>>>>>>>>>> >>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>> Thread#init(), >>>>>>>>>>> but I could not change native thread name. >>>>>>>>>> >>>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>>> native >>>>>>>>>> name is not set. >>>>>>>>>> >>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>> >>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>> check - >>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>> then >>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>> work >>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>> >>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>> exposing >>>>>>>>>> a new JVM function this way. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>>>> thread name. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>> >>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - jdk: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>> This >>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>>>> set the >>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>> "main" >>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have >>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> From david.holmes at oracle.com Sat Apr 16 07:11:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 17:11:03 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5711CD48.7010403@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> Message-ID: <5711E587.4050805@oracle.com> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: > Hi David, > >> That change in behaviour may be a problem, it could be considered a >> regression that setName stops setting the native thread main, even >> though we never really intended it to work in the first place. :( Such >> a change needs to go through CCC. > > I understood. > Can I send CCC request? > (I'm jdk 9 commiter, but I'm not employee at Oracle.) Sorry you can't file a CCC request, you would need a sponsor for that. But at this stage I don't think I agree with the proposed change because of the change in behaviour - there's no way to restore the "broken" behaviour. > I want to continue to discuss about it on JDK-8154331 [1]. Okay we can do that. > >> Further, we expect the launcher to use the supported JNI interface (as >> other processes would), not the internal JVM interface that exists for >> the JDK sources to communicate with the JVM. > > I think that we do not use JVM interface if we add new method in > LauncherHelper as below: > ---------------- > diff -r f02139a1ac84 > src/java.base/share/classes/sun/launcher/LauncherHelper.java > --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java > Wed Apr 13 14:19:30 2016 +0000 > +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java > Sat Apr 16 11:25:53 2016 +0900 > @@ -960,4 +960,8 @@ > else > return md.toNameAndVersion() + " (" + loc + ")"; > } > + > + static void setNativeThreadName(String name) { > + Thread.currentThread().setName(name); > + } You could also make that call via JNI directly, so not sure the helper adds much here. But it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? David ----- > } > diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c > --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 > 2016 +0000 > +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 > 2016 +0900 > @@ -125,6 +125,7 @@ > static void PrintUsage(JNIEnv* env, jboolean doXUsage); > static void ShowSettings(JNIEnv* env, char *optString); > static void ListModules(JNIEnv* env, char *optString); > +static void SetNativeThreadName(JNIEnv* env, char *name); > > static void SetPaths(int argc, char **argv); > > @@ -325,6 +326,7 @@ > * mainThread.isAlive() to work as expected. > */ > #define LEAVE() \ > + SetNativeThreadName(env, "DestroyJavaVM"); \ > do { \ > if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ > JLI_ReportErrorMessage(JVM_ERROR2); \ > @@ -488,6 +490,9 @@ > mainArgs = CreateApplicationArgs(env, argv, argc); > CHECK_EXCEPTION_NULL_LEAVE(mainArgs); > > + /* Set native thread name. */ > + SetNativeThreadName(env, "main"); > + > /* Invoke main method. */ > (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); > > @@ -1686,6 +1691,22 @@ > joptString); > } > > +/** > + * Set native thread name as possible. > + */ > +static void > +SetNativeThreadName(JNIEnv *env, char *name) > +{ > + jmethodID setNativeThreadNameID; > + jstring nameString; > + jclass cls = GetLauncherHelperClass(env); > + NULL_CHECK(cls); > + NULL_CHECK(setNativeThreadNameID = (*env)->GetStaticMethodID(env, cls, > + "setNativeThreadName", "(Ljava/lang/String;)V")); > + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); > + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, > nameString); > +} > + > /* > * Prints default usage or the Xusage message, see > sun.launcher.LauncherHelper.java > */ > ---------------- > > So I want to add new arg to JVM_SetNativeThreadName(). > >> However this is still a change to the exported JVM interface and so >> has to be approved. > > Do you mean that this change needs CCC? > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html > > > > On 2016/04/16 7:26, David Holmes wrote: >> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> I think it is a bug based on the comment here: >>>> >>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>> JNI attached threads >>> >>> I filed it to JBS as JDK-8154331. >>> I will send review request to hotspot-runtime-dev. >>> >>> >>>> Though that will introduce a change in behaviour by itself as setName >>>> will no longer set the native name for the main thread. >>> >>> I know. >> >> That change in behaviour may be a problem, it could be considered a >> regression that setName stops setting the native thread main, even >> though we never really intended it to work in the first place. :( Such >> a change needs to go through CCC. >> >>> I checked changeset history. >>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>> backported JDK 8. >> >> Yes this all came in as part of the OSX port in 7u2. >> >>> However, this function seems to be called from Thread#setNativeName() >>> only. >>> In addition, Thread#setNativeName() is private method. >>> >>> Thus I think that we can add an argument to JVM_SetNativeThreadName() >>> for force setting. >>> (e.g. "bool forced") >>> >>> It makes a change of JVM API. >>> However, this function is NOT public, so I think we can add one more >>> argument. >>> >>> What do you think about this? >>> If it is accepted, we can set native thread name from Java launcher. >> >> The private/public aspect of the Java API is not really at issue. Yes >> we would add another arg to the JVM function to allow it to apply to >> JNI-attached threads as well (I'd prefer the arg reflect that not just >> "force"). However this is still a change to the exported JVM interface >> and so has to be approved. Further, we expect the launcher to use the >> supported JNI interface (as other processes would), not the internal >> JVM interface that exists for the JDK sources to communicate with the >> JVM. >> >> David >> ----- >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/15 19:16, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> The fact that the "main" thread is not tagged as being a JNI-attached >>>>>> thread seems accidental to me >>>>> >>>>> Should I file it to JBS? >>>> >>>> I think it is a bug based on the comment here: >>>> >>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>> JNI attached threads >>>> >>>> Though that will introduce a change in behaviour by itself as setName >>>> will no longer set the native name for the main thread. >>>> >>>>> I think that we can fix as below: >>>>> --------------- >>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>> @@ -3592,7 +3592,7 @@ >>>>> #endif // INCLUDE_JVMCI >>>>> >>>>> // Attach the main thread to this os thread >>>>> - JavaThread* main_thread = new JavaThread(); >>>>> + JavaThread* main_thread = new JavaThread(true); >>>>> main_thread->set_thread_state(_thread_in_vm); >>>>> main_thread->initialize_thread_current(); >>>>> // must do this before set_active_handles >>>>> @@ -3776,6 +3776,9 @@ >>>>> // Notify JVMTI agents that VM initialization is complete - nop if >>>>> no agents. >>>>> JvmtiExport::post_vm_initialized(); >>>>> >>>>> + // Change attach status to "attached" >>>>> + main_thread->set_done_attaching_via_jni(); >>>>> + >>>> >>>> I think we can do this straight after the JavaThread constructor. >>>> >>>>> if (TRACE_START() != JNI_OK) { >>>>> vm_exit_during_initialization("Failed to start tracing >>>>> backend."); >>>>> } >>>>> --------------- >>>>> >>>>> >>>>>> If it wants to name its native threads then it is free to do so, >>>>> >>>>> Currently, JVM_SetNativeThreadName() cannot change native thread name >>>>> when the caller thread is JNI-attached thread. >>>>> However, I think that it should be changed if Java developer calls >>>>> Thread#setName() explicitly. >>>>> It is not the same of changing native thread name at >>>>> Threads::create_vm(). >>>>> >>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>> What do you think about this? >>>> >>>> The decision to not change the name of JNI-attached threads was a >>>> deliberate one** - this functionality originated with the OSX port and >>>> it was reported that the initial feedback with this feature was to >>>> ensure it didn't mess with thread names that had been set by the host >>>> process. If we do as you propose then we will just have an >>>> inconsistency for people to complain about: "why does my native thread >>>> only have a name if I call cur.setName(cur.getName()) ?" >>>> >>>> ** If you follow the bugs and related discussions on this, the >>>> semantics and limitations (truncation, current thread only, non-JNI >>>> threads only) of setting the native thread name were supposed to be >>>> documented in the release notes - but as far as I can see that never >>>> happened. :( >>>> >>>> My position on this remains that if it is desirable for the main >>>> thread (and DestroyJavaVM thread) to have native names then the >>>> launcher needs to be setting them using the available platform APIs. >>>> Unfortunately this is complicated - as evidenced by the VM code for >>>> this - due to the need to verify API availability. >>>> >>>> Any change in behaviour in relation to Thread.setName would have to go >>>> through our CCC process I think. But a change in the launcher would >>>> not. >>>> >>>> Sorry. >>>> >>>> David >>>> ----- >>>> >>>>> --------------- >>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>> @@ -3187,7 +3187,7 @@ >>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>> // Thread naming only supported for the current thread, doesn't >>>>> work >>>>> for >>>>> // target threads. >>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>>> + if (Thread::current() == thr) { >>>>> // we don't set the name of an attached thread to avoid stepping >>>>> // on other programs >>>>> const char *thread_name = >>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>> --------------- >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>> >>>>>> >>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>> Roger, >>>>>>> Thanks for your comment! >>>>>>> >>>>>>> David, >>>>>>> >>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>> exposing >>>>>>>>>> a new JVM function this way. >>>>>>> >>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>> calling >>>>>>> main method), >>>>>>> I could set native thread name. >>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't >>>>>>> set >>>>>>> native thread name for DestroyJavaVM. >>>>>> >>>>>> Right - I came to the same realization earlier this morning. Which, >>>>>> unfortunately, takes me back to the basic premise here that we don't >>>>>> set the name of threads not created by the JVM. The fact that the >>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>> accident for the initial attach, and can't be used for the >>>>>> DestroyJavaVM part - which leaves the thread inconsistently named at >>>>>> the native level. >>>>>> >>>>>> I'm afraid my view here is that the launcher has to be treated like >>>>>> any other process that might host a JVM. If it wants to name its >>>>>> native threads then it is free to do so, but I would not be exporting >>>>>> a function from the JVM to do that - it would have to use the OS >>>>>> specific API's for that on a platform-by-platform basis. >>>>>> >>>>>> Sorry. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Comments: >>>>>>>> >>>>>>>> jvm.h: The function names are too similar but perform different >>>>>>>> functions: >>>>>>>> >>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>> >>>>>>>> - The first function applies to the current thread, the second >>>>>>>> one a >>>>>>>> specific java thread. >>>>>>>> It would seem useful for there to be a comment somewhere about >>>>>>>> what >>>>>>>> the new function does. >>>>>>>> >>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>> instead of >>>>>>>> (SetNativeThreadName0_t) >>>>>>>> as is done on unix and mac. >>>>>>>> >>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>>>> line 730 >>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>>>> same >>>>>>>> line as dlsym... >>>>>>>> >>>>>>>> $.02, Roger >>>>>>>> >>>>>>>> >>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>> check - >>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>> then >>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>> work >>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>> JNI-attached threads :( ) >>>>>>>>> >>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>>>> thread name (test) was set. >>>>>>>>> --------- >>>>>>>>> public class Sleep{ >>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>> Thread.sleep(3600000); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> --------- >>>>>>>>> >>>>>>>>> >>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>> exposing >>>>>>>>>> a new JVM function this way. >>>>>>>>> >>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>> >>>>>>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>>>>>> uses it >>>>>>>>>>>>> in new webrev. >>>>>>>>>>>> >>>>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>>>> need to >>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>>>> rather >>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>> needed in >>>>>>>>>>>> that case. >>>>>>>>>>> >>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>> Thread#init(), >>>>>>>>>>> but I could not change native thread name. >>>>>>>>>> >>>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>>> native >>>>>>>>>> name is not set. >>>>>>>>>> >>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>> >>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>> check - >>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>> then >>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>> work >>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>> >>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>> exposing >>>>>>>>>> a new JVM function this way. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>>>> thread name. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>> >>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - jdk: >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>> This >>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>>>> set the >>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>> "main" >>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have >>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>> From david.holmes at oracle.com Sat Apr 16 07:25:13 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 17:25:13 +1000 Subject: RFR: JDK-8154331: main thread should be treated as JNI-attached thread. In-Reply-To: <5710EB68.2080308@gmail.com> References: <5710EB68.2080308@gmail.com> Message-ID: <5711E8D9.20805@oracle.com> Hi Yasumasa, On 15/04/2016 11:23 PM, Yasumasa Suenaga wrote: > Hi all, > > In discussion about JDK-8152690 [1], we were found a bug. > Java main thread which is started by Java launcher is not treated as JNI-attached thread. > > I uploaded a webrev. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8154331/webrev.00/ > > I cannot access JPRT. > So I need a sponsor. As I just wrote in the bug report: I think it was an oversight that when the OSX port brought this code in, the main thread was not marked as being a JNI-attached thread - as suggested by this comment: JavaThread(bool is_attaching_via_jni = false); // for main thread and JNI attached threads However because of this oversight a call to Thread.setName from the main thread would** cause the native thread name to be set (normally we don't modify JNI-attached threads). Correcting this behaviour could be seen as a regression because there would no be no way to set the native name of the main thread. Given that we don't actually gain anything by "fixing" this I'm inclined to simply leave it as-is. ** I haven't actually verified this as I don't have access to a system I can check it on right now. But based on code inspection this appears to be the case. Thanks, David > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040251.html > From david.holmes at oracle.com Sat Apr 16 07:41:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 17:41:44 +1000 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> Message-ID: <5711ECB8.5090100@oracle.com> Hi Hiroshi, As the diff file does not survive the mail process I can't see the actual proposed changes. There doesn't seem to be a bug for this so could you please file one. Also can you get someone to host the webrev for you on cr.openjdk.java.net? Or else include the diff in the bug report. It is fine for ppc to have variations of cmpxchg with different memory barrier semantics, but the shared API must not be affected as there is a requirement that the basic form of this operation provide "full bi-directional fence" semantics. Note that these semantics are not in place to fulfill Java Memory Model requirements, but are an internal contract in hotspot. Thanks, David On 12/04/2016 3:59 AM, Christian Thalinger wrote: > [This should be on hotspot-runtime-dev. BCC?ing hotspot-compiler-dev.] > >> On Apr 8, 2016, at 12:53 AM, Hiroshi H Horii wrote: >> >> Dear all: >> >> Can I please request reviews for the following change? >> This change was created for JDK 9 and ppc64. >> >> Description: >> This change adds options of compare-and-exchange for POWER architecture. >> As described in atomic_linux_ppc.inline.hpp, the current implementation of >> cmpxchg is fence_cmpxchg_acquire. This implementation is useful for >> general purposes because twice calls of sync before and after cmpxchg will >> keep consistency. However, they sometimes cause overheads because >> sync instructions are very expensive in the current POWER chip design. >> With this change, callers can explicitly specify to run fence and acquire with >> two additional bool parameters. Because their default values are "true", >> it is not necessary to modify existing cmpxchg calls. >> >> In addition, with the new parameters of cmpxchg, this change improves >> performance of copy_to_survivor in the parallel GC. >> copy_to_survivor changes forward pointers by using cmpxchg. This >> operation doesn't require any sync instructions, in my understanding. >> A pointer is changed at most once in a GC and when cmpxchg fails, >> the latest pointer is available for the caller. >> >> When I evaluated SPECjbb2013 (slightly customized because obsolete grizzly >> doesn't support new version format of Java 9), pause time of young GC was >> reduced from 10% to 20%. >> >> Summary of source code changes: >> >> * src/share/vm/runtime/atomic.hpp >> * src/share/vm/runtime/atomic.cpp >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >> - Add two arguments of fence and acquire to cmpxchg only for PPC64. >> Though cmpxchg in atomic_linux_ppc.inline.hpp has some branches, >> they are reduced while inlining to callers. >> >> * src/share/vm/oops/oop.inline.hpp >> - Changed cas_set_mark to call cmpxchg without fence and acquire. >> cas_set_mark is called only by cas_forward_to that is called only by >> copy_to_survivor_space and oop_promotion_failed in >> psPromotionManager. >> >> Code change: >> >> Please see an attached diff file that was generated with "hg diff -g" >> under the latest hotspot directory. >> >> Passed test: >> SPECjbb2013 (customized) >> >> * I believe some other cmpxchg will be optimized by reducing fence >> or acquire because twice calls of sync are too conservative to implement >> Java memory model. >> >> >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, Ph.D. >> IBM Research - Tokyo >> > From david.holmes at oracle.com Sat Apr 16 07:43:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 17:43:20 +1000 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> Message-ID: <5711ED18.7000706@oracle.com> Hi Hiroshi, As the diff file does not survive the mail process I can't see the actual proposed changes. There doesn't seem to be a bug for this so could you please file one. Also can you get someone to host the webrev for you on cr.openjdk.java.net? Or else include the diff in the bug report. It is fine for ppc to have variations of cmpxchg with different memory barrier semantics, but the shared API must not be affected as there is a requirement that the basic form of this operation provide "full bi-directional fence" semantics. Note that these semantics are not in place to fulfill Java Memory Model requirements, but are an internal contract in hotspot. Thanks, David On 12/04/2016 3:59 AM, Christian Thalinger wrote: > [This should be on hotspot-runtime-dev. BCC?ing hotspot-compiler-dev.] > >> On Apr 8, 2016, at 12:53 AM, Hiroshi H Horii wrote: >> >> Dear all: >> >> Can I please request reviews for the following change? >> This change was created for JDK 9 and ppc64. >> >> Description: >> This change adds options of compare-and-exchange for POWER architecture. >> As described in atomic_linux_ppc.inline.hpp, the current implementation of >> cmpxchg is fence_cmpxchg_acquire. This implementation is useful for >> general purposes because twice calls of sync before and after cmpxchg will >> keep consistency. However, they sometimes cause overheads because >> sync instructions are very expensive in the current POWER chip design. >> With this change, callers can explicitly specify to run fence and acquire with >> two additional bool parameters. Because their default values are "true", >> it is not necessary to modify existing cmpxchg calls. >> >> In addition, with the new parameters of cmpxchg, this change improves >> performance of copy_to_survivor in the parallel GC. >> copy_to_survivor changes forward pointers by using cmpxchg. This >> operation doesn't require any sync instructions, in my understanding. >> A pointer is changed at most once in a GC and when cmpxchg fails, >> the latest pointer is available for the caller. >> >> When I evaluated SPECjbb2013 (slightly customized because obsolete grizzly >> doesn't support new version format of Java 9), pause time of young GC was >> reduced from 10% to 20%. >> >> Summary of source code changes: >> >> * src/share/vm/runtime/atomic.hpp >> * src/share/vm/runtime/atomic.cpp >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >> - Add two arguments of fence and acquire to cmpxchg only for PPC64. >> Though cmpxchg in atomic_linux_ppc.inline.hpp has some branches, >> they are reduced while inlining to callers. >> >> * src/share/vm/oops/oop.inline.hpp >> - Changed cas_set_mark to call cmpxchg without fence and acquire. >> cas_set_mark is called only by cas_forward_to that is called only by >> copy_to_survivor_space and oop_promotion_failed in >> psPromotionManager. >> >> Code change: >> >> Please see an attached diff file that was generated with "hg diff -g" >> under the latest hotspot directory. >> >> Passed test: >> SPECjbb2013 (customized) >> >> * I believe some other cmpxchg will be optimized by reducing fence >> or acquire because twice calls of sync are too conservative to implement >> Java memory model. >> >> >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, Ph.D. >> IBM Research - Tokyo >> > From david.holmes at oracle.com Sat Apr 16 09:04:02 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 19:04:02 +1000 Subject: RFR (S): 8153751: Windows Atomic and OrderAccess are not emitting explicit compiler barriers In-Reply-To: <57077322.3000009@oracle.com> References: <57077322.3000009@oracle.com> Message-ID: <57120002.90703@oracle.com> Hi Erik, Still catching up on vacation email backlog but I will review this asap. I see no one else has been game to step in yet :) David On 8/04/2016 7:00 PM, Erik ?sterlund wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153751 > Webrev: http://cr.openjdk.java.net/~eosterlund/8153751/webrev.00/ > > It turns out that on Windows, compiler barriers are not used for > Atomic:: code and some code in OrderAccess. It is assumed that the > non-volatile accesses will not be reordered across __asm statements, as > the current memory model should prevent. But I have not found any > guarantees that this is the case for __asm. > > The closest source I could find is the documentation for the > MemoryBarrier macro that uses an __asm statement to produce a hardware > membar. The documentation says the following: "Creates a hardware memory > barrier (fence) that prevents the CPU from re-ordering read and write > operations. It may also prevent the compiler from re-ordering read and > write operations." > > Note the "MAY" prevent compiler reordering. (*facepalm*) This sounds to > me like __asm really does not guarantee compiler reordering across __asm > at all. > > A suspected victim of this reordering is here: > https://bugs.openjdk.java.net/browse/JDK-8033545 > > To make the use of these classes more safe, I propose to simply add > explicit compiler barriers in this windows code. It should not make any > difference, as I am only enforcing compiler reordering rules that should > already hold. > > This small patch fixes this. The only thing to note is that the __asm > statements that put things in %eax and avoid returning anything. > > Testing: JPRT > > Thanks, > /Erik From david.holmes at oracle.com Sat Apr 16 09:21:20 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 19:21:20 +1000 Subject: RFR(M): 8153076: Atomic::* on Solaris should use inline assembly instead of .il files In-Reply-To: <570B9121.1010908@oracle.com> References: <57079B83.5040906@oracle.com> <57084ABD.7080106@oracle.com> <570B6C1D.2000407@oracle.com> <570B9121.1010908@oracle.com> Message-ID: <57120410.1010208@oracle.com> On 11/04/2016 9:57 PM, Claes Redestad wrote: > Not really a qualified reviewer in this area, but I think this looks great! > > Shouldn't the remaining solaris 32-bit build support in the (old) > makefiles and sources be purged altogether? Is there any point in > holding on to things like solaris_x86_32.s (which in turn is referencing > non-existent sources like os_solaris_i486.cpp)? I think the last time this was raised it was pointed out that non-Oracle JDK builders still build 32-bit Solaris. Otherwise eradicating 32-bit Solris support would be a separate RFE. David > Thanks! > > /Claes > > On 2016-04-11 11:19, Erik ?sterlund wrote: >> Hi Dean, >> >> Changing the input to a memory operand did indeed work better. Thanks >> for the great idea. >> I updated the x86 code with cleaner assembly. >> >> Updated webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.01/ >> >> Thanks, >> /Erik >> >> On 2016-04-09 02:20, Dean Long wrote: >>> Hi Erik. Does this work any better? >>> >>> __asm__ volatile ("lock; addl $1,%0" : "+m" (*dest) : : "cc", >>> "memory"); >>> >>> >>> dl >>> >>> On 4/8/2016 4:52 AM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153076 >>>> Webrev: http://cr.openjdk.java.net/~eosterlund/8153076/webrev.00/ >>>> >>>> On Solaris, the Atomic class puts its assembly in a separate .il >>>> file, then the code blobs are declared as extern "C" and called from >>>> Atomic. More modern GCC-style inline assembly is now supported, and >>>> we should use that instead. It works fine the way it is, but making >>>> calls just to get an instruction that could be inlined, seems >>>> suboptimal. >>>> >>>> There are two important things to note: >>>> >>>> 1) I have removed all the 32 bit code from solaris Atomic, and weird >>>> combinations with GCC and compiler1. JDK9 is only supported on 64 >>>> bit SPARC and x86, building using Solaris Studio. Since it is using >>>> GCC-style inline assembly, the code should work with GCC too, but I >>>> have not tested that as it is not a supported way of building >>>> OpenJDK. I personally do not think we should spend too much time on >>>> supporting unsupported code. >>>> >>>> 2) There appears to be a bug in Solaris Studio for emitting memory >>>> accesses on x86. >>>> >>>> The following code: >>>> >>>> inline void Atomic::inc (volatile jint* dest) { >>>> __asm__ volatile ("lock; addl $1,(%0)" : >>>> : "r" (dest) : "cc", "memory"); >>>> } >>>> >>>> generated the following in HandleMark::initialize(Thread* thread) on >>>> Solaris, x64, using SS12.4: >>>> >>>> lock addl $1, (%eax) >>>> >>>> Note the %eax instead of %rax. It is wrong and caused SIGSEGV as the >>>> address was truncated, and libraries are not put within the first 4 >>>> GB of VA. >>>> >>>> I worked around the issue by assigning the address operands to a >>>> fixed register, rdx. Being awkward with the choice of registers is >>>> still better than having to make calls. This will have to be fixed, >>>> once the solaris studio bug is fixed. >>>> >>>> Note that for SPARC there were no issues like this and the generated >>>> code is fine. >>>> >>>> Testing: JPRT >>>> >>>> I need a sponsor to push this. >>>> >>>> Thanks, >>>> /Erik >>> >> > From yasuenag at gmail.com Sat Apr 16 09:29:36 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 16 Apr 2016 18:29:36 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5711E587.4050805@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> Message-ID: <57120600.6090005@gmail.com> Hi David, I uploaded new webrev: - hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ - jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ > it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? I added a flag for setting native thread name to JNI-attached thread. This change can set native thread name if main thread changes to JNI-attached thread. Thanks, Yasumasa On 2016/04/16 16:11, David Holmes wrote: > On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >> Hi David, >> >>> That change in behaviour may be a problem, it could be considered a >>> regression that setName stops setting the native thread main, even >>> though we never really intended it to work in the first place. :( Such >>> a change needs to go through CCC. >> >> I understood. >> Can I send CCC request? >> (I'm jdk 9 commiter, but I'm not employee at Oracle.) > > Sorry you can't file a CCC request, you would need a sponsor for that. But at this stage I don't think I agree with the proposed change because of the change in behaviour - there's no way to restore the "broken" behaviour. > >> I want to continue to discuss about it on JDK-8154331 [1]. > > Okay we can do that. > >> >>> Further, we expect the launcher to use the supported JNI interface (as >>> other processes would), not the internal JVM interface that exists for >>> the JDK sources to communicate with the JVM. >> >> I think that we do not use JVM interface if we add new method in >> LauncherHelper as below: >> ---------------- >> diff -r f02139a1ac84 >> src/java.base/share/classes/sun/launcher/LauncherHelper.java >> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >> Wed Apr 13 14:19:30 2016 +0000 >> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >> Sat Apr 16 11:25:53 2016 +0900 >> @@ -960,4 +960,8 @@ >> else >> return md.toNameAndVersion() + " (" + loc + ")"; >> } >> + >> + static void setNativeThreadName(String name) { >> + Thread.currentThread().setName(name); >> + } > > You could also make that call via JNI directly, so not sure the helper adds much here. But it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? > > David > ----- > >> } >> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >> 2016 +0000 >> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >> 2016 +0900 >> @@ -125,6 +125,7 @@ >> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >> static void ShowSettings(JNIEnv* env, char *optString); >> static void ListModules(JNIEnv* env, char *optString); >> +static void SetNativeThreadName(JNIEnv* env, char *name); >> >> static void SetPaths(int argc, char **argv); >> >> @@ -325,6 +326,7 @@ >> * mainThread.isAlive() to work as expected. >> */ >> #define LEAVE() \ >> + SetNativeThreadName(env, "DestroyJavaVM"); \ >> do { \ >> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >> JLI_ReportErrorMessage(JVM_ERROR2); \ >> @@ -488,6 +490,9 @@ >> mainArgs = CreateApplicationArgs(env, argv, argc); >> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >> >> + /* Set native thread name. */ >> + SetNativeThreadName(env, "main"); >> + >> /* Invoke main method. */ >> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >> >> @@ -1686,6 +1691,22 @@ >> joptString); >> } >> >> +/** >> + * Set native thread name as possible. >> + */ >> +static void >> +SetNativeThreadName(JNIEnv *env, char *name) >> +{ >> + jmethodID setNativeThreadNameID; >> + jstring nameString; >> + jclass cls = GetLauncherHelperClass(env); >> + NULL_CHECK(cls); >> + NULL_CHECK(setNativeThreadNameID = (*env)->GetStaticMethodID(env, cls, >> + "setNativeThreadName", "(Ljava/lang/String;)V")); >> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >> nameString); >> +} >> + >> /* >> * Prints default usage or the Xusage message, see >> sun.launcher.LauncherHelper.java >> */ >> ---------------- >> >> So I want to add new arg to JVM_SetNativeThreadName(). >> >>> However this is still a change to the exported JVM interface and so >>> has to be approved. >> >> Do you mean that this change needs CCC? >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >> >> >> >> On 2016/04/16 7:26, David Holmes wrote: >>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> I think it is a bug based on the comment here: >>>>> >>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>> JNI attached threads >>>> >>>> I filed it to JBS as JDK-8154331. >>>> I will send review request to hotspot-runtime-dev. >>>> >>>> >>>>> Though that will introduce a change in behaviour by itself as setName >>>>> will no longer set the native name for the main thread. >>>> >>>> I know. >>> >>> That change in behaviour may be a problem, it could be considered a >>> regression that setName stops setting the native thread main, even >>> though we never really intended it to work in the first place. :( Such >>> a change needs to go through CCC. >>> >>>> I checked changeset history. >>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>>> backported JDK 8. >>> >>> Yes this all came in as part of the OSX port in 7u2. >>> >>>> However, this function seems to be called from Thread#setNativeName() >>>> only. >>>> In addition, Thread#setNativeName() is private method. >>>> >>>> Thus I think that we can add an argument to JVM_SetNativeThreadName() >>>> for force setting. >>>> (e.g. "bool forced") >>>> >>>> It makes a change of JVM API. >>>> However, this function is NOT public, so I think we can add one more >>>> argument. >>>> >>>> What do you think about this? >>>> If it is accepted, we can set native thread name from Java launcher. >>> >>> The private/public aspect of the Java API is not really at issue. Yes >>> we would add another arg to the JVM function to allow it to apply to >>> JNI-attached threads as well (I'd prefer the arg reflect that not just >>> "force"). However this is still a change to the exported JVM interface >>> and so has to be approved. Further, we expect the launcher to use the >>> supported JNI interface (as other processes would), not the internal >>> JVM interface that exists for the JDK sources to communicate with the >>> JVM. >>> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/15 19:16, David Holmes wrote: >>>>> Hi Yasumasa, >>>>> >>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> The fact that the "main" thread is not tagged as being a JNI-attached >>>>>>> thread seems accidental to me >>>>>> >>>>>> Should I file it to JBS? >>>>> >>>>> I think it is a bug based on the comment here: >>>>> >>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>> JNI attached threads >>>>> >>>>> Though that will introduce a change in behaviour by itself as setName >>>>> will no longer set the native name for the main thread. >>>>> >>>>>> I think that we can fix as below: >>>>>> --------------- >>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>>> @@ -3592,7 +3592,7 @@ >>>>>> #endif // INCLUDE_JVMCI >>>>>> >>>>>> // Attach the main thread to this os thread >>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>> main_thread->initialize_thread_current(); >>>>>> // must do this before set_active_handles >>>>>> @@ -3776,6 +3776,9 @@ >>>>>> // Notify JVMTI agents that VM initialization is complete - nop if >>>>>> no agents. >>>>>> JvmtiExport::post_vm_initialized(); >>>>>> >>>>>> + // Change attach status to "attached" >>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>> + >>>>> >>>>> I think we can do this straight after the JavaThread constructor. >>>>> >>>>>> if (TRACE_START() != JNI_OK) { >>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>> backend."); >>>>>> } >>>>>> --------------- >>>>>> >>>>>> >>>>>>> If it wants to name its native threads then it is free to do so, >>>>>> >>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread name >>>>>> when the caller thread is JNI-attached thread. >>>>>> However, I think that it should be changed if Java developer calls >>>>>> Thread#setName() explicitly. >>>>>> It is not the same of changing native thread name at >>>>>> Threads::create_vm(). >>>>>> >>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>> What do you think about this? >>>>> >>>>> The decision to not change the name of JNI-attached threads was a >>>>> deliberate one** - this functionality originated with the OSX port and >>>>> it was reported that the initial feedback with this feature was to >>>>> ensure it didn't mess with thread names that had been set by the host >>>>> process. If we do as you propose then we will just have an >>>>> inconsistency for people to complain about: "why does my native thread >>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>> >>>>> ** If you follow the bugs and related discussions on this, the >>>>> semantics and limitations (truncation, current thread only, non-JNI >>>>> threads only) of setting the native thread name were supposed to be >>>>> documented in the release notes - but as far as I can see that never >>>>> happened. :( >>>>> >>>>> My position on this remains that if it is desirable for the main >>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>> launcher needs to be setting them using the available platform APIs. >>>>> Unfortunately this is complicated - as evidenced by the VM code for >>>>> this - due to the need to verify API availability. >>>>> >>>>> Any change in behaviour in relation to Thread.setName would have to go >>>>> through our CCC process I think. But a change in the launcher would >>>>> not. >>>>> >>>>> Sorry. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> --------------- >>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>>> @@ -3187,7 +3187,7 @@ >>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>> // Thread naming only supported for the current thread, doesn't >>>>>> work >>>>>> for >>>>>> // target threads. >>>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>>>> + if (Thread::current() == thr) { >>>>>> // we don't set the name of an attached thread to avoid stepping >>>>>> // on other programs >>>>>> const char *thread_name = >>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>> --------------- >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>> >>>>>>> >>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>> Roger, >>>>>>>> Thanks for your comment! >>>>>>>> >>>>>>>> David, >>>>>>>> >>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>> exposing >>>>>>>>>>> a new JVM function this way. >>>>>>>> >>>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>>> calling >>>>>>>> main method), >>>>>>>> I could set native thread name. >>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't >>>>>>>> set >>>>>>>> native thread name for DestroyJavaVM. >>>>>>> >>>>>>> Right - I came to the same realization earlier this morning. Which, >>>>>>> unfortunately, takes me back to the basic premise here that we don't >>>>>>> set the name of threads not created by the JVM. The fact that the >>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>>> accident for the initial attach, and can't be used for the >>>>>>> DestroyJavaVM part - which leaves the thread inconsistently named at >>>>>>> the native level. >>>>>>> >>>>>>> I'm afraid my view here is that the launcher has to be treated like >>>>>>> any other process that might host a JVM. If it wants to name its >>>>>>> native threads then it is free to do so, but I would not be exporting >>>>>>> a function from the JVM to do that - it would have to use the OS >>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>> >>>>>>> Sorry. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Comments: >>>>>>>>> >>>>>>>>> jvm.h: The function names are too similar but perform different >>>>>>>>> functions: >>>>>>>>> >>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>> >>>>>>>>> - The first function applies to the current thread, the second >>>>>>>>> one a >>>>>>>>> specific java thread. >>>>>>>>> It would seem useful for there to be a comment somewhere about >>>>>>>>> what >>>>>>>>> the new function does. >>>>>>>>> >>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>> instead of >>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>> as is done on unix and mac. >>>>>>>>> >>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>>>>> line 730 >>>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>>>>> same >>>>>>>>> line as dlsym... >>>>>>>>> >>>>>>>>> $.02, Roger >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>> check - >>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>> then >>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>> work >>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>> >>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>>>>> thread name (test) was set. >>>>>>>>>> --------- >>>>>>>>>> public class Sleep{ >>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> --------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>> exposing >>>>>>>>>>> a new JVM function this way. >>>>>>>>>> >>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>>>>>>> uses it >>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>> >>>>>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>>>>> need to >>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>>>>> rather >>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>>> needed in >>>>>>>>>>>>> that case. >>>>>>>>>>>> >>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>>> Thread#init(), >>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>> >>>>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>>>> native >>>>>>>>>>> name is not set. >>>>>>>>>>> >>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>> >>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>> check - >>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>> then >>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>> work >>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>> >>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>> exposing >>>>>>>>>>> a new JVM function this way. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>>>>> thread name. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>> >>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>> This >>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have >>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> From david.holmes at oracle.com Sat Apr 16 09:35:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 19:35:55 +1000 Subject: RFR(XS) 8152846: Creation of ModuleEntryTable Investigate Need For OrderAccess::storestore() In-Reply-To: <5703FB65.7060504@oracle.com> References: <5703FB65.7060504@oracle.com> Message-ID: <5712077B.1090605@oracle.com> Hi Harold, On 6/04/2016 3:52 AM, harold seigel wrote: > Hi, > > Please review this small change to fix bug 8152846. > > This change removes an unneeded OrderAccess::storestore() call. > > Webrev: http://javaweb.us.oracle.com/~hseigel/webrev/bug_8152846/ Please ensure you provide an accessible webrev link please. I have a concern with this code. I think the storeStore as written was in the wrong place. The main concern with lock-free read of a field like _packages is that if you see a non-null value then you also see all the stores that were made as part of the construction of the object _packages refers to. In that regard I think the original code: // Ensure _packages is stable, since it is examined without a lock OrderAccess::storestore(); _packages = new PackageEntryTable(PackageEntryTable::_packagetable_entry_size); } return _packages; Should really have bee: temp = new PackageEntryTable(PackageEntryTable::_packagetable_entry_size); OrderAccess::storeStore(); _packages = tmp; ... though to be sure we need to examine the lock-free usage of _packages. David ----- > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152846 > > The fix was tested with JCK API, Lang, and VM tests, the UTE > non-colocated quick tests, and the hotspot, JDK vm, java/io, java/lang, > java/util, and java/security tests. Testing with UTE colocated tests is > in progress. > > Thanks, Harold From david.holmes at oracle.com Sat Apr 16 09:39:11 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Apr 2016 19:39:11 +1000 Subject: RFR(XS) 8152846: Creation of ModuleEntryTable Investigate Need For OrderAccess::storestore() In-Reply-To: <5703FB65.7060504@oracle.com> References: <5703FB65.7060504@oracle.com> Message-ID: <5712083F.1050702@oracle.com> Hi Harold, On 6/04/2016 3:52 AM, harold seigel wrote: > Hi, > > Please review this small change to fix bug 8152846. > > This change removes an unneeded OrderAccess::storestore() call. > > Webrev: http://javaweb.us.oracle.com/~hseigel/webrev/bug_8152846/ Please ensure you provide an accessible webrev link please. I have a concern with this code. I think the storeStore as written was in the wrong place. The main concern with lock-free read of a field like _packages is that if you see a non-null value then you also see all the stores that were made as part of the construction of the object _packages refers to. In that regard I think the original code: // Ensure _packages is stable, since it is examined without a lock OrderAccess::storestore(); _packages = new PackageEntryTable(PackageEntryTable::_packagetable_entry_size); } return _packages; Should really have been: temp = new PackageEntryTable(PackageEntryTable::_packagetable_entry_size); OrderAccess::storeStore(); _packages = tmp; ... though to be sure we need to examine the lock-free usage of _packages. And to be really correct the store to _packages should be a storeRelease (no storestore barrier) and the lock-free read should be a readAcquire. David ----- > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152846 > > The fix was tested with JCK API, Lang, and VM tests, the UTE > non-colocated quick tests, and the hotspot, JDK vm, java/io, java/lang, > java/util, and java/security tests. Testing with UTE colocated tests is > in progress. > > Thanks, Harold From yasuenag at gmail.com Sat Apr 16 12:03:18 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 16 Apr 2016 21:03:18 +0900 Subject: RFR: JDK-8154331: main thread should be treated as JNI-attached thread. In-Reply-To: <5711E8D9.20805@oracle.com> References: <5710EB68.2080308@gmail.com> <5711E8D9.20805@oracle.com> Message-ID: <57122A06.8020709@gmail.com> Hi David, > Correcting this behaviour could be seen as > a regression because there would no be no way to set the native name of > the main thread. If my proposal in JDK-8152690 [1] is merged, Java developer can change native thread name with reflection. IMHO, we can merge changes for jvm.cpp and Thread.{c,java} to this issue from JDK-8152690. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040276.html On 2016/04/16 16:25, David Holmes wrote: > Hi Yasumasa, > > On 15/04/2016 11:23 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> In discussion about JDK-8152690 [1], we were found a bug. >> Java main thread which is started by Java launcher is not treated as JNI-attached thread. >> >> I uploaded a webrev. >> Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8154331/webrev.00/ >> >> I cannot access JPRT. >> So I need a sponsor. > > As I just wrote in the bug report: > > I think it was an oversight that when the OSX port brought this code in, > the main thread was not marked as being a JNI-attached thread - as > suggested by this comment: > > JavaThread(bool is_attaching_via_jni = false); // for main thread and > JNI attached threads > > However because of this oversight a call to Thread.setName from the main > thread would** cause the native thread name to be set (normally we don't > modify JNI-attached threads). Correcting this behaviour could be seen as > a regression because there would no be no way to set the native name of > the main thread. > > Given that we don't actually gain anything by "fixing" this I'm inclined > to simply leave it as-is. > > ** I haven't actually verified this as I don't have access to a system I > can check it on right now. But based on code inspection this appears to > be the case. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040251.html >> From david.holmes at oracle.com Sat Apr 16 22:20:41 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 17 Apr 2016 08:20:41 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57120600.6090005@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> Message-ID: <5712BAB9.5040400@oracle.com> Hi Yasumasa, On 16/04/2016 7:29 PM, Yasumasa Suenaga wrote: > Hi David, > > I uploaded new webrev: > > - hotspot: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ > > - jdk: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ Ah sneaky! :) Using JNI to by-pass access control so we can set up a private method to do the name setting, yet avoid any API change that would require a CCC request. I think I like it. :) Need to hear from core-libs and/or launcher folk as this touches a number of pieces of code. Thanks, David ----- > >> it won't work unless you change the semantics of setName so I'm not >> sure what you were thinking here. To take advantage of an arg taking >> JVM_SetNativThreadName you would need to call it directly as no Java >> code will call it . ??? > > I added a flag for setting native thread name to JNI-attached thread. > This change can set native thread name if main thread changes to > JNI-attached thread. > > > Thanks, > > Yasumasa > > > On 2016/04/16 16:11, David Holmes wrote: >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> That change in behaviour may be a problem, it could be considered a >>>> regression that setName stops setting the native thread main, even >>>> though we never really intended it to work in the first place. :( Such >>>> a change needs to go through CCC. >>> >>> I understood. >>> Can I send CCC request? >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >> >> Sorry you can't file a CCC request, you would need a sponsor for that. >> But at this stage I don't think I agree with the proposed change >> because of the change in behaviour - there's no way to restore the >> "broken" behaviour. >> >>> I want to continue to discuss about it on JDK-8154331 [1]. >> >> Okay we can do that. >> >>> >>>> Further, we expect the launcher to use the supported JNI interface (as >>>> other processes would), not the internal JVM interface that exists for >>>> the JDK sources to communicate with the JVM. >>> >>> I think that we do not use JVM interface if we add new method in >>> LauncherHelper as below: >>> ---------------- >>> diff -r f02139a1ac84 >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> Wed Apr 13 14:19:30 2016 +0000 >>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> Sat Apr 16 11:25:53 2016 +0900 >>> @@ -960,4 +960,8 @@ >>> else >>> return md.toNameAndVersion() + " (" + loc + ")"; >>> } >>> + >>> + static void setNativeThreadName(String name) { >>> + Thread.currentThread().setName(name); >>> + } >> >> You could also make that call via JNI directly, so not sure the helper >> adds much here. But it won't work unless you change the semantics of >> setName so I'm not sure what you were thinking here. To take advantage >> of an arg taking JVM_SetNativThreadName you would need to call it >> directly as no Java code will call it . ??? >> >> David >> ----- >> >>> } >>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >>> 2016 +0000 >>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >>> 2016 +0900 >>> @@ -125,6 +125,7 @@ >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>> static void ShowSettings(JNIEnv* env, char *optString); >>> static void ListModules(JNIEnv* env, char *optString); >>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>> >>> static void SetPaths(int argc, char **argv); >>> >>> @@ -325,6 +326,7 @@ >>> * mainThread.isAlive() to work as expected. >>> */ >>> #define LEAVE() \ >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>> do { \ >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>> @@ -488,6 +490,9 @@ >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>> >>> + /* Set native thread name. */ >>> + SetNativeThreadName(env, "main"); >>> + >>> /* Invoke main method. */ >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>> >>> @@ -1686,6 +1691,22 @@ >>> joptString); >>> } >>> >>> +/** >>> + * Set native thread name as possible. >>> + */ >>> +static void >>> +SetNativeThreadName(JNIEnv *env, char *name) >>> +{ >>> + jmethodID setNativeThreadNameID; >>> + jstring nameString; >>> + jclass cls = GetLauncherHelperClass(env); >>> + NULL_CHECK(cls); >>> + NULL_CHECK(setNativeThreadNameID = >>> (*env)->GetStaticMethodID(env, cls, >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>> nameString); >>> +} >>> + >>> /* >>> * Prints default usage or the Xusage message, see >>> sun.launcher.LauncherHelper.java >>> */ >>> ---------------- >>> >>> So I want to add new arg to JVM_SetNativeThreadName(). >>> >>>> However this is still a change to the exported JVM interface and so >>>> has to be approved. >>> >>> Do you mean that this change needs CCC? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>> >>> >>> >>> >>> On 2016/04/16 7:26, David Holmes wrote: >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> I think it is a bug based on the comment here: >>>>>> >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>>> JNI attached threads >>>>> >>>>> I filed it to JBS as JDK-8154331. >>>>> I will send review request to hotspot-runtime-dev. >>>>> >>>>> >>>>>> Though that will introduce a change in behaviour by itself as setName >>>>>> will no longer set the native name for the main thread. >>>>> >>>>> I know. >>>> >>>> That change in behaviour may be a problem, it could be considered a >>>> regression that setName stops setting the native thread main, even >>>> though we never really intended it to work in the first place. :( Such >>>> a change needs to go through CCC. >>>> >>>>> I checked changeset history. >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>>>> backported JDK 8. >>>> >>>> Yes this all came in as part of the OSX port in 7u2. >>>> >>>>> However, this function seems to be called from Thread#setNativeName() >>>>> only. >>>>> In addition, Thread#setNativeName() is private method. >>>>> >>>>> Thus I think that we can add an argument to JVM_SetNativeThreadName() >>>>> for force setting. >>>>> (e.g. "bool forced") >>>>> >>>>> It makes a change of JVM API. >>>>> However, this function is NOT public, so I think we can add one more >>>>> argument. >>>>> >>>>> What do you think about this? >>>>> If it is accepted, we can set native thread name from Java launcher. >>>> >>>> The private/public aspect of the Java API is not really at issue. Yes >>>> we would add another arg to the JVM function to allow it to apply to >>>> JNI-attached threads as well (I'd prefer the arg reflect that not just >>>> "force"). However this is still a change to the exported JVM interface >>>> and so has to be approved. Further, we expect the launcher to use the >>>> supported JNI interface (as other processes would), not the internal >>>> JVM interface that exists for the JDK sources to communicate with the >>>> JVM. >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> The fact that the "main" thread is not tagged as being a >>>>>>>> JNI-attached >>>>>>>> thread seems accidental to me >>>>>>> >>>>>>> Should I file it to JBS? >>>>>> >>>>>> I think it is a bug based on the comment here: >>>>>> >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>>> JNI attached threads >>>>>> >>>>>> Though that will introduce a change in behaviour by itself as setName >>>>>> will no longer set the native name for the main thread. >>>>>> >>>>>>> I think that we can fix as below: >>>>>>> --------------- >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 >>>>>>> +0200 >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 >>>>>>> +0900 >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>> #endif // INCLUDE_JVMCI >>>>>>> >>>>>>> // Attach the main thread to this os thread >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>> main_thread->initialize_thread_current(); >>>>>>> // must do this before set_active_handles >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>> // Notify JVMTI agents that VM initialization is complete - >>>>>>> nop if >>>>>>> no agents. >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>> >>>>>>> + // Change attach status to "attached" >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>> + >>>>>> >>>>>> I think we can do this straight after the JavaThread constructor. >>>>>> >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>>> backend."); >>>>>>> } >>>>>>> --------------- >>>>>>> >>>>>>> >>>>>>>> If it wants to name its native threads then it is free to do so, >>>>>>> >>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread >>>>>>> name >>>>>>> when the caller thread is JNI-attached thread. >>>>>>> However, I think that it should be changed if Java developer calls >>>>>>> Thread#setName() explicitly. >>>>>>> It is not the same of changing native thread name at >>>>>>> Threads::create_vm(). >>>>>>> >>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>>> What do you think about this? >>>>>> >>>>>> The decision to not change the name of JNI-attached threads was a >>>>>> deliberate one** - this functionality originated with the OSX port >>>>>> and >>>>>> it was reported that the initial feedback with this feature was to >>>>>> ensure it didn't mess with thread names that had been set by the host >>>>>> process. If we do as you propose then we will just have an >>>>>> inconsistency for people to complain about: "why does my native >>>>>> thread >>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>>> >>>>>> ** If you follow the bugs and related discussions on this, the >>>>>> semantics and limitations (truncation, current thread only, non-JNI >>>>>> threads only) of setting the native thread name were supposed to be >>>>>> documented in the release notes - but as far as I can see that never >>>>>> happened. :( >>>>>> >>>>>> My position on this remains that if it is desirable for the main >>>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>>> launcher needs to be setting them using the available platform APIs. >>>>>> Unfortunately this is complicated - as evidenced by the VM code for >>>>>> this - due to the need to verify API availability. >>>>>> >>>>>> Any change in behaviour in relation to Thread.setName would have >>>>>> to go >>>>>> through our CCC process I think. But a change in the launcher would >>>>>> not. >>>>>> >>>>>> Sorry. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> --------------- >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 >>>>>>> +0200 >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 >>>>>>> +0900 >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>>> // Thread naming only supported for the current thread, doesn't >>>>>>> work >>>>>>> for >>>>>>> // target threads. >>>>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>>>>> + if (Thread::current() == thr) { >>>>>>> // we don't set the name of an attached thread to avoid >>>>>>> stepping >>>>>>> // on other programs >>>>>>> const char *thread_name = >>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>> >>>>>>> --------------- >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>> Roger, >>>>>>>>> Thanks for your comment! >>>>>>>>> >>>>>>>>> David, >>>>>>>>> >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>> exposing >>>>>>>>>>>> a new JVM function this way. >>>>>>>>> >>>>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>>>> calling >>>>>>>>> main method), >>>>>>>>> I could set native thread name. >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't >>>>>>>>> set >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>> >>>>>>>> Right - I came to the same realization earlier this morning. Which, >>>>>>>> unfortunately, takes me back to the basic premise here that we >>>>>>>> don't >>>>>>>> set the name of threads not created by the JVM. The fact that the >>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>>>> accident for the initial attach, and can't be used for the >>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >>>>>>>> named at >>>>>>>> the native level. >>>>>>>> >>>>>>>> I'm afraid my view here is that the launcher has to be treated like >>>>>>>> any other process that might host a JVM. If it wants to name its >>>>>>>> native threads then it is free to do so, but I would not be >>>>>>>> exporting >>>>>>>> a function from the JVM to do that - it would have to use the OS >>>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>>> >>>>>>>> Sorry. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Comments: >>>>>>>>>> >>>>>>>>>> jvm.h: The function names are too similar but perform different >>>>>>>>>> functions: >>>>>>>>>> >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>>> >>>>>>>>>> - The first function applies to the current thread, the second >>>>>>>>>> one a >>>>>>>>>> specific java thread. >>>>>>>>>> It would seem useful for there to be a comment somewhere about >>>>>>>>>> what >>>>>>>>>> the new function does. >>>>>>>>>> >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>>> instead of >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>> as is done on unix and mac. >>>>>>>>>> >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>>>>>> line 730 >>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>>>>>> same >>>>>>>>>> line as dlsym... >>>>>>>>>> >>>>>>>>>> $.02, Roger >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>> check - >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>> then >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>>> work >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>> >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>>>>>> thread name (test) was set. >>>>>>>>>>> --------- >>>>>>>>>>> public class Sleep{ >>>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>> exposing >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>> >>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I exported new JVM function to set native thread name, >>>>>>>>>>>>>>> and JLI >>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>> >>>>>>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>>>>>> need to >>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>>>>>> rather >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>>>> needed in >>>>>>>>>>>>>> that case. >>>>>>>>>>>>> >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>> >>>>>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>>>>> native >>>>>>>>>>>> name is not set. >>>>>>>>>>>> >>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>>> >>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>> check - >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>> then >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>>> work >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>> >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>> exposing >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>>>>>> thread name. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>>>>>>>>>>>>>>>>>>>> JavaThread(); >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>>>>>>>>>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue >>>>>>>>>>>>>>>>>>>>>> Mar 29 >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed >>>>>>>>>>>>>>>>>>>>>> Mar 30 >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = >>>>>>>>>>>>>>>>>>>>>> "main"; >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>>>>>>>>>> thread); >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we >>>>>>>>>>>>>>>>>>>>>> want >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - >>>>>>>>>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I >>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> From david.holmes at oracle.com Sat Apr 16 22:25:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 17 Apr 2016 08:25:00 +1000 Subject: RFR: JDK-8154331: main thread should be treated as JNI-attached thread. In-Reply-To: <57122A06.8020709@gmail.com> References: <5710EB68.2080308@gmail.com> <5711E8D9.20805@oracle.com> <57122A06.8020709@gmail.com> Message-ID: <5712BBBC.3040401@oracle.com> On 16/04/2016 10:03 PM, Yasumasa Suenaga wrote: > Hi David, > >> Correcting this behaviour could be seen as >> a regression because there would no be no way to set the native name of >> the main thread. > > If my proposal in JDK-8152690 [1] is merged, Java developer can change native > thread name with reflection. Yes though access control may get in the way. > IMHO, we can merge changes for jvm.cpp and Thread.{c,java} to this issue > from JDK-8152690. Not sure what you mean. I want to keep the two issues distinct. This issue does introduce an incompatible change in behaviour so it may be best to defer this part until Java 10, as Dan suggested in the bug report. Thanks, David > > Thanks, > > Yasumasa > > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040276.html > > > On 2016/04/16 16:25, David Holmes wrote: >> Hi Yasumasa, >> >> On 15/04/2016 11:23 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> In discussion about JDK-8152690 [1], we were found a bug. >>> Java main thread which is started by Java launcher is not treated as JNI-attached thread. >>> >>> I uploaded a webrev. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8154331/webrev.00/ >>> >>> I cannot access JPRT. >>> So I need a sponsor. >> >> As I just wrote in the bug report: >> >> I think it was an oversight that when the OSX port brought this code in, >> the main thread was not marked as being a JNI-attached thread - as >> suggested by this comment: >> >> JavaThread(bool is_attaching_via_jni = false); // for main thread and >> JNI attached threads >> >> However because of this oversight a call to Thread.setName from the main >> thread would** cause the native thread name to be set (normally we don't >> modify JNI-attached threads). Correcting this behaviour could be seen as >> a regression because there would no be no way to set the native name of >> the main thread. >> >> Given that we don't actually gain anything by "fixing" this I'm inclined >> to simply leave it as-is. >> >> ** I haven't actually verified this as I don't have access to a system I >> can check it on right now. But based on code inspection this appears to >> be the case. >> >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040251.html >>> From yasuenag at gmail.com Sun Apr 17 03:38:44 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 17 Apr 2016 12:38:44 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5712BAB9.5040400@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5712BAB9.5040400@oracle.com> Message-ID: <57130544.8000601@gmail.com> Hi David, > Need to hear from core-libs and/or launcher folk as this touches a number of pieces of code. I'm waiting more reviewer(s) . BTW, Should I make patches which are based on jdk9/dev repos? My proposal includes hotspot changes. So I want to know whether I can push all changes jdk9/dev/{jdk,hotspot} after reviewing. I can update my webrev to adapt to jdk9/dev repos if need. Thanks, Yasumasa On 2016/04/17 7:20, David Holmes wrote: > Hi Yasumasa, > > On 16/04/2016 7:29 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> I uploaded new webrev: >> >> - hotspot: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >> >> - jdk: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ > > Ah sneaky! :) Using JNI to by-pass access control so we can set up a private method to do the name setting, yet avoid any API change that would require a CCC request. I think I like it. :) > > Need to hear from core-libs and/or launcher folk as this touches a number of pieces of code. > > Thanks, > David > ----- > >> >>> it won't work unless you change the semantics of setName so I'm not >>> sure what you were thinking here. To take advantage of an arg taking >>> JVM_SetNativThreadName you would need to call it directly as no Java >>> code will call it . ??? >> >> I added a flag for setting native thread name to JNI-attached thread. >> This change can set native thread name if main thread changes to >> JNI-attached thread. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/16 16:11, David Holmes wrote: >>> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> That change in behaviour may be a problem, it could be considered a >>>>> regression that setName stops setting the native thread main, even >>>>> though we never really intended it to work in the first place. :( Such >>>>> a change needs to go through CCC. >>>> >>>> I understood. >>>> Can I send CCC request? >>>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>> >>> Sorry you can't file a CCC request, you would need a sponsor for that. >>> But at this stage I don't think I agree with the proposed change >>> because of the change in behaviour - there's no way to restore the >>> "broken" behaviour. >>> >>>> I want to continue to discuss about it on JDK-8154331 [1]. >>> >>> Okay we can do that. >>> >>>> >>>>> Further, we expect the launcher to use the supported JNI interface (as >>>>> other processes would), not the internal JVM interface that exists for >>>>> the JDK sources to communicate with the JVM. >>>> >>>> I think that we do not use JVM interface if we add new method in >>>> LauncherHelper as below: >>>> ---------------- >>>> diff -r f02139a1ac84 >>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> Wed Apr 13 14:19:30 2016 +0000 >>>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> Sat Apr 16 11:25:53 2016 +0900 >>>> @@ -960,4 +960,8 @@ >>>> else >>>> return md.toNameAndVersion() + " (" + loc + ")"; >>>> } >>>> + >>>> + static void setNativeThreadName(String name) { >>>> + Thread.currentThread().setName(name); >>>> + } >>> >>> You could also make that call via JNI directly, so not sure the helper >>> adds much here. But it won't work unless you change the semantics of >>> setName so I'm not sure what you were thinking here. To take advantage >>> of an arg taking JVM_SetNativThreadName you would need to call it >>> directly as no Java code will call it . ??? >>> >>> David >>> ----- >>> >>>> } >>>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >>>> 2016 +0000 >>>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >>>> 2016 +0900 >>>> @@ -125,6 +125,7 @@ >>>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>> static void ShowSettings(JNIEnv* env, char *optString); >>>> static void ListModules(JNIEnv* env, char *optString); >>>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>> >>>> static void SetPaths(int argc, char **argv); >>>> >>>> @@ -325,6 +326,7 @@ >>>> * mainThread.isAlive() to work as expected. >>>> */ >>>> #define LEAVE() \ >>>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>> do { \ >>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>> @@ -488,6 +490,9 @@ >>>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>> >>>> + /* Set native thread name. */ >>>> + SetNativeThreadName(env, "main"); >>>> + >>>> /* Invoke main method. */ >>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>> >>>> @@ -1686,6 +1691,22 @@ >>>> joptString); >>>> } >>>> >>>> +/** >>>> + * Set native thread name as possible. >>>> + */ >>>> +static void >>>> +SetNativeThreadName(JNIEnv *env, char *name) >>>> +{ >>>> + jmethodID setNativeThreadNameID; >>>> + jstring nameString; >>>> + jclass cls = GetLauncherHelperClass(env); >>>> + NULL_CHECK(cls); >>>> + NULL_CHECK(setNativeThreadNameID = >>>> (*env)->GetStaticMethodID(env, cls, >>>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>>> nameString); >>>> +} >>>> + >>>> /* >>>> * Prints default usage or the Xusage message, see >>>> sun.launcher.LauncherHelper.java >>>> */ >>>> ---------------- >>>> >>>> So I want to add new arg to JVM_SetNativeThreadName(). >>>> >>>>> However this is still a change to the exported JVM interface and so >>>>> has to be approved. >>>> >>>> Do you mean that this change needs CCC? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>> >>>> >>>> >>>> >>>> On 2016/04/16 7:26, David Holmes wrote: >>>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> I think it is a bug based on the comment here: >>>>>>> >>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>>>> JNI attached threads >>>>>> >>>>>> I filed it to JBS as JDK-8154331. >>>>>> I will send review request to hotspot-runtime-dev. >>>>>> >>>>>> >>>>>>> Though that will introduce a change in behaviour by itself as setName >>>>>>> will no longer set the native name for the main thread. >>>>>> >>>>>> I know. >>>>> >>>>> That change in behaviour may be a problem, it could be considered a >>>>> regression that setName stops setting the native thread main, even >>>>> though we never really intended it to work in the first place. :( Such >>>>> a change needs to go through CCC. >>>>> >>>>>> I checked changeset history. >>>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>>>>> backported JDK 8. >>>>> >>>>> Yes this all came in as part of the OSX port in 7u2. >>>>> >>>>>> However, this function seems to be called from Thread#setNativeName() >>>>>> only. >>>>>> In addition, Thread#setNativeName() is private method. >>>>>> >>>>>> Thus I think that we can add an argument to JVM_SetNativeThreadName() >>>>>> for force setting. >>>>>> (e.g. "bool forced") >>>>>> >>>>>> It makes a change of JVM API. >>>>>> However, this function is NOT public, so I think we can add one more >>>>>> argument. >>>>>> >>>>>> What do you think about this? >>>>>> If it is accepted, we can set native thread name from Java launcher. >>>>> >>>>> The private/public aspect of the Java API is not really at issue. Yes >>>>> we would add another arg to the JVM function to allow it to apply to >>>>> JNI-attached threads as well (I'd prefer the arg reflect that not just >>>>> "force"). However this is still a change to the exported JVM interface >>>>> and so has to be approved. Further, we expect the launcher to use the >>>>> supported JNI interface (as other processes would), not the internal >>>>> JVM interface that exists for the JDK sources to communicate with the >>>>> JVM. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> The fact that the "main" thread is not tagged as being a >>>>>>>>> JNI-attached >>>>>>>>> thread seems accidental to me >>>>>>>> >>>>>>>> Should I file it to JBS? >>>>>>> >>>>>>> I think it is a bug based on the comment here: >>>>>>> >>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>>>> JNI attached threads >>>>>>> >>>>>>> Though that will introduce a change in behaviour by itself as setName >>>>>>> will no longer set the native name for the main thread. >>>>>>> >>>>>>>> I think that we can fix as below: >>>>>>>> --------------- >>>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 >>>>>>>> +0200 >>>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 >>>>>>>> +0900 >>>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>> #endif // INCLUDE_JVMCI >>>>>>>> >>>>>>>> // Attach the main thread to this os thread >>>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>> main_thread->initialize_thread_current(); >>>>>>>> // must do this before set_active_handles >>>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>> // Notify JVMTI agents that VM initialization is complete - >>>>>>>> nop if >>>>>>>> no agents. >>>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>> >>>>>>>> + // Change attach status to "attached" >>>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>> + >>>>>>> >>>>>>> I think we can do this straight after the JavaThread constructor. >>>>>>> >>>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>>>> backend."); >>>>>>>> } >>>>>>>> --------------- >>>>>>>> >>>>>>>> >>>>>>>>> If it wants to name its native threads then it is free to do so, >>>>>>>> >>>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread >>>>>>>> name >>>>>>>> when the caller thread is JNI-attached thread. >>>>>>>> However, I think that it should be changed if Java developer calls >>>>>>>> Thread#setName() explicitly. >>>>>>>> It is not the same of changing native thread name at >>>>>>>> Threads::create_vm(). >>>>>>>> >>>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>>>> What do you think about this? >>>>>>> >>>>>>> The decision to not change the name of JNI-attached threads was a >>>>>>> deliberate one** - this functionality originated with the OSX port >>>>>>> and >>>>>>> it was reported that the initial feedback with this feature was to >>>>>>> ensure it didn't mess with thread names that had been set by the host >>>>>>> process. If we do as you propose then we will just have an >>>>>>> inconsistency for people to complain about: "why does my native >>>>>>> thread >>>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>>>> >>>>>>> ** If you follow the bugs and related discussions on this, the >>>>>>> semantics and limitations (truncation, current thread only, non-JNI >>>>>>> threads only) of setting the native thread name were supposed to be >>>>>>> documented in the release notes - but as far as I can see that never >>>>>>> happened. :( >>>>>>> >>>>>>> My position on this remains that if it is desirable for the main >>>>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>>>> launcher needs to be setting them using the available platform APIs. >>>>>>> Unfortunately this is complicated - as evidenced by the VM code for >>>>>>> this - due to the need to verify API availability. >>>>>>> >>>>>>> Any change in behaviour in relation to Thread.setName would have >>>>>>> to go >>>>>>> through our CCC process I think. But a change in the launcher would >>>>>>> not. >>>>>>> >>>>>>> Sorry. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> --------------- >>>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 >>>>>>>> +0200 >>>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 >>>>>>>> +0900 >>>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>>>> // Thread naming only supported for the current thread, doesn't >>>>>>>> work >>>>>>>> for >>>>>>>> // target threads. >>>>>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>>>>>> + if (Thread::current() == thr) { >>>>>>>> // we don't set the name of an attached thread to avoid >>>>>>>> stepping >>>>>>>> // on other programs >>>>>>>> const char *thread_name = >>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>> >>>>>>>> --------------- >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Roger, >>>>>>>>>> Thanks for your comment! >>>>>>>>>> >>>>>>>>>> David, >>>>>>>>>> >>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>> exposing >>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>> >>>>>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>>>>> calling >>>>>>>>>> main method), >>>>>>>>>> I could set native thread name. >>>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't >>>>>>>>>> set >>>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>> >>>>>>>>> Right - I came to the same realization earlier this morning. Which, >>>>>>>>> unfortunately, takes me back to the basic premise here that we >>>>>>>>> don't >>>>>>>>> set the name of threads not created by the JVM. The fact that the >>>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>>>>> accident for the initial attach, and can't be used for the >>>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >>>>>>>>> named at >>>>>>>>> the native level. >>>>>>>>> >>>>>>>>> I'm afraid my view here is that the launcher has to be treated like >>>>>>>>> any other process that might host a JVM. If it wants to name its >>>>>>>>> native threads then it is free to do so, but I would not be >>>>>>>>> exporting >>>>>>>>> a function from the JVM to do that - it would have to use the OS >>>>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>>>> >>>>>>>>> Sorry. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Comments: >>>>>>>>>>> >>>>>>>>>>> jvm.h: The function names are too similar but perform different >>>>>>>>>>> functions: >>>>>>>>>>> >>>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>>>> >>>>>>>>>>> - The first function applies to the current thread, the second >>>>>>>>>>> one a >>>>>>>>>>> specific java thread. >>>>>>>>>>> It would seem useful for there to be a comment somewhere about >>>>>>>>>>> what >>>>>>>>>>> the new function does. >>>>>>>>>>> >>>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>>>> instead of >>>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>> as is done on unix and mac. >>>>>>>>>>> >>>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>>>>>>> line 730 >>>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>>>>>>> same >>>>>>>>>>> line as dlsym... >>>>>>>>>>> >>>>>>>>>>> $.02, Roger >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>> check - >>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>>> then >>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>>>> work >>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>> >>>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>> --------- >>>>>>>>>>>> public class Sleep{ >>>>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> --------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>> exposing >>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>> >>>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I exported new JVM function to set native thread name, >>>>>>>>>>>>>>>> and JLI >>>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>>>>>>> rather >>>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>>>>> needed in >>>>>>>>>>>>>>> that case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>>> >>>>>>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>>>>>> native >>>>>>>>>>>>> name is not set. >>>>>>>>>>>>> >>>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>>>> >>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>> check - >>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>>> then >>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>>>> work >>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>> >>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>> exposing >>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>>>>>>> thread name. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>>>>>>>>>>>>>>>>>>>>> JavaThread(); >>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>>>>>>>>>>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue >>>>>>>>>>>>>>>>>>>>>>> Mar 29 >>>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed >>>>>>>>>>>>>>>>>>>>>>> Mar 30 >>>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = >>>>>>>>>>>>>>>>>>>>>>> "main"; >>>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>> thread); >>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we >>>>>>>>>>>>>>>>>>>>>>> want >>>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have >>>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - >>>>>>>>>>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I >>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> From yasuenag at gmail.com Sun Apr 17 03:51:09 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 17 Apr 2016 12:51:09 +0900 Subject: RFR: JDK-8154331: main thread should be treated as JNI-attached thread. In-Reply-To: <5712BBBC.3040401@oracle.com> References: <5710EB68.2080308@gmail.com> <5711E8D9.20805@oracle.com> <57122A06.8020709@gmail.com> <5712BBBC.3040401@oracle.com> Message-ID: <5713082D.9050307@gmail.com> Hi David, > This issue does introduce an incompatible change in behaviour so it may be > best to defer this part until Java 10, as Dan suggested in the bug report. Okay, If I cannot get sponsor and reviewer, I will come back on this issue after jdk 10 repos is opened. Thanks, Yasumasa On 2016/04/17 7:25, David Holmes wrote: > On 16/04/2016 10:03 PM, Yasumasa Suenaga wrote: >> Hi David, >> >>> Correcting this behaviour could be seen as >>> a regression because there would no be no way to set the native name of >>> the main thread. >> >> If my proposal in JDK-8152690 [1] is merged, Java developer can change native >> thread name with reflection. > > Yes though access control may get in the way. > >> IMHO, we can merge changes for jvm.cpp and Thread.{c,java} to this issue >> from JDK-8152690. > > Not sure what you mean. I want to keep the two issues distinct. This > issue does introduce an incompatible change in behaviour so it may be > best to defer this part until Java 10, as Dan suggested in the bug report. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040276.html >> >> >> On 2016/04/16 16:25, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 15/04/2016 11:23 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> In discussion about JDK-8152690 [1], we were found a bug. >>>> Java main thread which is started by Java launcher is not treated as JNI-attached thread. >>>> >>>> I uploaded a webrev. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8154331/webrev.00/ >>>> >>>> I cannot access JPRT. >>>> So I need a sponsor. >>> >>> As I just wrote in the bug report: >>> >>> I think it was an oversight that when the OSX port brought this code in, >>> the main thread was not marked as being a JNI-attached thread - as >>> suggested by this comment: >>> >>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>> JNI attached threads >>> >>> However because of this oversight a call to Thread.setName from the main >>> thread would** cause the native thread name to be set (normally we don't >>> modify JNI-attached threads). Correcting this behaviour could be seen as >>> a regression because there would no be no way to set the native name of >>> the main thread. >>> >>> Given that we don't actually gain anything by "fixing" this I'm inclined >>> to simply leave it as-is. >>> >>> ** I haven't actually verified this as I don't have access to a system I >>> can check it on right now. But based on code inspection this appears to >>> be the case. >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040251.html >>>> From david.holmes at oracle.com Sun Apr 17 09:46:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 17 Apr 2016 19:46:22 +1000 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <570FC3B2.4040805@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> Message-ID: <57135B6E.2040402@oracle.com> Hi Max, Sorry for being late to the party here ... On 15/04/2016 2:22 AM, Max Ockner wrote: > new webrev: > http://cr.openjdk.java.net/~mockner/8151526.05/ > - new describe_* methods are now private > - VMError is now a friend class in logConfiguration. but I also think reporting the available log level and tags is not the kind of thing we need in the hs_err file. The hs_err file captures information specific to the execution of the VM that crashed - the dynamic state if you like. The available log levels and tags are static information in the source code and don't tell me anything about the crash. (We didn't report which TraceXXX flags existed). While I'm all for providing useful crash information the hs_err file is starting to suffer from bloat in my opinion. Thanks, David ----- > Thanks, > Max > > On 4/14/2016 4:30 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/13/2016 09:33 PM, Max Ockner wrote: >>> Hello, >>> I have made these changes. >>> - refactored describe into a portion which uses locking and one that >>> does not. >>> - in the print_vm_info function in vmError.cpp, describe() is used, >>> since this function is called while the program is running. >>> - in the report function, the describe_no_lock and describe_with_lock >>> functions are both used without taking a lock. If it doesnt crash, >>> then fantastic. If it does crash, the error handler will skip this >>> step anyway. >>> >>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >> >> I suggest making the new two functions private in LogConfiguration, >> and friending VMError, instead of keeping them public. That should >> reduce confusion about which describe-method to use, and prevent >> misuse of the describe_with_lock in other places. >> >> Otherwise this looks good. >> >> Thanks, >> Marcus >> >>> >>> Thanks, >>> Max >>> >>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>> Hey, >>>> >>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>> Marcus, >>>>> >>>>> I just spoke with Coleen about this. If I attempt to print >>>>> configuration during a crash without lock and it crashes, the error >>>>> handler will eat it up and start at the next step. It would be fun >>>>> to write a locking mechanism, but this seems better to me. >>>>> >>>>> I will continue to call describe() from VM.info, but I will >>>>> refactor the code in describe so that all of the information can be >>>>> printed easily without taking a lock. For a crash, I'll use the >>>>> refactored print functions to print all the necessary information >>>>> without taking a lock. Even if the vm crashes during this step it >>>>> is not such a bad thing because of the robust error handler. >>>> >>>> Alright, that sounds good! >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>> Hi Max, >>>>>> >>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>> Hello again, >>>>>>> >>>>>>> I have looked into this and I see a possible workaround to the >>>>>>> issue raised by Marcus: >>>>>>> >>>>>>> LogConfiguration::describe() takes the ConfigurationLock, which >>>>>>> might be problematic for the error handler. I suppose the error >>>>>>> handler could potentially deadlock if its thread already holds >>>>>>> the lock. Unsure how to resolve this, because skipping to take >>>>>>> the lock means that we might crash due to another thread >>>>>>> changing the configuration as we read it. >>>>>>> >>>>>>> >>>>>>> My proposed solution is this: >>>>>>> >>>>>>> If the ConfigurationLock is held by another thread during the >>>>>>> crash, then I think we could print "Log configuration can not be >>>>>>> accessed because ConfigurationLock is currently held by another >>>>>>> thread" or something similar. If the ConfigurationLock can be >>>>>>> taken by the current thread, then print the configuration. >>>>>>> >>>>>>> We can accomplish this as follows: >>>>>>> >>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class >>>>>>> extending ConfigurationLock. >>>>>>> >>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>> private: >>>>>>> bool _success; >>>>>>> public: >>>>>>> ConfigurationLockMaybe() { >>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>> } >>>>>>> ~ConfigurationLock() { >>>>>>> if(_success){_semaphore.signal();} >>>>>>> } >>>>>>> bool has_lock(){return _success;} >>>>>>> }; >>>>>>> >>>>>>> _semaphore is a static var in ConfigurationLock, so the same copy >>>>>>> is accessed in child classes. >>>>>>> >>>>>>> Another method LogConfiguration::describe_on_crash(outputStream* >>>>>>> out) can use ConfigurationLockMaybe to attempt to print the >>>>>>> configuration. >>>>>>> >>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>> LogConfiguration::describe_on_crash. >>>>>> >>>>>> Sounds good to me. >>>>>> >>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>> better suggestion. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> Max >>>>>>> >>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>> I missed this before. I'm going to investigate. >>>>>>>> Max >>>>>>>> >>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> I forgot to respond to this: >>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>> (Replies in line) >>>>>>>>>>>> >>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>> >>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>> >>>>>>>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>>>>>>> >>>>>>>>>>>> Just going by what we currently put in the hs_err file, >>>>>>>>>>>> I think >>>>>>>>>>>> this may be the first "Do we really need" we've ever >>>>>>>>>>>> asked for >>>>>>>>>>>> this type of change. >>>>>>>>>>>> >>>>>>>>>>>> All joking aside, I think it is a good idea to direct users >>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>> >>>>>>>>>>>>> Also: I assume what you print is the Log state as it is >>>>>>>>>>>>> at the >>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. with jcmd, >>>>>>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>> >>>>>>>>>>>> Would it be possible? Yes, but I think this would require a >>>>>>>>>>>> framework change. It does not look like any marks are >>>>>>>>>>>> made when >>>>>>>>>>>> the LogConfiguration changes during runtime, and we >>>>>>>>>>>> would need >>>>>>>>>>>> to record that in order to know what to print when we >>>>>>>>>>>> dump into >>>>>>>>>>>> hs_err. >>>>>>>>>>> >>>>>>>>>>> Yes, this would required the framework to keep some sort >>>>>>>>>>> of log >>>>>>>>>>> of configuration changes. Is there value in knowing that >>>>>>>>>>> the log >>>>>>>>>>> configuration changed since startup? >>>>>>>>>> >>>>>>>>>> I think it is useful along with other information. An >>>>>>>>>> example case: >>>>>>>>>> >>>>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>>>> acquired or >>>>>>>>>> released. In a subsystem like this, the action which dooms >>>>>>>>>> the vm >>>>>>>>>> may not cause an immediate crash. This leaves time for >>>>>>>>>> logging to >>>>>>>>>> turn on or off in between the bad action and the crash. If >>>>>>>>>> you >>>>>>>>>> don't know when logging was active and when it was not, >>>>>>>>>> then the >>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>> information. You may not see the message that has the >>>>>>>>>> answer for >>>>>>>>>> you because it was not logged, though the action may have >>>>>>>>>> occurred. >>>>>>>>>> >>>>>>>>>> However, if we don't have the framework support for this >>>>>>>>>> then I >>>>>>>>>> believe it should be added later. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is a good example. A small easy solution, as I mentioned >>>>>>>>>> before, could be just to distinguish between "logging >>>>>>>>>> parameters stable since startup" and "logging parameters >>>>>>>>>> changed at some time". That way you would at least know >>>>>>>>>> whether to trust the logging output. >>>>>>>>>> >>>>>>>>>> But you are right, this can be added later. >>>>>>>>> >>>>>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for >>>>>>>>> this. >>>>>>>>> >>>>>>>>> Max: Did you see my comments about the ConfigurationLock? It >>>>>>>>> was an inline reply to your first mail. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Kind Regards, Thomas >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max >>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>> > >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> Please review another Unified Logging change. They are >>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>> >>>>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>> webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>>>>> which >>>>>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>>>>> error >>>>>>>>>>> handler could potentially deadlock if its thread already >>>>>>>>>>> holds >>>>>>>>>>> the lock. Unsure how to resolve this, because skipping to >>>>>>>>>>> take >>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Marcus >>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The logging configuration is now printed in each >>>>>>>>>>>>> hs_err >>>>>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>> >>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>> Logging info >>>>>>>>>>>>> is printed after VM Arguments and Whitebox, and before >>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>> >>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>> >>>>>>>>>>>>> Logging: >>>>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>>>> warning, error >>>>>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>>>>> timemillis >>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags (tg) >>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>> exceptions, >>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, itables, >>>>>>>>>>>>> jni, >>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>>>> preorder, >>>>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>>>> safepoint, >>>>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, start, >>>>>>>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>> >>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>> >>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>> >>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Sun Apr 17 10:38:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 17 Apr 2016 20:38:46 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57130544.8000601@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5712BAB9.5040400@oracle.com> <57130544.8000601@gmail.com> Message-ID: <571367B6.5020808@oracle.com> On 17/04/2016 1:38 PM, Yasumasa Suenaga wrote: > Hi David, > >> Need to hear from core-libs and/or launcher folk as this touches a >> number of pieces of code. > > I'm waiting more reviewer(s) . > > BTW, Should I make patches which are based on jdk9/dev repos? > My proposal includes hotspot changes. > So I want to know whether I can push all changes jdk9/dev/{jdk,hotspot} > after reviewing. No, jdk9/hs please. Thanks, David > I can update my webrev to adapt to jdk9/dev repos if need. > > > Thanks, > > Yasumasa > > > On 2016/04/17 7:20, David Holmes wrote: >> Hi Yasumasa, >> >> On 16/04/2016 7:29 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> I uploaded new webrev: >>> >>> - hotspot: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>> >>> - jdk: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >> >> Ah sneaky! :) Using JNI to by-pass access control so we can set up a >> private method to do the name setting, yet avoid any API change that >> would require a CCC request. I think I like it. :) >> >> Need to hear from core-libs and/or launcher folk as this touches a >> number of pieces of code. >> >> Thanks, >> David >> ----- >> >>> >>>> it won't work unless you change the semantics of setName so I'm not >>>> sure what you were thinking here. To take advantage of an arg taking >>>> JVM_SetNativThreadName you would need to call it directly as no Java >>>> code will call it . ??? >>> >>> I added a flag for setting native thread name to JNI-attached thread. >>> This change can set native thread name if main thread changes to >>> JNI-attached thread. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/16 16:11, David Holmes wrote: >>>> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> That change in behaviour may be a problem, it could be considered a >>>>>> regression that setName stops setting the native thread main, even >>>>>> though we never really intended it to work in the first place. :( >>>>>> Such >>>>>> a change needs to go through CCC. >>>>> >>>>> I understood. >>>>> Can I send CCC request? >>>>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>> >>>> Sorry you can't file a CCC request, you would need a sponsor for that. >>>> But at this stage I don't think I agree with the proposed change >>>> because of the change in behaviour - there's no way to restore the >>>> "broken" behaviour. >>>> >>>>> I want to continue to discuss about it on JDK-8154331 [1]. >>>> >>>> Okay we can do that. >>>> >>>>> >>>>>> Further, we expect the launcher to use the supported JNI interface >>>>>> (as >>>>>> other processes would), not the internal JVM interface that exists >>>>>> for >>>>>> the JDK sources to communicate with the JVM. >>>>> >>>>> I think that we do not use JVM interface if we add new method in >>>>> LauncherHelper as below: >>>>> ---------------- >>>>> diff -r f02139a1ac84 >>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>> Wed Apr 13 14:19:30 2016 +0000 >>>>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>> Sat Apr 16 11:25:53 2016 +0900 >>>>> @@ -960,4 +960,8 @@ >>>>> else >>>>> return md.toNameAndVersion() + " (" + loc + ")"; >>>>> } >>>>> + >>>>> + static void setNativeThreadName(String name) { >>>>> + Thread.currentThread().setName(name); >>>>> + } >>>> >>>> You could also make that call via JNI directly, so not sure the helper >>>> adds much here. But it won't work unless you change the semantics of >>>> setName so I'm not sure what you were thinking here. To take advantage >>>> of an arg taking JVM_SetNativThreadName you would need to call it >>>> directly as no Java code will call it . ??? >>>> >>>> David >>>> ----- >>>> >>>>> } >>>>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>>>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >>>>> 2016 +0000 >>>>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >>>>> 2016 +0900 >>>>> @@ -125,6 +125,7 @@ >>>>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>> static void ShowSettings(JNIEnv* env, char *optString); >>>>> static void ListModules(JNIEnv* env, char *optString); >>>>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>>> >>>>> static void SetPaths(int argc, char **argv); >>>>> >>>>> @@ -325,6 +326,7 @@ >>>>> * mainThread.isAlive() to work as expected. >>>>> */ >>>>> #define LEAVE() \ >>>>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>> do { \ >>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>> @@ -488,6 +490,9 @@ >>>>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>> >>>>> + /* Set native thread name. */ >>>>> + SetNativeThreadName(env, "main"); >>>>> + >>>>> /* Invoke main method. */ >>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>>> >>>>> @@ -1686,6 +1691,22 @@ >>>>> joptString); >>>>> } >>>>> >>>>> +/** >>>>> + * Set native thread name as possible. >>>>> + */ >>>>> +static void >>>>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>> +{ >>>>> + jmethodID setNativeThreadNameID; >>>>> + jstring nameString; >>>>> + jclass cls = GetLauncherHelperClass(env); >>>>> + NULL_CHECK(cls); >>>>> + NULL_CHECK(setNativeThreadNameID = >>>>> (*env)->GetStaticMethodID(env, cls, >>>>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>>>> nameString); >>>>> +} >>>>> + >>>>> /* >>>>> * Prints default usage or the Xusage message, see >>>>> sun.launcher.LauncherHelper.java >>>>> */ >>>>> ---------------- >>>>> >>>>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>> >>>>>> However this is still a change to the exported JVM interface and so >>>>>> has to be approved. >>>>> >>>>> Do you mean that this change needs CCC? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2016/04/16 7:26, David Holmes wrote: >>>>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> I think it is a bug based on the comment here: >>>>>>>> >>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>>>>> thread and >>>>>>>> JNI attached threads >>>>>>> >>>>>>> I filed it to JBS as JDK-8154331. >>>>>>> I will send review request to hotspot-runtime-dev. >>>>>>> >>>>>>> >>>>>>>> Though that will introduce a change in behaviour by itself as >>>>>>>> setName >>>>>>>> will no longer set the native name for the main thread. >>>>>>> >>>>>>> I know. >>>>>> >>>>>> That change in behaviour may be a problem, it could be considered a >>>>>> regression that setName stops setting the native thread main, even >>>>>> though we never really intended it to work in the first place. :( >>>>>> Such >>>>>> a change needs to go through CCC. >>>>>> >>>>>>> I checked changeset history. >>>>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>>>>>> backported JDK 8. >>>>>> >>>>>> Yes this all came in as part of the OSX port in 7u2. >>>>>> >>>>>>> However, this function seems to be called from >>>>>>> Thread#setNativeName() >>>>>>> only. >>>>>>> In addition, Thread#setNativeName() is private method. >>>>>>> >>>>>>> Thus I think that we can add an argument to >>>>>>> JVM_SetNativeThreadName() >>>>>>> for force setting. >>>>>>> (e.g. "bool forced") >>>>>>> >>>>>>> It makes a change of JVM API. >>>>>>> However, this function is NOT public, so I think we can add one more >>>>>>> argument. >>>>>>> >>>>>>> What do you think about this? >>>>>>> If it is accepted, we can set native thread name from Java launcher. >>>>>> >>>>>> The private/public aspect of the Java API is not really at issue. Yes >>>>>> we would add another arg to the JVM function to allow it to apply to >>>>>> JNI-attached threads as well (I'd prefer the arg reflect that not >>>>>> just >>>>>> "force"). However this is still a change to the exported JVM >>>>>> interface >>>>>> and so has to be approved. Further, we expect the launcher to use the >>>>>> supported JNI interface (as other processes would), not the internal >>>>>> JVM interface that exists for the JDK sources to communicate with the >>>>>> JVM. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> The fact that the "main" thread is not tagged as being a >>>>>>>>>> JNI-attached >>>>>>>>>> thread seems accidental to me >>>>>>>>> >>>>>>>>> Should I file it to JBS? >>>>>>>> >>>>>>>> I think it is a bug based on the comment here: >>>>>>>> >>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>>>>> thread and >>>>>>>> JNI attached threads >>>>>>>> >>>>>>>> Though that will introduce a change in behaviour by itself as >>>>>>>> setName >>>>>>>> will no longer set the native name for the main thread. >>>>>>>> >>>>>>>>> I think that we can fix as below: >>>>>>>>> --------------- >>>>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 >>>>>>>>> +0200 >>>>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 >>>>>>>>> +0900 >>>>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>> >>>>>>>>> // Attach the main thread to this os thread >>>>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>> // must do this before set_active_handles >>>>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>> // Notify JVMTI agents that VM initialization is complete - >>>>>>>>> nop if >>>>>>>>> no agents. >>>>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>> >>>>>>>>> + // Change attach status to "attached" >>>>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>> + >>>>>>>> >>>>>>>> I think we can do this straight after the JavaThread constructor. >>>>>>>> >>>>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>>>>> backend."); >>>>>>>>> } >>>>>>>>> --------------- >>>>>>>>> >>>>>>>>> >>>>>>>>>> If it wants to name its native threads then it is free to do so, >>>>>>>>> >>>>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread >>>>>>>>> name >>>>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>> However, I think that it should be changed if Java developer calls >>>>>>>>> Thread#setName() explicitly. >>>>>>>>> It is not the same of changing native thread name at >>>>>>>>> Threads::create_vm(). >>>>>>>>> >>>>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>>>>> What do you think about this? >>>>>>>> >>>>>>>> The decision to not change the name of JNI-attached threads was a >>>>>>>> deliberate one** - this functionality originated with the OSX port >>>>>>>> and >>>>>>>> it was reported that the initial feedback with this feature was to >>>>>>>> ensure it didn't mess with thread names that had been set by the >>>>>>>> host >>>>>>>> process. If we do as you propose then we will just have an >>>>>>>> inconsistency for people to complain about: "why does my native >>>>>>>> thread >>>>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>>>>> >>>>>>>> ** If you follow the bugs and related discussions on this, the >>>>>>>> semantics and limitations (truncation, current thread only, non-JNI >>>>>>>> threads only) of setting the native thread name were supposed to be >>>>>>>> documented in the release notes - but as far as I can see that >>>>>>>> never >>>>>>>> happened. :( >>>>>>>> >>>>>>>> My position on this remains that if it is desirable for the main >>>>>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>>>>> launcher needs to be setting them using the available platform >>>>>>>> APIs. >>>>>>>> Unfortunately this is complicated - as evidenced by the VM code for >>>>>>>> this - due to the need to verify API availability. >>>>>>>> >>>>>>>> Any change in behaviour in relation to Thread.setName would have >>>>>>>> to go >>>>>>>> through our CCC process I think. But a change in the launcher would >>>>>>>> not. >>>>>>>> >>>>>>>> Sorry. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> --------------- >>>>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 >>>>>>>>> +0200 >>>>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 >>>>>>>>> +0900 >>>>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>>>>> // Thread naming only supported for the current thread, >>>>>>>>> doesn't >>>>>>>>> work >>>>>>>>> for >>>>>>>>> // target threads. >>>>>>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>>>>>>> + if (Thread::current() == thr) { >>>>>>>>> // we don't set the name of an attached thread to avoid >>>>>>>>> stepping >>>>>>>>> // on other programs >>>>>>>>> const char *thread_name = >>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> Roger, >>>>>>>>>>> Thanks for your comment! >>>>>>>>>>> >>>>>>>>>>> David, >>>>>>>>>>> >>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>> exposing >>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>> >>>>>>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>>>>>> calling >>>>>>>>>>> main method), >>>>>>>>>>> I could set native thread name. >>>>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we >>>>>>>>>>> can't >>>>>>>>>>> set >>>>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>> >>>>>>>>>> Right - I came to the same realization earlier this morning. >>>>>>>>>> Which, >>>>>>>>>> unfortunately, takes me back to the basic premise here that we >>>>>>>>>> don't >>>>>>>>>> set the name of threads not created by the JVM. The fact that the >>>>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>>>>>> accident for the initial attach, and can't be used for the >>>>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >>>>>>>>>> named at >>>>>>>>>> the native level. >>>>>>>>>> >>>>>>>>>> I'm afraid my view here is that the launcher has to be treated >>>>>>>>>> like >>>>>>>>>> any other process that might host a JVM. If it wants to name its >>>>>>>>>> native threads then it is free to do so, but I would not be >>>>>>>>>> exporting >>>>>>>>>> a function from the JVM to do that - it would have to use the OS >>>>>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>>>>> >>>>>>>>>> Sorry. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Comments: >>>>>>>>>>>> >>>>>>>>>>>> jvm.h: The function names are too similar but perform >>>>>>>>>>>> different >>>>>>>>>>>> functions: >>>>>>>>>>>> >>>>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>>>>> >>>>>>>>>>>> - The first function applies to the current thread, the second >>>>>>>>>>>> one a >>>>>>>>>>>> specific java thread. >>>>>>>>>>>> It would seem useful for there to be a comment somewhere >>>>>>>>>>>> about >>>>>>>>>>>> what >>>>>>>>>>>> the new function does. >>>>>>>>>>>> >>>>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>>>>> instead of >>>>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>> >>>>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>> used at >>>>>>>>>>>> line 730 >>>>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast >>>>>>>>>>>> on the >>>>>>>>>>>> same >>>>>>>>>>>> line as dlsym... >>>>>>>>>>>> >>>>>>>>>>>> $.02, Roger >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>>> check - >>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>>>> then >>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>>>>>>>>>>> should >>>>>>>>>>>>>> work >>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>> >>>>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed >>>>>>>>>>>>> native >>>>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>>> --------- >>>>>>>>>>>>> public class Sleep{ >>>>>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>>> } >>>>>>>>>>>>> } >>>>>>>>>>>>> --------- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>> exposing >>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>> >>>>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I exported new JVM function to set native thread name, >>>>>>>>>>>>>>>>> and JLI >>>>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> First the launcher belongs to another team so core-libs >>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>>>>>>>>>>>>> Thread.setName >>>>>>>>>>>>>>>> rather >>>>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>>>>>> needed in >>>>>>>>>>>>>>>> that case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>>>> >>>>>>>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>>>>>>> native >>>>>>>>>>>>>> name is not set. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>>> check - >>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>>>> then >>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>>>>>>>>>>> should >>>>>>>>>>>>>> work >>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>> exposing >>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thus I think that we have to provide a function to set >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> thread name. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we >>>>>>>>>>>>>>>>>> do not >>>>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>>>>>>>>>>>>>>>>>>>>>> JavaThread(); >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>>>>>>>>>>>>>>>> set_active_handles >>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread >>>>>>>>>>>>>>>>>>>>>>>> name in >>>>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already >>>>>>>>>>>>>>>>>>>>>>>> starte >>>>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue >>>>>>>>>>>>>>>>>>>>>>>> Mar 29 >>>>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed >>>>>>>>>>>>>>>>>>>>>>>> Mar 30 >>>>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = >>>>>>>>>>>>>>>>>>>>>>>> "main"; >>>>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>>> thread); >>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and >>>>>>>>>>>>>>>>>>>>>>>> thus >>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. >>>>>>>>>>>>>>>>>>>>>>>> So I >>>>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we >>>>>>>>>>>>>>>>>>>>>>>> want >>>>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have >>>>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - >>>>>>>>>>>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I >>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name >>>>>>>>>>>>>>>>>>>>>>>> via >>>>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> From ioi.lam at oracle.com Sun Apr 17 14:32:32 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 17 Apr 2016 07:32:32 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <570EA62C.4080605@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> <570EA62C.4080605@oracle.com> Message-ID: <57139E80.7090105@oracle.com> Hi Calvin, Thanks for the review. Please see my comments inside. On 4/13/16 1:03 PM, Calvin Cheung wrote: > Hi Ioi, > > Just a few minor comments. No need to see another webrev. > compactHashtable.cpp: > > 71 _num_entries ++; > > extra space before ++ > similarly in lines 80, 112, 123, 125 > I grepped the hotspot source code with '[a-z] [+][+]' and found that there are quite a few cases of putting a space between the variable name and "++". Other lines in compactHashtable.cpp that are not changed by this patch also use "++". The HotSpot coding guide (https://wiki.openjdk.java.net/display/HotSpot/StyleGuide) doesn't mention the "++" operator specifically, so I'll leave the space there for now. > 118 Entry tent = bucket->at(i); > > It is clearer if 'tent' is just 'ent' since the code in this block is > not dealing with tiny entry. > Changed tent -> ent > 249 while (entry > Needs a space before entry_max. > Fixed. > > SASymbolTableTest.java: > > The result of p.getPid() can be saved into a local variable so that it > won't need to be done twice in lines 86 and 93. > Fixed. Thanks - Ioi > thanks, > Calvin > > On 4/12/16, 12:40 PM, Jiangli Zhou wrote: >> Ioi, >> >>> On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: >>> >>> Hi Jiangli, >>> >>> >>> Thanks for the review: >>> >>> On 4/11/16 6:44 PM, Jiangli Zhou wrote: >>>> Hi Ioi, >>>> >>>> I like the more structural way of reading/writing the compact table >>>> with SimpleCompactHashtable. It looks quite clean overall. >>>> >>>> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive >>>> than TINY_BUCKET_TYPE? >>>> >>> OK, I will make the change. >>> >>>> - The following assert in CompactSymbolTableWriter::add() limits >>>> the total shared space size to be less than MAX_SHARED_DELTA >>>> unnecessarily. Symbols are allocated from the RO space at dump >>>> time. We only need to make sure the max delta between the >>>> ?base_address? and the end of RO space is less than >>>> MAX_SHARED_DELTA. This is not a new issue introduced by your >>>> change, you don?t have to address that as part of this change if >>>> you prefer. I?ll file a separate RFE. >>>> >>> I think it's better to do this in a separate RFE since >>> MAX_SHARED_DELTA is used elsewhere as well. >> I filed JDK-8154108. >> >>>> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol >>>> *symbol) { >>>> 172 address base_address = >>>> address(MetaspaceShared::shared_rs()->base()); >>>> 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); >>>> 174 assert(max_delta<= MAX_SHARED_DELTA, "range check"); >>>> >>>> - Why is the default RO space size increased? >>>> >>> That's because the symbol table is moved from RW to RO, so I had to >>> change the RO minimum size, or else >>> test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. >> Ok. >> >> Thanks, >> Jiangli >> >>>> - >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >>>> - >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >>>> Copyright year. >>> Will fix. >>> >>> Thanks >>> - Ioi >>>> Thanks, >>>> Jiangli >>>> >>>>> On Mar 31, 2016, at 10:43 PM, Ioi >>>>> Lam> wrote: >>>>> >>>>> Please review >>>>> >>>>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>>>> >>>>> >>>>> Bug: Clean up CompactHashtable >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>>>> >>>>> Summary of fix: >>>>> >>>>> [1] Instead of reading/writing the table bit-by-bit, which is >>>>> tedious and >>>>> error prone, use SimpleCompactHashtable::serialize(), which is >>>>> more >>>>> structural. >>>>> >>>>> [2] Split up the _buckets and _entries into two separate arrays, >>>>> so the >>>>> dumping and walking code is easier to understand >>>>> >>>>> (see comments above SimpleCompactHashtable declaration) >>>>> These 2 arrays are now allocated from the RO region (used to >>>>> be in RW) >>>>> >>>>> [3] Renamed a few things >>>>> >>>>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>>>> (having something called "compact" in CompactHashtable is >>>>> confusing) >>>>> >>>>> The old names "dump_table" (actually dumping the buckets) and >>>>> "dump_buckets" (actually dumping the entries) were conflicting >>>>> with >>>>> terminology used elsewhere. Now the terminology is unified: >>>>> "buckets" = the main index, "entries" = the second level. >>>>> >>>>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>>>> >>>>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>>>> checked with assert. >>>>> >>>>> [5] Replaced all juint to u4 (suggested by Coleen) >>>>> >>>>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>>>> SimpleCompactHashtable::iterate) >>>>> >>>>> [7] I also added a test case using Serviceability Agent -- due to >>>>> the lack of >>>>> a regression test, the walking of the compact hashtable in SA >>>>> had been >>>>> broken for a while before it was fixed in JDK-8151368, so >>>>> having a test >>>>> case would make the code more maintainable. >>>>> >>>>> Tests: >>>>> >>>>> Hotspot JTREG tests >>>>> >>>>> Thanks >>>>> - Ioi From david.holmes at oracle.com Sun Apr 17 23:08:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Apr 2016 09:08:27 +1000 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <57139E80.7090105@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> <570EA62C.4080605@oracle.com> <57139E80.7090105@oracle.com> Message-ID: <5714176B.1090406@oracle.com> On 18/04/2016 12:32 AM, Ioi Lam wrote: > Hi Calvin, > > Thanks for the review. Please see my comments inside. > > On 4/13/16 1:03 PM, Calvin Cheung wrote: >> Hi Ioi, >> >> Just a few minor comments. No need to see another webrev. >> compactHashtable.cpp: >> >> 71 _num_entries ++; >> >> extra space before ++ >> similarly in lines 80, 112, 123, 125 >> > I grepped the hotspot source code with '[a-z] [+][+]' and found that > there are quite a few cases of putting a space between the variable name > and "++". Other lines in compactHashtable.cpp that are not changed by > this patch also use "++". The HotSpot coding guide > (https://wiki.openjdk.java.net/display/HotSpot/StyleGuide) doesn't > mention the "++" operator specifically, so I'll leave the space there > for now. Then we need to update the style guide - unary operators (like the booleans the guide does mention) should not have a space between the operator and operand. Cheers, David ----- > >> 118 Entry tent = bucket->at(i); >> >> It is clearer if 'tent' is just 'ent' since the code in this block is >> not dealing with tiny entry. >> > Changed tent -> ent > >> 249 while (entry > >> Needs a space before entry_max. >> > Fixed. >> >> SASymbolTableTest.java: >> >> The result of p.getPid() can be saved into a local variable so that it >> won't need to be done twice in lines 86 and 93. >> > Fixed. > > Thanks > - Ioi >> thanks, >> Calvin >> >> On 4/12/16, 12:40 PM, Jiangli Zhou wrote: >>> Ioi, >>> >>>> On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: >>>> >>>> Hi Jiangli, >>>> >>>> >>>> Thanks for the review: >>>> >>>> On 4/11/16 6:44 PM, Jiangli Zhou wrote: >>>>> Hi Ioi, >>>>> >>>>> I like the more structural way of reading/writing the compact table >>>>> with SimpleCompactHashtable. It looks quite clean overall. >>>>> >>>>> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive >>>>> than TINY_BUCKET_TYPE? >>>>> >>>> OK, I will make the change. >>>> >>>>> - The following assert in CompactSymbolTableWriter::add() limits >>>>> the total shared space size to be less than MAX_SHARED_DELTA >>>>> unnecessarily. Symbols are allocated from the RO space at dump >>>>> time. We only need to make sure the max delta between the >>>>> ?base_address? and the end of RO space is less than >>>>> MAX_SHARED_DELTA. This is not a new issue introduced by your >>>>> change, you don?t have to address that as part of this change if >>>>> you prefer. I?ll file a separate RFE. >>>>> >>>> I think it's better to do this in a separate RFE since >>>> MAX_SHARED_DELTA is used elsewhere as well. >>> I filed JDK-8154108. >>> >>>>> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol >>>>> *symbol) { >>>>> 172 address base_address = >>>>> address(MetaspaceShared::shared_rs()->base()); >>>>> 173 uintx max_delta = uintx(MetaspaceShared::shared_rs()->size()); >>>>> 174 assert(max_delta<= MAX_SHARED_DELTA, "range check"); >>>>> >>>>> - Why is the default RO space size increased? >>>>> >>>> That's because the symbol table is moved from RW to RO, so I had to >>>> change the RO minimum size, or else >>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. >>> Ok. >>> >>> Thanks, >>> Jiangli >>> >>>>> - >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >>>>> >>>>> - >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >>>>> >>>>> Copyright year. >>>> Will fix. >>>> >>>> Thanks >>>> - Ioi >>>>> Thanks, >>>>> Jiangli >>>>> >>>>>> On Mar 31, 2016, at 10:43 PM, Ioi >>>>>> Lam> wrote: >>>>>> >>>>>> Please review >>>>>> >>>>>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>>>>> >>>>>> >>>>>> Bug: Clean up CompactHashtable >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>>>>> >>>>>> >>>>>> Summary of fix: >>>>>> >>>>>> [1] Instead of reading/writing the table bit-by-bit, which is >>>>>> tedious and >>>>>> error prone, use SimpleCompactHashtable::serialize(), which is >>>>>> more >>>>>> structural. >>>>>> >>>>>> [2] Split up the _buckets and _entries into two separate arrays, >>>>>> so the >>>>>> dumping and walking code is easier to understand >>>>>> >>>>>> (see comments above SimpleCompactHashtable declaration) >>>>>> These 2 arrays are now allocated from the RO region (used to >>>>>> be in RW) >>>>>> >>>>>> [3] Renamed a few things >>>>>> >>>>>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>>>>> (having something called "compact" in CompactHashtable is >>>>>> confusing) >>>>>> >>>>>> The old names "dump_table" (actually dumping the buckets) and >>>>>> "dump_buckets" (actually dumping the entries) were conflicting >>>>>> with >>>>>> terminology used elsewhere. Now the terminology is unified: >>>>>> "buckets" = the main index, "entries" = the second level. >>>>>> >>>>>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>>>>> >>>>>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>>>>> checked with assert. >>>>>> >>>>>> [5] Replaced all juint to u4 (suggested by Coleen) >>>>>> >>>>>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>>>>> SimpleCompactHashtable::iterate) >>>>>> >>>>>> [7] I also added a test case using Serviceability Agent -- due to >>>>>> the lack of >>>>>> a regression test, the walking of the compact hashtable in SA >>>>>> had been >>>>>> broken for a while before it was fixed in JDK-8151368, so >>>>>> having a test >>>>>> case would make the code more maintainable. >>>>>> >>>>>> Tests: >>>>>> >>>>>> Hotspot JTREG tests >>>>>> >>>>>> Thanks >>>>>> - Ioi > From ioi.lam at oracle.com Mon Apr 18 02:25:15 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 17 Apr 2016 19:25:15 -0700 Subject: RFR 8150607 - Clean up CompactHashtable In-Reply-To: <5714176B.1090406@oracle.com> References: <56FE0A77.6010604@oracle.com> <570C5968.3000401@oracle.com> <332126AD-ADAD-4BEC-A443-04F96F1C4D9F@oracle.com> <570EA62C.4080605@oracle.com> <57139E80.7090105@oracle.com> <5714176B.1090406@oracle.com> Message-ID: <5714458B.1050206@oracle.com> On 4/17/16 4:08 PM, David Holmes wrote: > On 18/04/2016 12:32 AM, Ioi Lam wrote: >> Hi Calvin, >> >> Thanks for the review. Please see my comments inside. >> >> On 4/13/16 1:03 PM, Calvin Cheung wrote: >>> Hi Ioi, >>> >>> Just a few minor comments. No need to see another webrev. >>> compactHashtable.cpp: >>> >>> 71 _num_entries ++; >>> >>> extra space before ++ >>> similarly in lines 80, 112, 123, 125 >>> >> I grepped the hotspot source code with '[a-z] [+][+]' and found that >> there are quite a few cases of putting a space between the variable name >> and "++". Other lines in compactHashtable.cpp that are not changed by >> this patch also use "++". The HotSpot coding guide >> (https://wiki.openjdk.java.net/display/HotSpot/StyleGuide) doesn't >> mention the "++" operator specifically, so I'll leave the space there >> for now. > > Then we need to update the style guide - unary operators (like the > booleans the guide does mention) should not have a space between the > operator and operand. > OK, I have updated the webrev to fix the "++" issues on compactHashtable.cpp/hpp. I'll leave the other files as-is. This webrev also contains the feedbacks from Calvin and Jiangli in the previous mails. These are stylistic changes, variable renaming, etc with no change in functionality. http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v03/ Thanks - Ioi > Cheers, > David > ----- > > >> >>> 118 Entry tent = bucket->at(i); >>> >>> It is clearer if 'tent' is just 'ent' since the code in this block is >>> not dealing with tiny entry. >>> >> Changed tent -> ent >> >>> 249 while (entry >> >>> Needs a space before entry_max. >>> >> Fixed. >>> >>> SASymbolTableTest.java: >>> >>> The result of p.getPid() can be saved into a local variable so that it >>> won't need to be done twice in lines 86 and 93. >>> >> Fixed. >> >> Thanks >> - Ioi >>> thanks, >>> Calvin >>> >>> On 4/12/16, 12:40 PM, Jiangli Zhou wrote: >>>> Ioi, >>>> >>>>> On Apr 11, 2016, at 7:11 PM, Ioi Lam wrote: >>>>> >>>>> Hi Jiangli, >>>>> >>>>> >>>>> Thanks for the review: >>>>> >>>>> On 4/11/16 6:44 PM, Jiangli Zhou wrote: >>>>>> Hi Ioi, >>>>>> >>>>>> I like the more structural way of reading/writing the compact table >>>>>> with SimpleCompactHashtable. It looks quite clean overall. >>>>>> >>>>>> - How about using VALUE_ONLY_BUCKET_TYPE, which is more descriptive >>>>>> than TINY_BUCKET_TYPE? >>>>>> >>>>> OK, I will make the change. >>>>> >>>>>> - The following assert in CompactSymbolTableWriter::add() limits >>>>>> the total shared space size to be less than MAX_SHARED_DELTA >>>>>> unnecessarily. Symbols are allocated from the RO space at dump >>>>>> time. We only need to make sure the max delta between the >>>>>> ?base_address? and the end of RO space is less than >>>>>> MAX_SHARED_DELTA. This is not a new issue introduced by your >>>>>> change, you don?t have to address that as part of this change if >>>>>> you prefer. I?ll file a separate RFE. >>>>>> >>>>> I think it's better to do this in a separate RFE since >>>>> MAX_SHARED_DELTA is used elsewhere as well. >>>> I filed JDK-8154108. >>>> >>>>>> 171 void CompactSymbolTableWriter::add(unsigned int hash, Symbol >>>>>> *symbol) { >>>>>> 172 address base_address = >>>>>> address(MetaspaceShared::shared_rs()->base()); >>>>>> 173 uintx max_delta = >>>>>> uintx(MetaspaceShared::shared_rs()->size()); >>>>>> 174 assert(max_delta<= MAX_SHARED_DELTA, "range check"); >>>>>> >>>>>> - Why is the default RO space size increased? >>>>>> >>>>> That's because the symbol table is moved from RW to RO, so I had to >>>>> change the RO minimum size, or else >>>>> test/runtime/SharedArchiveFile/LimitSharedSizes.java would fail. >>>> Ok. >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>>> - >>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SymbolTable.java >>>>>> >>>>>> >>>>>> - >>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java >>>>>> >>>>>> >>>>>> Copyright year. >>>>> Will fix. >>>>> >>>>> Thanks >>>>> - Ioi >>>>>> Thanks, >>>>>> Jiangli >>>>>> >>>>>>> On Mar 31, 2016, at 10:43 PM, Ioi >>>>>>> Lam> wrote: >>>>>>> >>>>>>> Please review >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iklam/jdk9/8150607_cleanup_compact_hashtable.v01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Bug: Clean up CompactHashtable >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8150607 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Summary of fix: >>>>>>> >>>>>>> [1] Instead of reading/writing the table bit-by-bit, which is >>>>>>> tedious and >>>>>>> error prone, use SimpleCompactHashtable::serialize(), which is >>>>>>> more >>>>>>> structural. >>>>>>> >>>>>>> [2] Split up the _buckets and _entries into two separate arrays, >>>>>>> so the >>>>>>> dumping and walking code is easier to understand >>>>>>> >>>>>>> (see comments above SimpleCompactHashtable declaration) >>>>>>> These 2 arrays are now allocated from the RO region (used to >>>>>>> be in RW) >>>>>>> >>>>>>> [3] Renamed a few things >>>>>>> >>>>>>> COMPACT_BUCKET_TYPE -> TINY_BUCKET_TYPE >>>>>>> (having something called "compact" in CompactHashtable is >>>>>>> confusing) >>>>>>> >>>>>>> The old names "dump_table" (actually dumping the buckets) and >>>>>>> "dump_buckets" (actually dumping the entries) were conflicting >>>>>>> with >>>>>>> terminology used elsewhere. Now the terminology is unified: >>>>>>> "buckets" = the main index, "entries" = the second level. >>>>>>> >>>>>>> lookup_entry -> decode_entry (it wasn't doing any lookup) >>>>>>> >>>>>>> [4] Changed all "*p++" to "array->at_put", so out-of-bounds can be >>>>>>> checked with assert. >>>>>>> >>>>>>> [5] Replaced all juint to u4 (suggested by Coleen) >>>>>>> >>>>>>> [6] templatize the iterator (see CompactHashtable::symbols_do -> >>>>>>> SimpleCompactHashtable::iterate) >>>>>>> >>>>>>> [7] I also added a test case using Serviceability Agent -- due to >>>>>>> the lack of >>>>>>> a regression test, the walking of the compact hashtable in SA >>>>>>> had been >>>>>>> broken for a while before it was fixed in JDK-8151368, so >>>>>>> having a test >>>>>>> case would make the code more maintainable. >>>>>>> >>>>>>> Tests: >>>>>>> >>>>>>> Hotspot JTREG tests >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >> From david.holmes at oracle.com Mon Apr 18 04:38:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Apr 2016 14:38:55 +1000 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> Message-ID: <571464DF.3070706@oracle.com> Hi Hiroshi, On 18/04/2016 12:15 PM, Hiroshi H Horii wrote: > Hi David, > > Thank you for your replying and sorry that I didn't append my diff file > when the discussion was forwarded to this mailing list. I appended my > original diff file (hg diff -g) to this mail. > > > It is fine for ppc to have variations of cmpxchg with different memory > > barrier semantics, but the shared API must not be affected as there is a > > requirement that the basic form of this operation provide "full > > bi-directional fence" semantics. Note that these semantics are not in > > place to fulfill Java Memory Model requirements, but are an internal > > contract in hotspot. > > Sure. Probably, it is better for me to modify my patch because it > changes the internal contract. I will create a new patch that adds new > cmpxchg functions for ppc. I think this is only usable from PPC specific code, not from the shared code as per your original patch. The oopDesc::cas_set_mark may be written to expect the full bi-directional fence that is required by the atomic.hpp contract. If we break that contract we would have to prove correctness along all code paths using that code - well the ppc64 folk would have to do that :). But I would object to the platform-specific code in the shared file - sorry. Thanks, David > > Also can you get someone to host the webrev > > for you on cr.openjdk.java.net? Or else include the diff in the bug > report. > > I will ask someone to create webrev after my next patch is created. > > > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > David Holmes wrote on 04/16/2016 16:43:20: > > > From: David Holmes > > To: Christian Thalinger , Hiroshi H > > Horii/Japan/IBM at IBMJP > > Cc: Tim Ellison , ppc-aix-port- > > dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net > > Date: 04/16/2016 16:46 > > Subject: Re: enhancement of cmpxchg and copy_to_survivor for ppc64 > > > > Hi Hiroshi, > > > > As the diff file does not survive the mail process I can't see the > > actual proposed changes. There doesn't seem to be a bug for this so > > could you please file one. Also can you get someone to host the webrev > > for you on cr.openjdk.java.net? Or else include the diff in the bug > report. > > > > It is fine for ppc to have variations of cmpxchg with different memory > > barrier semantics, but the shared API must not be affected as there is a > > requirement that the basic form of this operation provide "full > > bi-directional fence" semantics. Note that these semantics are not in > > place to fulfill Java Memory Model requirements, but are an internal > > contract in hotspot. > > > > Thanks, > > David > > > > On 12/04/2016 3:59 AM, Christian Thalinger wrote: > > > [This should be on hotspot-runtime-dev. BCC?ing hotspot-compiler-dev.] > > > > > >> On Apr 8, 2016, at 12:53 AM, Hiroshi H Horii wrote: > > >> > > >> Dear all: > > >> > > >> Can I please request reviews for the following change? > > >> This change was created for JDK 9 and ppc64. > > >> > > >> Description: > > >> This change adds options of compare-and-exchange for POWER > architecture. > > >> As described in atomic_linux_ppc.inline.hpp, the current > implementation of > > >> cmpxchg is fence_cmpxchg_acquire. This implementation is useful for > > >> general purposes because twice calls of sync before and after > cmpxchg will > > >> keep consistency. However, they sometimes cause overheads because > > >> sync instructions are very expensive in the current POWER chip design. > > >> With this change, callers can explicitly specify to run fence and > > acquire with > > >> two additional bool parameters. Because their default values are > "true", > > >> it is not necessary to modify existing cmpxchg calls. > > >> > > >> In addition, with the new parameters of cmpxchg, this change improves > > >> performance of copy_to_survivor in the parallel GC. > > >> copy_to_survivor changes forward pointers by using cmpxchg. This > > >> operation doesn't require any sync instructions, in my understanding. > > >> A pointer is changed at most once in a GC and when cmpxchg fails, > > >> the latest pointer is available for the caller. > > >> > > >> When I evaluated SPECjbb2013 (slightly customized because obsolete > grizzly > > >> doesn't support new version format of Java 9), pause time of young > GC was > > >> reduced from 10% to 20%. > > >> > > >> Summary of source code changes: > > >> > > >> * src/share/vm/runtime/atomic.hpp > > >> * src/share/vm/runtime/atomic.cpp > > >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > > >> - Add two arguments of fence and acquire to cmpxchg only > for PPC64. > > >> Though cmpxchg in atomic_linux_ppc.inline.hpp has some > branches, > > >> they are reduced while inlining to callers. > > >> > > >> * src/share/vm/oops/oop.inline.hpp > > >> - Changed cas_set_mark to call cmpxchg without fence and > acquire. > > >> cas_set_mark is called only by cas_forward_to that is > > called only by > > >> copy_to_survivor_space and oop_promotion_failed in > > >> psPromotionManager. > > >> > > >> Code change: > > >> > > >> Please see an attached diff file that was generated with "hg > diff -g" > > >> under the latest hotspot directory. > > >> > > >> Passed test: > > >> SPECjbb2013 (customized) > > >> > > >> * I believe some other cmpxchg will be optimized by reducing fence > > >> or acquire because twice calls of sync are too conservative > toimplement > > >> Java memory model. > > >> > > >> > > >> > > >> Regards, > > >> Hiroshi > > >> ----------------------- > > >> Hiroshi Horii, Ph.D. > > >> IBM Research - Tokyo > > >> > > > > > > From david.holmes at oracle.com Mon Apr 18 04:40:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 18 Apr 2016 14:40:36 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571367B6.5020808@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5712BAB9.5040400@oracle.com> <57130544.8000601@gmail.com> <571367B6.5020808@oracle.com> Message-ID: <57146544.9050903@oracle.com> On 17/04/2016 8:38 PM, David Holmes wrote: > On 17/04/2016 1:38 PM, Yasumasa Suenaga wrote: >> Hi David, >> >>> Need to hear from core-libs and/or launcher folk as this touches a >>> number of pieces of code. >> >> I'm waiting more reviewer(s) . >> >> BTW, Should I make patches which are based on jdk9/dev repos? >> My proposal includes hotspot changes. >> So I want to know whether I can push all changes jdk9/dev/{jdk,hotspot} >> after reviewing. > > No, jdk9/hs please. And it will need to go via JPRT so I will sponsor it for you. Thanks, David > Thanks, > David > >> I can update my webrev to adapt to jdk9/dev repos if need. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/17 7:20, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 16/04/2016 7:29 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> I uploaded new webrev: >>>> >>>> - hotspot: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>> >>>> - jdk: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>> >>> Ah sneaky! :) Using JNI to by-pass access control so we can set up a >>> private method to do the name setting, yet avoid any API change that >>> would require a CCC request. I think I like it. :) >>> >>> Need to hear from core-libs and/or launcher folk as this touches a >>> number of pieces of code. >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>>> it won't work unless you change the semantics of setName so I'm not >>>>> sure what you were thinking here. To take advantage of an arg taking >>>>> JVM_SetNativThreadName you would need to call it directly as no Java >>>>> code will call it . ??? >>>> >>>> I added a flag for setting native thread name to JNI-attached thread. >>>> This change can set native thread name if main thread changes to >>>> JNI-attached thread. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/16 16:11, David Holmes wrote: >>>>> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> That change in behaviour may be a problem, it could be considered a >>>>>>> regression that setName stops setting the native thread main, even >>>>>>> though we never really intended it to work in the first place. :( >>>>>>> Such >>>>>>> a change needs to go through CCC. >>>>>> >>>>>> I understood. >>>>>> Can I send CCC request? >>>>>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>> >>>>> Sorry you can't file a CCC request, you would need a sponsor for that. >>>>> But at this stage I don't think I agree with the proposed change >>>>> because of the change in behaviour - there's no way to restore the >>>>> "broken" behaviour. >>>>> >>>>>> I want to continue to discuss about it on JDK-8154331 [1]. >>>>> >>>>> Okay we can do that. >>>>> >>>>>> >>>>>>> Further, we expect the launcher to use the supported JNI interface >>>>>>> (as >>>>>>> other processes would), not the internal JVM interface that exists >>>>>>> for >>>>>>> the JDK sources to communicate with the JVM. >>>>>> >>>>>> I think that we do not use JVM interface if we add new method in >>>>>> LauncherHelper as below: >>>>>> ---------------- >>>>>> diff -r f02139a1ac84 >>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> Wed Apr 13 14:19:30 2016 +0000 >>>>>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> Sat Apr 16 11:25:53 2016 +0900 >>>>>> @@ -960,4 +960,8 @@ >>>>>> else >>>>>> return md.toNameAndVersion() + " (" + loc + ")"; >>>>>> } >>>>>> + >>>>>> + static void setNativeThreadName(String name) { >>>>>> + Thread.currentThread().setName(name); >>>>>> + } >>>>> >>>>> You could also make that call via JNI directly, so not sure the helper >>>>> adds much here. But it won't work unless you change the semantics of >>>>> setName so I'm not sure what you were thinking here. To take advantage >>>>> of an arg taking JVM_SetNativThreadName you would need to call it >>>>> directly as no Java code will call it . ??? >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> } >>>>>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>>>>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >>>>>> 2016 +0000 >>>>>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >>>>>> 2016 +0900 >>>>>> @@ -125,6 +125,7 @@ >>>>>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>>> static void ShowSettings(JNIEnv* env, char *optString); >>>>>> static void ListModules(JNIEnv* env, char *optString); >>>>>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>>>> >>>>>> static void SetPaths(int argc, char **argv); >>>>>> >>>>>> @@ -325,6 +326,7 @@ >>>>>> * mainThread.isAlive() to work as expected. >>>>>> */ >>>>>> #define LEAVE() \ >>>>>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>> do { \ >>>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>> @@ -488,6 +490,9 @@ >>>>>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>> >>>>>> + /* Set native thread name. */ >>>>>> + SetNativeThreadName(env, "main"); >>>>>> + >>>>>> /* Invoke main method. */ >>>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>>>> >>>>>> @@ -1686,6 +1691,22 @@ >>>>>> joptString); >>>>>> } >>>>>> >>>>>> +/** >>>>>> + * Set native thread name as possible. >>>>>> + */ >>>>>> +static void >>>>>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>> +{ >>>>>> + jmethodID setNativeThreadNameID; >>>>>> + jstring nameString; >>>>>> + jclass cls = GetLauncherHelperClass(env); >>>>>> + NULL_CHECK(cls); >>>>>> + NULL_CHECK(setNativeThreadNameID = >>>>>> (*env)->GetStaticMethodID(env, cls, >>>>>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>>>>> nameString); >>>>>> +} >>>>>> + >>>>>> /* >>>>>> * Prints default usage or the Xusage message, see >>>>>> sun.launcher.LauncherHelper.java >>>>>> */ >>>>>> ---------------- >>>>>> >>>>>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>> >>>>>>> However this is still a change to the exported JVM interface and so >>>>>>> has to be approved. >>>>>> >>>>>> Do you mean that this change needs CCC? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> I think it is a bug based on the comment here: >>>>>>>>> >>>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>>>>>> thread and >>>>>>>>> JNI attached threads >>>>>>>> >>>>>>>> I filed it to JBS as JDK-8154331. >>>>>>>> I will send review request to hotspot-runtime-dev. >>>>>>>> >>>>>>>> >>>>>>>>> Though that will introduce a change in behaviour by itself as >>>>>>>>> setName >>>>>>>>> will no longer set the native name for the main thread. >>>>>>>> >>>>>>>> I know. >>>>>>> >>>>>>> That change in behaviour may be a problem, it could be considered a >>>>>>> regression that setName stops setting the native thread main, even >>>>>>> though we never really intended it to work in the first place. :( >>>>>>> Such >>>>>>> a change needs to go through CCC. >>>>>>> >>>>>>>> I checked changeset history. >>>>>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>>>>>>> backported JDK 8. >>>>>>> >>>>>>> Yes this all came in as part of the OSX port in 7u2. >>>>>>> >>>>>>>> However, this function seems to be called from >>>>>>>> Thread#setNativeName() >>>>>>>> only. >>>>>>>> In addition, Thread#setNativeName() is private method. >>>>>>>> >>>>>>>> Thus I think that we can add an argument to >>>>>>>> JVM_SetNativeThreadName() >>>>>>>> for force setting. >>>>>>>> (e.g. "bool forced") >>>>>>>> >>>>>>>> It makes a change of JVM API. >>>>>>>> However, this function is NOT public, so I think we can add one >>>>>>>> more >>>>>>>> argument. >>>>>>>> >>>>>>>> What do you think about this? >>>>>>>> If it is accepted, we can set native thread name from Java >>>>>>>> launcher. >>>>>>> >>>>>>> The private/public aspect of the Java API is not really at issue. >>>>>>> Yes >>>>>>> we would add another arg to the JVM function to allow it to apply to >>>>>>> JNI-attached threads as well (I'd prefer the arg reflect that not >>>>>>> just >>>>>>> "force"). However this is still a change to the exported JVM >>>>>>> interface >>>>>>> and so has to be approved. Further, we expect the launcher to use >>>>>>> the >>>>>>> supported JNI interface (as other processes would), not the internal >>>>>>> JVM interface that exists for the JDK sources to communicate with >>>>>>> the >>>>>>> JVM. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>>> The fact that the "main" thread is not tagged as being a >>>>>>>>>>> JNI-attached >>>>>>>>>>> thread seems accidental to me >>>>>>>>>> >>>>>>>>>> Should I file it to JBS? >>>>>>>>> >>>>>>>>> I think it is a bug based on the comment here: >>>>>>>>> >>>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>>>>>> thread and >>>>>>>>> JNI attached threads >>>>>>>>> >>>>>>>>> Though that will introduce a change in behaviour by itself as >>>>>>>>> setName >>>>>>>>> will no longer set the native name for the main thread. >>>>>>>>> >>>>>>>>>> I think that we can fix as below: >>>>>>>>>> --------------- >>>>>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 >>>>>>>>>> +0200 >>>>>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 >>>>>>>>>> +0900 >>>>>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>> >>>>>>>>>> // Attach the main thread to this os thread >>>>>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>> // must do this before set_active_handles >>>>>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>> // Notify JVMTI agents that VM initialization is complete - >>>>>>>>>> nop if >>>>>>>>>> no agents. >>>>>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>> >>>>>>>>>> + // Change attach status to "attached" >>>>>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>> + >>>>>>>>> >>>>>>>>> I think we can do this straight after the JavaThread constructor. >>>>>>>>> >>>>>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>>>>>> backend."); >>>>>>>>>> } >>>>>>>>>> --------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> If it wants to name its native threads then it is free to do so, >>>>>>>>>> >>>>>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread >>>>>>>>>> name >>>>>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>>> However, I think that it should be changed if Java developer >>>>>>>>>> calls >>>>>>>>>> Thread#setName() explicitly. >>>>>>>>>> It is not the same of changing native thread name at >>>>>>>>>> Threads::create_vm(). >>>>>>>>>> >>>>>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>>>>>> What do you think about this? >>>>>>>>> >>>>>>>>> The decision to not change the name of JNI-attached threads was a >>>>>>>>> deliberate one** - this functionality originated with the OSX port >>>>>>>>> and >>>>>>>>> it was reported that the initial feedback with this feature was to >>>>>>>>> ensure it didn't mess with thread names that had been set by the >>>>>>>>> host >>>>>>>>> process. If we do as you propose then we will just have an >>>>>>>>> inconsistency for people to complain about: "why does my native >>>>>>>>> thread >>>>>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>>>>>> >>>>>>>>> ** If you follow the bugs and related discussions on this, the >>>>>>>>> semantics and limitations (truncation, current thread only, >>>>>>>>> non-JNI >>>>>>>>> threads only) of setting the native thread name were supposed >>>>>>>>> to be >>>>>>>>> documented in the release notes - but as far as I can see that >>>>>>>>> never >>>>>>>>> happened. :( >>>>>>>>> >>>>>>>>> My position on this remains that if it is desirable for the main >>>>>>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>>>>>> launcher needs to be setting them using the available platform >>>>>>>>> APIs. >>>>>>>>> Unfortunately this is complicated - as evidenced by the VM code >>>>>>>>> for >>>>>>>>> this - due to the need to verify API availability. >>>>>>>>> >>>>>>>>> Any change in behaviour in relation to Thread.setName would have >>>>>>>>> to go >>>>>>>>> through our CCC process I think. But a change in the launcher >>>>>>>>> would >>>>>>>>> not. >>>>>>>>> >>>>>>>>> Sorry. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> --------------- >>>>>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 >>>>>>>>>> +0200 >>>>>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 >>>>>>>>>> +0900 >>>>>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>>>>>> // Thread naming only supported for the current thread, >>>>>>>>>> doesn't >>>>>>>>>> work >>>>>>>>>> for >>>>>>>>>> // target threads. >>>>>>>>>> - if (Thread::current() == thr && >>>>>>>>>> !thr->has_attached_via_jni()) { >>>>>>>>>> + if (Thread::current() == thr) { >>>>>>>>>> // we don't set the name of an attached thread to avoid >>>>>>>>>> stepping >>>>>>>>>> // on other programs >>>>>>>>>> const char *thread_name = >>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Roger, >>>>>>>>>>>> Thanks for your comment! >>>>>>>>>>>> >>>>>>>>>>>> David, >>>>>>>>>>>> >>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>> >>>>>>>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>>>>>>> calling >>>>>>>>>>>> main method), >>>>>>>>>>>> I could set native thread name. >>>>>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we >>>>>>>>>>>> can't >>>>>>>>>>>> set >>>>>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>> >>>>>>>>>>> Right - I came to the same realization earlier this morning. >>>>>>>>>>> Which, >>>>>>>>>>> unfortunately, takes me back to the basic premise here that we >>>>>>>>>>> don't >>>>>>>>>>> set the name of threads not created by the JVM. The fact that >>>>>>>>>>> the >>>>>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>>>>>>> accident for the initial attach, and can't be used for the >>>>>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >>>>>>>>>>> named at >>>>>>>>>>> the native level. >>>>>>>>>>> >>>>>>>>>>> I'm afraid my view here is that the launcher has to be treated >>>>>>>>>>> like >>>>>>>>>>> any other process that might host a JVM. If it wants to name its >>>>>>>>>>> native threads then it is free to do so, but I would not be >>>>>>>>>>> exporting >>>>>>>>>>> a function from the JVM to do that - it would have to use the OS >>>>>>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>>>>>> >>>>>>>>>>> Sorry. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Comments: >>>>>>>>>>>>> >>>>>>>>>>>>> jvm.h: The function names are too similar but perform >>>>>>>>>>>>> different >>>>>>>>>>>>> functions: >>>>>>>>>>>>> >>>>>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>>>>>> >>>>>>>>>>>>> - The first function applies to the current thread, the >>>>>>>>>>>>> second >>>>>>>>>>>>> one a >>>>>>>>>>>>> specific java thread. >>>>>>>>>>>>> It would seem useful for there to be a comment somewhere >>>>>>>>>>>>> about >>>>>>>>>>>>> what >>>>>>>>>>>>> the new function does. >>>>>>>>>>>>> >>>>>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>>>>>> instead of >>>>>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>>> >>>>>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>>> used at >>>>>>>>>>>>> line 730 >>>>>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast >>>>>>>>>>>>> on the >>>>>>>>>>>>> same >>>>>>>>>>>>> line as dlsym... >>>>>>>>>>>>> >>>>>>>>>>>>> $.02, Roger >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>>>> check - >>>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>>>>>>>>>>>> should >>>>>>>>>>>>>>> work >>>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed >>>>>>>>>>>>>> native >>>>>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>>>> --------- >>>>>>>>>>>>>> public class Sleep{ >>>>>>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> } >>>>>>>>>>>>>> --------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I exported new JVM function to set native thread name, >>>>>>>>>>>>>>>>>> and JLI >>>>>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> First the launcher belongs to another team so core-libs >>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>>>>>>>>>>>>>> Thread.setName >>>>>>>>>>>>>>>>> rather >>>>>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>>>>>>> needed in >>>>>>>>>>>>>>>>> that case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> At Thread.init time the thread is not alive, which is why >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> name is not set. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>>>> check - >>>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>>>>>>>>>>>> should >>>>>>>>>>>>>>> work >>>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thus I think that we have to provide a function to set >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> thread name. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we >>>>>>>>>>>>>>>>>>> do not >>>>>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>> Thu >>>>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>> Thu >>>>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>>>>>>>>>>>>>>>>>>>>>>> JavaThread(); >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>>>>>>>>>>>>>>>>> set_active_handles >>>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread >>>>>>>>>>>>>>>>>>>>>>>>> name in >>>>>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already >>>>>>>>>>>>>>>>>>>>>>>>> starte >>>>>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue >>>>>>>>>>>>>>>>>>>>>>>>> Mar 29 >>>>>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed >>>>>>>>>>>>>>>>>>>>>>>>> Mar 30 >>>>>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = >>>>>>>>>>>>>>>>>>>>>>>>> "main"; >>>>>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>>>> thread); >>>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' >>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and >>>>>>>>>>>>>>>>>>>>>>>>> thus >>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>> So I >>>>>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we >>>>>>>>>>>>>>>>>>>>>>>>> want >>>>>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might >>>>>>>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java >>>>>>>>>>>>>>>>>>>>>>>>> Main >>>>>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - >>>>>>>>>>>>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I >>>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name >>>>>>>>>>>>>>>>>>>>>>>>> via >>>>>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and >>>>>>>>>>>>>>>>>>>>>>>>> main >>>>>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review >>>>>>>>>>>>>>>>>>>>>>>>> it? >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> From erik.osterlund at oracle.com Mon Apr 18 05:35:39 2016 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Mon, 18 Apr 2016 07:35:39 +0200 Subject: RFR (S): 8153751: Windows Atomic and OrderAccess are not emitting explicit compiler barriers In-Reply-To: <57120002.90703@oracle.com> References: <57077322.3000009@oracle.com> <57120002.90703@oracle.com> Message-ID: Hi David, Thanks for helping with this. Much appreciated! :) /Erik > On 16 apr. 2016, at 11:04, David Holmes wrote: > > Hi Erik, > > Still catching up on vacation email backlog but I will review this asap. > > I see no one else has been game to step in yet :) > > David > >> On 8/04/2016 7:00 PM, Erik ?sterlund wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153751 >> Webrev: http://cr.openjdk.java.net/~eosterlund/8153751/webrev.00/ >> >> It turns out that on Windows, compiler barriers are not used for >> Atomic:: code and some code in OrderAccess. It is assumed that the >> non-volatile accesses will not be reordered across __asm statements, as >> the current memory model should prevent. But I have not found any >> guarantees that this is the case for __asm. >> >> The closest source I could find is the documentation for the >> MemoryBarrier macro that uses an __asm statement to produce a hardware >> membar. The documentation says the following: "Creates a hardware memory >> barrier (fence) that prevents the CPU from re-ordering read and write >> operations. It may also prevent the compiler from re-ordering read and >> write operations." >> >> Note the "MAY" prevent compiler reordering. (*facepalm*) This sounds to >> me like __asm really does not guarantee compiler reordering across __asm >> at all. >> >> A suspected victim of this reordering is here: >> https://bugs.openjdk.java.net/browse/JDK-8033545 >> >> To make the use of these classes more safe, I propose to simply add >> explicit compiler barriers in this windows code. It should not make any >> difference, as I am only enforcing compiler reordering rules that should >> already hold. >> >> This small patch fixes this. The only thing to note is that the __asm >> statements that put things in %eax and avoid returning anything. >> >> Testing: JPRT >> >> Thanks, >> /Erik From yasuenag at gmail.com Mon Apr 18 10:28:15 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 18 Apr 2016 19:28:15 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57146544.9050903@oracle.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5712BAB9.5040400@oracle.com> <57130544.8000601@gmail.com> <571367B6.5020808@oracle.com> <57146544.9050903@oracle.com> Message-ID: 2016/04/18 13:41 "David Holmes" : > > On 17/04/2016 8:38 PM, David Holmes wrote: >> >> On 17/04/2016 1:38 PM, Yasumasa Suenaga wrote: >>> >>> Hi David, >>> >>>> Need to hear from core-libs and/or launcher folk as this touches a >>>> number of pieces of code. >>> >>> >>> I'm waiting more reviewer(s) . >>> >>> BTW, Should I make patches which are based on jdk9/dev repos? >>> My proposal includes hotspot changes. >>> So I want to know whether I can push all changes jdk9/dev/{jdk,hotspot} >>> after reviewing. >> >> >> No, jdk9/hs please. > > > And it will need to go via JPRT so I will sponsor it for you. Thanks! I will send changesets to you after reviewing. Yasumasa > Thanks, > David > > >> Thanks, >> David >> >>> I can update my webrev to adapt to jdk9/dev repos if need. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/17 7:20, David Holmes wrote: >>>> >>>> Hi Yasumasa, >>>> >>>> On 16/04/2016 7:29 PM, Yasumasa Suenaga wrote: >>>>> >>>>> Hi David, >>>>> >>>>> I uploaded new webrev: >>>>> >>>>> - hotspot: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>> >>>>> - jdk: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>> >>>> >>>> Ah sneaky! :) Using JNI to by-pass access control so we can set up a >>>> private method to do the name setting, yet avoid any API change that >>>> would require a CCC request. I think I like it. :) >>>> >>>> Need to hear from core-libs and/or launcher folk as this touches a >>>> number of pieces of code. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>>> it won't work unless you change the semantics of setName so I'm not >>>>>> sure what you were thinking here. To take advantage of an arg taking >>>>>> JVM_SetNativThreadName you would need to call it directly as no Java >>>>>> code will call it . ??? >>>>> >>>>> >>>>> I added a flag for setting native thread name to JNI-attached thread. >>>>> This change can set native thread name if main thread changes to >>>>> JNI-attached thread. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/16 16:11, David Holmes wrote: >>>>>> >>>>>> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>>> That change in behaviour may be a problem, it could be considered a >>>>>>>> regression that setName stops setting the native thread main, even >>>>>>>> though we never really intended it to work in the first place. :( >>>>>>>> Such >>>>>>>> a change needs to go through CCC. >>>>>>> >>>>>>> >>>>>>> I understood. >>>>>>> Can I send CCC request? >>>>>>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>>> >>>>>> >>>>>> Sorry you can't file a CCC request, you would need a sponsor for that. >>>>>> But at this stage I don't think I agree with the proposed change >>>>>> because of the change in behaviour - there's no way to restore the >>>>>> "broken" behaviour. >>>>>> >>>>>>> I want to continue to discuss about it on JDK-8154331 [1]. >>>>>> >>>>>> >>>>>> Okay we can do that. >>>>>> >>>>>>> >>>>>>>> Further, we expect the launcher to use the supported JNI interface >>>>>>>> (as >>>>>>>> other processes would), not the internal JVM interface that exists >>>>>>>> for >>>>>>>> the JDK sources to communicate with the JVM. >>>>>>> >>>>>>> >>>>>>> I think that we do not use JVM interface if we add new method in >>>>>>> LauncherHelper as below: >>>>>>> ---------------- >>>>>>> diff -r f02139a1ac84 >>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>> @@ -960,4 +960,8 @@ >>>>>>> else >>>>>>> return md.toNameAndVersion() + " (" + loc + ")"; >>>>>>> } >>>>>>> + >>>>>>> + static void setNativeThreadName(String name) { >>>>>>> + Thread.currentThread().setName(name); >>>>>>> + } >>>>>> >>>>>> >>>>>> You could also make that call via JNI directly, so not sure the helper >>>>>> adds much here. But it won't work unless you change the semantics of >>>>>> setName so I'm not sure what you were thinking here. To take advantage >>>>>> of an arg taking JVM_SetNativThreadName you would need to call it >>>>>> directly as no Java code will call it . ??? >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> } >>>>>>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>>>>>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >>>>>>> 2016 +0000 >>>>>>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >>>>>>> 2016 +0900 >>>>>>> @@ -125,6 +125,7 @@ >>>>>>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>>>> static void ShowSettings(JNIEnv* env, char *optString); >>>>>>> static void ListModules(JNIEnv* env, char *optString); >>>>>>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>>>>> >>>>>>> static void SetPaths(int argc, char **argv); >>>>>>> >>>>>>> @@ -325,6 +326,7 @@ >>>>>>> * mainThread.isAlive() to work as expected. >>>>>>> */ >>>>>>> #define LEAVE() \ >>>>>>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>> do { \ >>>>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>> @@ -488,6 +490,9 @@ >>>>>>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>>>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>> >>>>>>> + /* Set native thread name. */ >>>>>>> + SetNativeThreadName(env, "main"); >>>>>>> + >>>>>>> /* Invoke main method. */ >>>>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>>>>> >>>>>>> @@ -1686,6 +1691,22 @@ >>>>>>> joptString); >>>>>>> } >>>>>>> >>>>>>> +/** >>>>>>> + * Set native thread name as possible. >>>>>>> + */ >>>>>>> +static void >>>>>>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>> +{ >>>>>>> + jmethodID setNativeThreadNameID; >>>>>>> + jstring nameString; >>>>>>> + jclass cls = GetLauncherHelperClass(env); >>>>>>> + NULL_CHECK(cls); >>>>>>> + NULL_CHECK(setNativeThreadNameID = >>>>>>> (*env)->GetStaticMethodID(env, cls, >>>>>>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>>>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>>>>>> nameString); >>>>>>> +} >>>>>>> + >>>>>>> /* >>>>>>> * Prints default usage or the Xusage message, see >>>>>>> sun.launcher.LauncherHelper.java >>>>>>> */ >>>>>>> ---------------- >>>>>>> >>>>>>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>>> >>>>>>>> However this is still a change to the exported JVM interface and so >>>>>>>> has to be approved. >>>>>>> >>>>>>> >>>>>>> Do you mean that this change needs CCC? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>> >>>>>>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> I think it is a bug based on the comment here: >>>>>>>>>> >>>>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>>>>>>> thread and >>>>>>>>>> JNI attached threads >>>>>>>>> >>>>>>>>> >>>>>>>>> I filed it to JBS as JDK-8154331. >>>>>>>>> I will send review request to hotspot-runtime-dev. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Though that will introduce a change in behaviour by itself as >>>>>>>>>> setName >>>>>>>>>> will no longer set the native name for the main thread. >>>>>>>>> >>>>>>>>> >>>>>>>>> I know. >>>>>>>> >>>>>>>> >>>>>>>> That change in behaviour may be a problem, it could be considered a >>>>>>>> regression that setName stops setting the native thread main, even >>>>>>>> though we never really intended it to work in the first place. :( >>>>>>>> Such >>>>>>>> a change needs to go through CCC. >>>>>>>> >>>>>>>>> I checked changeset history. >>>>>>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>>>>>>>> backported JDK 8. >>>>>>>> >>>>>>>> >>>>>>>> Yes this all came in as part of the OSX port in 7u2. >>>>>>>> >>>>>>>>> However, this function seems to be called from >>>>>>>>> Thread#setNativeName() >>>>>>>>> only. >>>>>>>>> In addition, Thread#setNativeName() is private method. >>>>>>>>> >>>>>>>>> Thus I think that we can add an argument to >>>>>>>>> JVM_SetNativeThreadName() >>>>>>>>> for force setting. >>>>>>>>> (e.g. "bool forced") >>>>>>>>> >>>>>>>>> It makes a change of JVM API. >>>>>>>>> However, this function is NOT public, so I think we can add one >>>>>>>>> more >>>>>>>>> argument. >>>>>>>>> >>>>>>>>> What do you think about this? >>>>>>>>> If it is accepted, we can set native thread name from Java >>>>>>>>> launcher. >>>>>>>> >>>>>>>> >>>>>>>> The private/public aspect of the Java API is not really at issue. >>>>>>>> Yes >>>>>>>> we would add another arg to the JVM function to allow it to apply to >>>>>>>> JNI-attached threads as well (I'd prefer the arg reflect that not >>>>>>>> just >>>>>>>> "force"). However this is still a change to the exported JVM >>>>>>>> interface >>>>>>>> and so has to be approved. Further, we expect the launcher to use >>>>>>>> the >>>>>>>> supported JNI interface (as other processes would), not the internal >>>>>>>> JVM interface that exists for the JDK sources to communicate with >>>>>>>> the >>>>>>>> JVM. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>> >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>>> The fact that the "main" thread is not tagged as being a >>>>>>>>>>>> JNI-attached >>>>>>>>>>>> thread seems accidental to me >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Should I file it to JBS? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think it is a bug based on the comment here: >>>>>>>>>> >>>>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>>>>>>> thread and >>>>>>>>>> JNI attached threads >>>>>>>>>> >>>>>>>>>> Though that will introduce a change in behaviour by itself as >>>>>>>>>> setName >>>>>>>>>> will no longer set the native name for the main thread. >>>>>>>>>> >>>>>>>>>>> I think that we can fix as below: >>>>>>>>>>> --------------- >>>>>>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 >>>>>>>>>>> +0200 >>>>>>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 >>>>>>>>>>> +0900 >>>>>>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>>> >>>>>>>>>>> // Attach the main thread to this os thread >>>>>>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>> // must do this before set_active_handles >>>>>>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>>> // Notify JVMTI agents that VM initialization is complete - >>>>>>>>>>> nop if >>>>>>>>>>> no agents. >>>>>>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>>> >>>>>>>>>>> + // Change attach status to "attached" >>>>>>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>>> + >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think we can do this straight after the JavaThread constructor. >>>>>>>>>> >>>>>>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>>>>>>> backend."); >>>>>>>>>>> } >>>>>>>>>>> --------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If it wants to name its native threads then it is free to do so, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread >>>>>>>>>>> name >>>>>>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>>>> However, I think that it should be changed if Java developer >>>>>>>>>>> calls >>>>>>>>>>> Thread#setName() explicitly. >>>>>>>>>>> It is not the same of changing native thread name at >>>>>>>>>>> Threads::create_vm(). >>>>>>>>>>> >>>>>>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>>>>>>> What do you think about this? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The decision to not change the name of JNI-attached threads was a >>>>>>>>>> deliberate one** - this functionality originated with the OSX port >>>>>>>>>> and >>>>>>>>>> it was reported that the initial feedback with this feature was to >>>>>>>>>> ensure it didn't mess with thread names that had been set by the >>>>>>>>>> host >>>>>>>>>> process. If we do as you propose then we will just have an >>>>>>>>>> inconsistency for people to complain about: "why does my native >>>>>>>>>> thread >>>>>>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>>>>>>> >>>>>>>>>> ** If you follow the bugs and related discussions on this, the >>>>>>>>>> semantics and limitations (truncation, current thread only, >>>>>>>>>> non-JNI >>>>>>>>>> threads only) of setting the native thread name were supposed >>>>>>>>>> to be >>>>>>>>>> documented in the release notes - but as far as I can see that >>>>>>>>>> never >>>>>>>>>> happened. :( >>>>>>>>>> >>>>>>>>>> My position on this remains that if it is desirable for the main >>>>>>>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>>>>>>> launcher needs to be setting them using the available platform >>>>>>>>>> APIs. >>>>>>>>>> Unfortunately this is complicated - as evidenced by the VM code >>>>>>>>>> for >>>>>>>>>> this - due to the need to verify API availability. >>>>>>>>>> >>>>>>>>>> Any change in behaviour in relation to Thread.setName would have >>>>>>>>>> to go >>>>>>>>>> through our CCC process I think. But a change in the launcher >>>>>>>>>> would >>>>>>>>>> not. >>>>>>>>>> >>>>>>>>>> Sorry. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> --------------- >>>>>>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 >>>>>>>>>>> +0200 >>>>>>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 >>>>>>>>>>> +0900 >>>>>>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>>>>>>> // Thread naming only supported for the current thread, >>>>>>>>>>> doesn't >>>>>>>>>>> work >>>>>>>>>>> for >>>>>>>>>>> // target threads. >>>>>>>>>>> - if (Thread::current() == thr && >>>>>>>>>>> !thr->has_attached_via_jni()) { >>>>>>>>>>> + if (Thread::current() == thr) { >>>>>>>>>>> // we don't set the name of an attached thread to avoid >>>>>>>>>>> stepping >>>>>>>>>>> // on other programs >>>>>>>>>>> const char *thread_name = >>>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Roger, >>>>>>>>>>>>> Thanks for your comment! >>>>>>>>>>>>> >>>>>>>>>>>>> David, >>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>>>>>>>> calling >>>>>>>>>>>>> main method), >>>>>>>>>>>>> I could set native thread name. >>>>>>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we >>>>>>>>>>>>> can't >>>>>>>>>>>>> set >>>>>>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Right - I came to the same realization earlier this morning. >>>>>>>>>>>> Which, >>>>>>>>>>>> unfortunately, takes me back to the basic premise here that we >>>>>>>>>>>> don't >>>>>>>>>>>> set the name of threads not created by the JVM. The fact that >>>>>>>>>>>> the >>>>>>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>>>>>>>> accident for the initial attach, and can't be used for the >>>>>>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >>>>>>>>>>>> named at >>>>>>>>>>>> the native level. >>>>>>>>>>>> >>>>>>>>>>>> I'm afraid my view here is that the launcher has to be treated >>>>>>>>>>>> like >>>>>>>>>>>> any other process that might host a JVM. If it wants to name its >>>>>>>>>>>> native threads then it is free to do so, but I would not be >>>>>>>>>>>> exporting >>>>>>>>>>>> a function from the JVM to do that - it would have to use the OS >>>>>>>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>>>>>>> >>>>>>>>>>>> Sorry. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Comments: >>>>>>>>>>>>>> >>>>>>>>>>>>>> jvm.h: The function names are too similar but perform >>>>>>>>>>>>>> different >>>>>>>>>>>>>> functions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>>>>>>> >>>>>>>>>>>>>> - The first function applies to the current thread, the >>>>>>>>>>>>>> second >>>>>>>>>>>>>> one a >>>>>>>>>>>>>> specific java thread. >>>>>>>>>>>>>> It would seem useful for there to be a comment somewhere >>>>>>>>>>>>>> about >>>>>>>>>>>>>> what >>>>>>>>>>>>>> the new function does. >>>>>>>>>>>>>> >>>>>>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>>>>>>> instead of >>>>>>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>>>> used at >>>>>>>>>>>>>> line 730 >>>>>>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast >>>>>>>>>>>>>> on the >>>>>>>>>>>>>> same >>>>>>>>>>>>>> line as dlsym... >>>>>>>>>>>>>> >>>>>>>>>>>>>> $.02, Roger >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>>>>> check - >>>>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>> public class Sleep{ >>>>>>>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I exported new JVM function to set native thread name, >>>>>>>>>>>>>>>>>>> and JLI >>>>>>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> First the launcher belongs to another team so core-libs >>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>>>>>>>>>>>>>>> Thread.setName >>>>>>>>>>>>>>>>>> rather >>>>>>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>>>>>>>> needed in >>>>>>>>>>>>>>>>>> that case. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At Thread.init time the thread is not alive, which is why >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> name is not set. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>>>>> check - >>>>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thus I think that we have to provide a function to set >>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>> thread name. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we >>>>>>>>>>>>>>>>>>>> do not >>>>>>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> Thu >>>>>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> Thu >>>>>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread(); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>>>>>>>>>>>>>>>>>> set_active_handles >>>>>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread >>>>>>>>>>>>>>>>>>>>>>>>>> name in >>>>>>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already >>>>>>>>>>>>>>>>>>>>>>>>>> starte >>>>>>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue >>>>>>>>>>>>>>>>>>>>>>>>>> Mar 29 >>>>>>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed >>>>>>>>>>>>>>>>>>>>>>>>>> Mar 30 >>>>>>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = >>>>>>>>>>>>>>>>>>>>>>>>>> "main"; >>>>>>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>>>>> thread); >>>>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' >>>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and >>>>>>>>>>>>>>>>>>>>>>>>>> thus >>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>>> So I >>>>>>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we >>>>>>>>>>>>>>>>>>>>>>>>>> want >>>>>>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might >>>>>>>>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java >>>>>>>>>>>>>>>>>>>>>>>>>> Main >>>>>>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - >>>>>>>>>>>>>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I >>>>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name >>>>>>>>>>>>>>>>>>>>>>>>>> via >>>>>>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and >>>>>>>>>>>>>>>>>>>>>>>>>> main >>>>>>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review >>>>>>>>>>>>>>>>>>>>>>>>>> it? >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> From varming at gmail.com Mon Apr 18 13:01:47 2016 From: varming at gmail.com (Carsten Varming) Date: Mon, 18 Apr 2016 09:01:47 -0400 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <571464DF.3070706@oracle.com> References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> Message-ID: Dear Hiroshi and David, I took a brief look at the patch and the idea looks good to me, in fact, a bunch of the garbage collectors could benefit from similar changes (G1 and ParNew both use oopDesc::forward_to_atomic which does not call cas_set_mark, and they could both benefit from the weaker semantics). An important question is: Should the shared parts of hotspot move towards weaker memory models? If yes, then everybody should review code assuming the weaker semantics. If no, then there really isn't room for patches like this one :(. The patch needs some work (IMHO). The name cas_set_mark must be renamed to reflect the weaker semantics, and the ifdefs in the shared code should be removed. All platforms should be changed as the Atomic API is extended, and platforms with weaker memory models should implement the weaker semantics. Finally, oopDesc::forward_to_atomic should use the weaker semantics, preferable by calling cas_set_mark instead of calling into Atomic directly. BTW. what is going on in oopDesc::forward_to_atomic? If curMark != oldMark, then curMark must have been marked (a similar fact is checked by "assert(is_forwarded())" (modulo a short race)), oldMark is set to curMark and then oldMark->is_marked is checked in the look condition. Why is there a loop? It seems much simpler if the assert is changed to a "guarantee(curMark->is_marked)" and the loop is changed to an if statement. Oh, and an assert is probably sufficient. My 2 cents, Carsten On Mon, Apr 18, 2016 at 12:38 AM, David Holmes wrote: > Hi Hiroshi, > > On 18/04/2016 12:15 PM, Hiroshi H Horii wrote: > >> Hi David, >> >> Thank you for your replying and sorry that I didn't append my diff file >> when the discussion was forwarded to this mailing list. I appended my >> original diff file (hg diff -g) to this mail. >> >> > It is fine for ppc to have variations of cmpxchg with different memory >> > barrier semantics, but the shared API must not be affected as there is >> a >> > requirement that the basic form of this operation provide "full >> > bi-directional fence" semantics. Note that these semantics are not in >> > place to fulfill Java Memory Model requirements, but are an internal >> > contract in hotspot. >> >> Sure. Probably, it is better for me to modify my patch because it >> changes the internal contract. I will create a new patch that adds new >> cmpxchg functions for ppc. >> > > I think this is only usable from PPC specific code, not from the shared > code as per your original patch. The oopDesc::cas_set_mark may be written > to expect the full bi-directional fence that is required by the atomic.hpp > contract. If we break that contract we would have to prove correctness > along all code paths using that code - well the ppc64 folk would have to do > that :). But I would object to the platform-specific code in the shared > file - sorry. > > Thanks, > David > > > Also can you get someone to host the webrev >> > for you on cr.openjdk.java.net? Or else include the diff in the bug >> report. >> >> I will ask someone to create webrev after my next patch is created. >> >> >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, Ph.D. >> IBM Research - Tokyo >> >> >> David Holmes wrote on 04/16/2016 16:43:20: >> >> > From: David Holmes >> > To: Christian Thalinger , Hiroshi H >> > Horii/Japan/IBM at IBMJP >> > Cc: Tim Ellison , ppc-aix-port- >> > dev at openjdk.java.net, hotspot-runtime-dev at openjdk.java.net >> > Date: 04/16/2016 16:46 >> > Subject: Re: enhancement of cmpxchg and copy_to_survivor for ppc64 >> >> > >> > Hi Hiroshi, >> > >> > As the diff file does not survive the mail process I can't see the >> > actual proposed changes. There doesn't seem to be a bug for this so >> > could you please file one. Also can you get someone to host the webrev >> > for you on cr.openjdk.java.net? Or else include the diff in the bug >> report. >> > >> > It is fine for ppc to have variations of cmpxchg with different memory >> > barrier semantics, but the shared API must not be affected as there is >> a >> > requirement that the basic form of this operation provide "full >> > bi-directional fence" semantics. Note that these semantics are not in >> > place to fulfill Java Memory Model requirements, but are an internal >> > contract in hotspot. >> > >> > Thanks, >> > David >> > >> > On 12/04/2016 3:59 AM, Christian Thalinger wrote: >> > > [This should be on hotspot-runtime-dev. BCC?ing >> hotspot-compiler-dev.] >> > > >> > >> On Apr 8, 2016, at 12:53 AM, Hiroshi H Horii >> wrote: >> > >> >> > >> Dear all: >> > >> >> > >> Can I please request reviews for the following change? >> > >> This change was created for JDK 9 and ppc64. >> > >> >> > >> Description: >> > >> This change adds options of compare-and-exchange for POWER >> architecture. >> > >> As described in atomic_linux_ppc.inline.hpp, the current >> implementation of >> > >> cmpxchg is fence_cmpxchg_acquire. This implementation is useful for >> > >> general purposes because twice calls of sync before and after >> cmpxchg will >> > >> keep consistency. However, they sometimes cause overheads because >> > >> sync instructions are very expensive in the current POWER chip >> design. >> > >> With this change, callers can explicitly specify to run fence and >> > acquire with >> > >> two additional bool parameters. Because their default values are >> "true", >> > >> it is not necessary to modify existing cmpxchg calls. >> > >> >> > >> In addition, with the new parameters of cmpxchg, this change >> improves >> > >> performance of copy_to_survivor in the parallel GC. >> > >> copy_to_survivor changes forward pointers by using cmpxchg. This >> > >> operation doesn't require any sync instructions, in my >> understanding. >> > >> A pointer is changed at most once in a GC and when cmpxchg fails, >> > >> the latest pointer is available for the caller. >> > >> >> > >> When I evaluated SPECjbb2013 (slightly customized because obsolete >> grizzly >> > >> doesn't support new version format of Java 9), pause time of young >> GC was >> > >> reduced from 10% to 20%. >> > >> >> > >> Summary of source code changes: >> > >> >> > >> * src/share/vm/runtime/atomic.hpp >> > >> * src/share/vm/runtime/atomic.cpp >> > >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >> > >> - Add two arguments of fence and acquire to cmpxchg only >> for PPC64. >> > >> Though cmpxchg in atomic_linux_ppc.inline.hpp has some >> branches, >> > >> they are reduced while inlining to callers. >> > >> >> > >> * src/share/vm/oops/oop.inline.hpp >> > >> - Changed cas_set_mark to call cmpxchg without fence and >> acquire. >> > >> cas_set_mark is called only by cas_forward_to that is >> > called only by >> > >> copy_to_survivor_space and oop_promotion_failed in >> > >> psPromotionManager. >> > >> >> > >> Code change: >> > >> >> > >> Please see an attached diff file that was generated with "hg >> diff -g" >> > >> under the latest hotspot directory. >> > >> >> > >> Passed test: >> > >> SPECjbb2013 (customized) >> > >> >> > >> * I believe some other cmpxchg will be optimized by reducing fence >> > >> or acquire because twice calls of sync are too conservative >> toimplement >> > >> Java memory model. >> > >> >> > >> >> > >> >> > >> Regards, >> > >> Hiroshi >> > >> ----------------------- >> > >> Hiroshi Horii, Ph.D. >> > >> IBM Research - Tokyo >> > >> >> > > >> > >> >> From coleen.phillimore at oracle.com Mon Apr 18 13:32:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 18 Apr 2016 09:32:32 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <57135B6E.2040402@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57135B6E.2040402@oracle.com> Message-ID: <5714E1F0.7070002@oracle.com> On 4/17/16 5:46 AM, David Holmes wrote: > Hi Max, > > Sorry for being late to the party here ... > > On 15/04/2016 2:22 AM, Max Ockner wrote: >> new webrev: >> http://cr.openjdk.java.net/~mockner/8151526.05/ >> - new describe_* methods are now private >> - VMError is now a friend class in logConfiguration. > > but I also think reporting the available log level and tags is not the > kind of thing we need in the hs_err file. The hs_err file captures > information specific to the execution of the VM that crashed - the > dynamic state if you like. The available log levels and tags are > static information in the source code and don't tell me anything about > the crash. (We didn't report which TraceXXX flags existed). Yes, I agree, this line to describe_available() doesn't need to appear in the crash log (but keep in vm.info because it's tied in with the main 'describe' function). > > While I'm all for providing useful crash information the hs_err file > is starting to suffer from bloat in my opinion. This one line is the least of the problems in the hs_err file. Wait until you see it printing the 100s of GC threads and all the NTAMS whatever they are. Coleen > > Thanks, > David > ----- > > >> Thanks, >> Max >> >> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>> Hello, >>>> I have made these changes. >>>> - refactored describe into a portion which uses locking and one that >>>> does not. >>>> - in the print_vm_info function in vmError.cpp, describe() is used, >>>> since this function is called while the program is running. >>>> - in the report function, the describe_no_lock and describe_with_lock >>>> functions are both used without taking a lock. If it doesnt crash, >>>> then fantastic. If it does crash, the error handler will skip this >>>> step anyway. >>>> >>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>> >>> I suggest making the new two functions private in LogConfiguration, >>> and friending VMError, instead of keeping them public. That should >>> reduce confusion about which describe-method to use, and prevent >>> misuse of the describe_with_lock in other places. >>> >>> Otherwise this looks good. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> Thanks, >>>> Max >>>> >>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>> Hey, >>>>> >>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>> Marcus, >>>>>> >>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>> configuration during a crash without lock and it crashes, the error >>>>>> handler will eat it up and start at the next step. It would be fun >>>>>> to write a locking mechanism, but this seems better to me. >>>>>> >>>>>> I will continue to call describe() from VM.info, but I will >>>>>> refactor the code in describe so that all of the information can be >>>>>> printed easily without taking a lock. For a crash, I'll use the >>>>>> refactored print functions to print all the necessary information >>>>>> without taking a lock. Even if the vm crashes during this step it >>>>>> is not such a bad thing because of the robust error handler. >>>>> >>>>> Alright, that sounds good! >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I have looked into this and I see a possible workaround to the >>>>>>>> issue raised by Marcus: >>>>>>>> >>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>> which >>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>> error >>>>>>>> handler could potentially deadlock if its thread already holds >>>>>>>> the lock. Unsure how to resolve this, because skipping to take >>>>>>>> the lock means that we might crash due to another thread >>>>>>>> changing the configuration as we read it. >>>>>>>> >>>>>>>> >>>>>>>> My proposed solution is this: >>>>>>>> >>>>>>>> If the ConfigurationLock is held by another thread during the >>>>>>>> crash, then I think we could print "Log configuration can not be >>>>>>>> accessed because ConfigurationLock is currently held by another >>>>>>>> thread" or something similar. If the ConfigurationLock can be >>>>>>>> taken by the current thread, then print the configuration. >>>>>>>> >>>>>>>> We can accomplish this as follows: >>>>>>>> >>>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe class >>>>>>>> extending ConfigurationLock. >>>>>>>> >>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>> private: >>>>>>>> bool _success; >>>>>>>> public: >>>>>>>> ConfigurationLockMaybe() { >>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>> } >>>>>>>> ~ConfigurationLock() { >>>>>>>> if(_success){_semaphore.signal();} >>>>>>>> } >>>>>>>> bool has_lock(){return _success;} >>>>>>>> }; >>>>>>>> >>>>>>>> _semaphore is a static var in ConfigurationLock, so the same copy >>>>>>>> is accessed in child classes. >>>>>>>> >>>>>>>> Another method LogConfiguration::describe_on_crash(outputStream* >>>>>>>> out) can use ConfigurationLockMaybe to attempt to print the >>>>>>>> configuration. >>>>>>>> >>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>> LogConfiguration::describe_on_crash. >>>>>>> >>>>>>> Sounds good to me. >>>>>>> >>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>>> better suggestion. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>> >>>>>>>> Max >>>>>>>> >>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>> >>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do we really need a list of all tags and all decorators? >>>>>>>>>>>>>> >>>>>>>>>>>>> Just going by what we currently put in the hs_err file, >>>>>>>>>>>>> I think >>>>>>>>>>>>> this may be the first "Do we really need" we've ever >>>>>>>>>>>>> asked for >>>>>>>>>>>>> this type of change. >>>>>>>>>>>>> >>>>>>>>>>>>> All joking aside, I think it is a good idea to direct >>>>>>>>>>>>> users >>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>> >>>>>>>>>>>>>> Also: I assume what you print is the Log state as it is >>>>>>>>>>>>>> at the >>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. with >>>>>>>>>>>>>> jcmd, >>>>>>>>>>>>>> would it be possible to see that? At least a warning if >>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>> >>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>> require a >>>>>>>>>>>>> framework change. It does not look like any marks are >>>>>>>>>>>>> made when >>>>>>>>>>>>> the LogConfiguration changes during runtime, and we >>>>>>>>>>>>> would need >>>>>>>>>>>>> to record that in order to know what to print when we >>>>>>>>>>>>> dump into >>>>>>>>>>>>> hs_err. >>>>>>>>>>>> >>>>>>>>>>>> Yes, this would required the framework to keep some sort >>>>>>>>>>>> of log >>>>>>>>>>>> of configuration changes. Is there value in knowing that >>>>>>>>>>>> the log >>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>> >>>>>>>>>>> I think it is useful along with other information. An >>>>>>>>>>> example case: >>>>>>>>>>> >>>>>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>>>>> acquired or >>>>>>>>>>> released. In a subsystem like this, the action which dooms >>>>>>>>>>> the vm >>>>>>>>>>> may not cause an immediate crash. This leaves time for >>>>>>>>>>> logging to >>>>>>>>>>> turn on or off in between the bad action and the crash. If >>>>>>>>>>> you >>>>>>>>>>> don't know when logging was active and when it was not, >>>>>>>>>>> then the >>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>> information. You may not see the message that has the >>>>>>>>>>> answer for >>>>>>>>>>> you because it was not logged, though the action may have >>>>>>>>>>> occurred. >>>>>>>>>>> >>>>>>>>>>> However, if we don't have the framework support for this >>>>>>>>>>> then I >>>>>>>>>>> believe it should be added later. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This is a good example. A small easy solution, as I mentioned >>>>>>>>>>> before, could be just to distinguish between "logging >>>>>>>>>>> parameters stable since startup" and "logging parameters >>>>>>>>>>> changed at some time". That way you would at least know >>>>>>>>>>> whether to trust the logging output. >>>>>>>>>>> >>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>> >>>>>>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 for >>>>>>>>>> this. >>>>>>>>>> >>>>>>>>>> Max: Did you see my comments about the ConfigurationLock? It >>>>>>>>>> was an inline reply to your first mail. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Max >>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>> Please review another Unified Logging change. >>>>>>>>>>>>>> They are >>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> bug: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>>>>>> which >>>>>>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>>>>>> error >>>>>>>>>>>> handler could potentially deadlock if its thread already >>>>>>>>>>>> holds >>>>>>>>>>>> the lock. Unsure how to resolve this, because skipping to >>>>>>>>>>>> take >>>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Marcus >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The logging configuration is now printed in each >>>>>>>>>>>>>> hs_err >>>>>>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>>> Logging info >>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, and >>>>>>>>>>>>>> before >>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>> >>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>> >>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>>>>> warning, error >>>>>>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>>>>>> timemillis >>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), tags >>>>>>>>>>>>>> (tg) >>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>>>>> classload, classloaderdata, classunload, classpath, >>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, itables, >>>>>>>>>>>>>> jni, >>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>>>>> preorder, >>>>>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>>>>> safepoint, >>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, >>>>>>>>>>>>>> start, >>>>>>>>>>>>>> startuptime, state, stats, stringdedup, stringtable, >>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From coleen.phillimore at oracle.com Mon Apr 18 13:33:35 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 18 Apr 2016 09:33:35 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5710FCAA.8080107@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57109E39.4000404@oracle.com> <5710FAE5.7090000@oracle.com> <5710FCAA.8080107@oracle.com> Message-ID: <5714E22F.3080403@oracle.com> On 4/15/16 10:37 AM, Marcus Larsson wrote: > Hi, > > On 04/15/2016 04:29 PM, Coleen Phillimore wrote: >> >> Max, >> >> I got this confused when looking at this because of the names. >> >> *+ STEP(395, "(printing log configuration)")* >> *+ if (_verbose){* >> *+ st->print_cr("Logging:");* >> *+ LogConfiguration::describe_no_lock(st);* >> *+ LogConfiguration::describe_with_lock(st);* >> *+ st->cr();* >> *+ }* >> *+ * >> >> I was thinking "wait, you don't want the lock here!" >> >> I think describe_no_lock() should be named >> describe_available_log_levels() >> >> describe_with_lock() should be names describe_log_configuration(). >> >> describe() should call these with the lock for the latter. > > In that case, can we make it describe_available() and > describe_outputs()? The first function doesn't only describe levels. describe_available() seems better. It seems that describe_outputs() isn't descriptive, why not describe_[current]_configuration(). Thanks, Coleen > > Thanks, > Marcus > >> >> Thanks, >> Coleen >> >> >> On 4/15/16 3:54 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/14/2016 06:22 PM, Max Ockner wrote: >>>> new webrev: >>>> http://cr.openjdk.java.net/~mockner/8151526.05/ >>> >>> logConfiguration.cpp: >>> unnecessary #include on line 39 >>> >>> logConfiguration.hpp: >>> typo in comment, 'ad' -> 'and' >>> >>> I don't need to see a new webrev for this. Thanks for fixing! >>> >>> Marcus >>> >>>> - new describe_* methods are now private >>>> - VMError is now a friend class in logConfiguration. >>>> >>>> Thanks, >>>> Max >>>> >>>> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>>>> Hello, >>>>>> I have made these changes. >>>>>> - refactored describe into a portion which uses locking and one >>>>>> that does not. >>>>>> - in the print_vm_info function in vmError.cpp, describe() is >>>>>> used, since this function is called while the program is running. >>>>>> - in the report function, the describe_no_lock and >>>>>> describe_with_lock functions are both used without taking a lock. >>>>>> If it doesnt crash, then fantastic. If it does crash, the error >>>>>> handler will skip this step anyway. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>>>> >>>>> I suggest making the new two functions private in >>>>> LogConfiguration, and friending VMError, instead of keeping them >>>>> public. That should reduce confusion about which describe-method >>>>> to use, and prevent misuse of the describe_with_lock in other places. >>>>> >>>>> Otherwise this looks good. >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>>>> Hey, >>>>>>> >>>>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>>>> Marcus, >>>>>>>> >>>>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>>>> configuration during a crash without lock and it crashes, the >>>>>>>> error handler will eat it up and start at the next step. It >>>>>>>> would be fun to write a locking mechanism, but this seems >>>>>>>> better to me. >>>>>>>> >>>>>>>> I will continue to call describe() from VM.info, but I will >>>>>>>> refactor the code in describe so that all of the information >>>>>>>> can be printed easily without taking a lock. For a crash, I'll >>>>>>>> use the refactored print functions to print all the necessary >>>>>>>> information without taking a lock. Even if the vm crashes >>>>>>>> during this step it is not such a bad thing because of the >>>>>>>> robust error handler. >>>>>>> >>>>>>> Alright, that sounds good! >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>>>> Hello again, >>>>>>>>>> >>>>>>>>>> I have looked into this and I see a possible workaround to >>>>>>>>>> the issue raised by Marcus: >>>>>>>>>> >>>>>>>>>> LogConfiguration::describe() takes the ConfigurationLock, >>>>>>>>>> which >>>>>>>>>> might be problematic for the error handler. I suppose the >>>>>>>>>> error >>>>>>>>>> handler could potentially deadlock if its thread already >>>>>>>>>> holds >>>>>>>>>> the lock. Unsure how to resolve this, because skipping to >>>>>>>>>> take >>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>> changing the configuration as we read it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> My proposed solution is this: >>>>>>>>>> >>>>>>>>>> If the ConfigurationLock is held by another thread during the >>>>>>>>>> crash, then I think we could print "Log configuration can not >>>>>>>>>> be accessed because ConfigurationLock is currently held by >>>>>>>>>> another thread" or something similar. If the >>>>>>>>>> ConfigurationLock can be taken by the current thread, then >>>>>>>>>> print the configuration. >>>>>>>>>> >>>>>>>>>> We can accomplish this as follows: >>>>>>>>>> >>>>>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe >>>>>>>>>> class extending ConfigurationLock. >>>>>>>>>> >>>>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>>>> private: >>>>>>>>>> bool _success; >>>>>>>>>> public: >>>>>>>>>> ConfigurationLockMaybe() { >>>>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>>>> } >>>>>>>>>> ~ConfigurationLock() { >>>>>>>>>> if(_success){_semaphore.signal();} >>>>>>>>>> } >>>>>>>>>> bool has_lock(){return _success;} >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> _semaphore is a static var in ConfigurationLock, so the same >>>>>>>>>> copy is accessed in child classes. >>>>>>>>>> >>>>>>>>>> Another method >>>>>>>>>> LogConfiguration::describe_on_crash(outputStream* out) can >>>>>>>>>> use ConfigurationLockMaybe to attempt to print the >>>>>>>>>> configuration. >>>>>>>>>> >>>>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>>>> LogConfiguration::describe_on_crash. >>>>>>>>> >>>>>>>>> Sounds good to me. >>>>>>>>> >>>>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>>>>> better suggestion. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>> >>>>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Do we really need a list of all tags and all >>>>>>>>>>>>>>>> decorators? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Just going by what we currently put in the hs_err >>>>>>>>>>>>>>> file, I think >>>>>>>>>>>>>>> this may be the first "Do we really need" we've ever >>>>>>>>>>>>>>> asked for >>>>>>>>>>>>>>> this type of change. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> All joking aside, I think it is a good idea to >>>>>>>>>>>>>>> direct users >>>>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also: I assume what you print is the Log state as >>>>>>>>>>>>>>>> it is at the >>>>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. >>>>>>>>>>>>>>>> with jcmd, >>>>>>>>>>>>>>>> would it be possible to see that? At least a >>>>>>>>>>>>>>>> warning if >>>>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>>>> require a >>>>>>>>>>>>>>> framework change. It does not look like any marks >>>>>>>>>>>>>>> are made when >>>>>>>>>>>>>>> the LogConfiguration changes during runtime, and we >>>>>>>>>>>>>>> would need >>>>>>>>>>>>>>> to record that in order to know what to print when >>>>>>>>>>>>>>> we dump into >>>>>>>>>>>>>>> hs_err. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, this would required the framework to keep some >>>>>>>>>>>>>> sort of log >>>>>>>>>>>>>> of configuration changes. Is there value in knowing >>>>>>>>>>>>>> that the log >>>>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>>>> >>>>>>>>>>>>> I think it is useful along with other information. An >>>>>>>>>>>>> example case: >>>>>>>>>>>>> >>>>>>>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>>>>>>> acquired or >>>>>>>>>>>>> released. In a subsystem like this, the action which >>>>>>>>>>>>> dooms the vm >>>>>>>>>>>>> may not cause an immediate crash. This leaves time for >>>>>>>>>>>>> logging to >>>>>>>>>>>>> turn on or off in between the bad action and the >>>>>>>>>>>>> crash. If you >>>>>>>>>>>>> don't know when logging was active and when it was >>>>>>>>>>>>> not, then the >>>>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>>>> information. You may not see the message that has the >>>>>>>>>>>>> answer for >>>>>>>>>>>>> you because it was not logged, though the action may >>>>>>>>>>>>> have occurred. >>>>>>>>>>>>> >>>>>>>>>>>>> However, if we don't have the framework support for >>>>>>>>>>>>> this then I >>>>>>>>>>>>> believe it should be added later. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This is a good example. A small easy solution, as I >>>>>>>>>>>>> mentioned before, could be just to distinguish between >>>>>>>>>>>>> "logging parameters stable since startup" and "logging >>>>>>>>>>>>> parameters changed at some time". That way you would at >>>>>>>>>>>>> least know whether to trust the logging output. >>>>>>>>>>>>> >>>>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>>>> >>>>>>>>>>>> I've filed https://bugs.openjdk.java.net/browse/JDK-8153945 >>>>>>>>>>>> for this. >>>>>>>>>>>> >>>>>>>>>>>> Max: Did you see my comments about the ConfigurationLock? >>>>>>>>>>>> It was an inline reply to your first mail. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Marcus >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>> Please review another Unified Logging change. >>>>>>>>>>>>>>>> They are >>>>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>>>>> the error >>>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>>> already holds >>>>>>>>>>>>>> the lock. Unsure how to resolve this, because >>>>>>>>>>>>>> skipping to take >>>>>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The logging configuration is now printed in >>>>>>>>>>>>>>>> each hs_err >>>>>>>>>>>>>>>> file. The output is the same as you would see from >>>>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>>>>> Logging info >>>>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, and >>>>>>>>>>>>>>>> before >>>>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>>>>>>> warning, error >>>>>>>>>>>>>>>> Available log decorators: time (t), uptime (u), >>>>>>>>>>>>>>>> timemillis >>>>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), >>>>>>>>>>>>>>>> tags (tg) >>>>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>>>>>>> classload, classloaderdata, classunload, >>>>>>>>>>>>>>>> classpath, >>>>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>>>>>>> preorder, >>>>>>>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>>>>>>> safepoint, >>>>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, >>>>>>>>>>>>>>>> start, >>>>>>>>>>>>>>>> startuptime, state, stats, stringdedup, >>>>>>>>>>>>>>>> stringtable, >>>>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From aph at redhat.com Mon Apr 18 13:41:42 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Apr 2016 14:41:42 +0100 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> Message-ID: <5714E416.6030300@redhat.com> On 04/18/2016 02:01 PM, Carsten Varming wrote: > An important question is: Should the shared parts of hotspot move towards > weaker memory models? If yes, then everybody should review code assuming > the weaker semantics. If no, then there really isn't room for patches like > this one :(. This would surely be useful. For example, the bitmap marking uses a two-way acquire and release barrier at the moment, and I'm fairly sure we don't need that. I don't think this change should be #ifdef PPC64. That disadvantages other targets such as AArch64, to no advantage. I understand that moving this to shared code requires more work, but we should do at least some of it in the JDK9 timeframe. C++11 has a considerably greater variety of atomic memory operators than the ones in HotSpot. Over time I believe we should migrate to C++11-like operators in our code base. One way to do this would be to create new operators which map in a simple way onto the standard ones. The we can get rid of much of this inline assembly code. Andrew. From marcus.larsson at oracle.com Mon Apr 18 13:43:53 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 18 Apr 2016 15:43:53 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5714E22F.3080403@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57109E39.4000404@oracle.com> <5710FAE5.7090000@oracle.com> <5710FCAA.8080107@oracle.com> <5714E22F.3080403@oracle.com> Message-ID: <5714E499.5070802@oracle.com> On 04/18/2016 03:33 PM, Coleen Phillimore wrote: > > > On 4/15/16 10:37 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/15/2016 04:29 PM, Coleen Phillimore wrote: >>> >>> Max, >>> >>> I got this confused when looking at this because of the names. >>> >>> *+ STEP(395, "(printing log configuration)")* >>> *+ if (_verbose){* >>> *+ st->print_cr("Logging:");* >>> *+ LogConfiguration::describe_no_lock(st);* >>> *+ LogConfiguration::describe_with_lock(st);* >>> *+ st->cr();* >>> *+ }* >>> *+ * >>> >>> I was thinking "wait, you don't want the lock here!" >>> >>> I think describe_no_lock() should be named >>> describe_available_log_levels() >>> >>> describe_with_lock() should be names describe_log_configuration(). >>> >>> describe() should call these with the lock for the latter. >> >> In that case, can we make it describe_available() and >> describe_outputs()? The first function doesn't only describe levels. > > describe_available() seems better. It seems that describe_outputs() > isn't descriptive, why not describe_[current]_configuration(). I just figured we could skip the "configuration" part of it since we're already in the scope of LogConfiguration::. I'm fine with describe_[current]_configuration(), it's no big deal. Thanks, Marcus > > Thanks, > Coleen >> >> Thanks, >> Marcus >> >>> >>> Thanks, >>> Coleen >>> >>> >>> On 4/15/16 3:54 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 04/14/2016 06:22 PM, Max Ockner wrote: >>>>> new webrev: >>>>> http://cr.openjdk.java.net/~mockner/8151526.05/ >>>> >>>> logConfiguration.cpp: >>>> unnecessary #include on line 39 >>>> >>>> logConfiguration.hpp: >>>> typo in comment, 'ad' -> 'and' >>>> >>>> I don't need to see a new webrev for this. Thanks for fixing! >>>> >>>> Marcus >>>> >>>>> - new describe_* methods are now private >>>>> - VMError is now a friend class in logConfiguration. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>>>>> Hello, >>>>>>> I have made these changes. >>>>>>> - refactored describe into a portion which uses locking and one >>>>>>> that does not. >>>>>>> - in the print_vm_info function in vmError.cpp, describe() is >>>>>>> used, since this function is called while the program is running. >>>>>>> - in the report function, the describe_no_lock and >>>>>>> describe_with_lock functions are both used without taking a >>>>>>> lock. If it doesnt crash, then fantastic. If it does crash, the >>>>>>> error handler will skip this step anyway. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>>>>> >>>>>> I suggest making the new two functions private in >>>>>> LogConfiguration, and friending VMError, instead of keeping them >>>>>> public. That should reduce confusion about which describe-method >>>>>> to use, and prevent misuse of the describe_with_lock in other >>>>>> places. >>>>>> >>>>>> Otherwise this looks good. >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>>>>> Hey, >>>>>>>> >>>>>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>>>>> Marcus, >>>>>>>>> >>>>>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>>>>> configuration during a crash without lock and it crashes, the >>>>>>>>> error handler will eat it up and start at the next step. It >>>>>>>>> would be fun to write a locking mechanism, but this seems >>>>>>>>> better to me. >>>>>>>>> >>>>>>>>> I will continue to call describe() from VM.info, but I will >>>>>>>>> refactor the code in describe so that all of the information >>>>>>>>> can be printed easily without taking a lock. For a crash, I'll >>>>>>>>> use the refactored print functions to print all the necessary >>>>>>>>> information without taking a lock. Even if the vm crashes >>>>>>>>> during this step it is not such a bad thing because of the >>>>>>>>> robust error handler. >>>>>>>> >>>>>>>> Alright, that sounds good! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>>>>> Hello again, >>>>>>>>>>> >>>>>>>>>>> I have looked into this and I see a possible workaround to >>>>>>>>>>> the issue raised by Marcus: >>>>>>>>>>> >>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>> the error >>>>>>>>>>> handler could potentially deadlock if its thread already >>>>>>>>>>> holds >>>>>>>>>>> the lock. Unsure how to resolve this, because skipping >>>>>>>>>>> to take >>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> My proposed solution is this: >>>>>>>>>>> >>>>>>>>>>> If the ConfigurationLock is held by another thread during >>>>>>>>>>> the crash, then I think we could print "Log configuration >>>>>>>>>>> can not be accessed because ConfigurationLock is currently >>>>>>>>>>> held by another thread" or something similar. If the >>>>>>>>>>> ConfigurationLock can be taken by the current thread, then >>>>>>>>>>> print the configuration. >>>>>>>>>>> >>>>>>>>>>> We can accomplish this as follows: >>>>>>>>>>> >>>>>>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe >>>>>>>>>>> class extending ConfigurationLock. >>>>>>>>>>> >>>>>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>>>>> private: >>>>>>>>>>> bool _success; >>>>>>>>>>> public: >>>>>>>>>>> ConfigurationLockMaybe() { >>>>>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>>>>> } >>>>>>>>>>> ~ConfigurationLock() { >>>>>>>>>>> if(_success){_semaphore.signal();} >>>>>>>>>>> } >>>>>>>>>>> bool has_lock(){return _success;} >>>>>>>>>>> }; >>>>>>>>>>> >>>>>>>>>>> _semaphore is a static var in ConfigurationLock, so the same >>>>>>>>>>> copy is accessed in child classes. >>>>>>>>>>> >>>>>>>>>>> Another method >>>>>>>>>>> LogConfiguration::describe_on_crash(outputStream* out) can >>>>>>>>>>> use ConfigurationLockMaybe to attempt to print the >>>>>>>>>>> configuration. >>>>>>>>>>> >>>>>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>>>>> LogConfiguration::describe_on_crash. >>>>>>>>>> >>>>>>>>>> Sounds good to me. >>>>>>>>>> >>>>>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>>>>>> better suggestion. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Do we really need a list of all tags and all >>>>>>>>>>>>>>>>> decorators? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Just going by what we currently put in the hs_err >>>>>>>>>>>>>>>> file, I think >>>>>>>>>>>>>>>> this may be the first "Do we really need" we've >>>>>>>>>>>>>>>> ever asked for >>>>>>>>>>>>>>>> this type of change. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All joking aside, I think it is a good idea to >>>>>>>>>>>>>>>> direct users >>>>>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also: I assume what you print is the Log state as >>>>>>>>>>>>>>>>> it is at the >>>>>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. >>>>>>>>>>>>>>>>> with jcmd, >>>>>>>>>>>>>>>>> would it be possible to see that? At least a >>>>>>>>>>>>>>>>> warning if >>>>>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>>>>> require a >>>>>>>>>>>>>>>> framework change. It does not look like any marks >>>>>>>>>>>>>>>> are made when >>>>>>>>>>>>>>>> the LogConfiguration changes during runtime, and we >>>>>>>>>>>>>>>> would need >>>>>>>>>>>>>>>> to record that in order to know what to print when >>>>>>>>>>>>>>>> we dump into >>>>>>>>>>>>>>>> hs_err. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, this would required the framework to keep some >>>>>>>>>>>>>>> sort of log >>>>>>>>>>>>>>> of configuration changes. Is there value in knowing >>>>>>>>>>>>>>> that the log >>>>>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think it is useful along with other information. An >>>>>>>>>>>>>> example case: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Let's say we are logging a message whenever a lock is >>>>>>>>>>>>>> acquired or >>>>>>>>>>>>>> released. In a subsystem like this, the action which >>>>>>>>>>>>>> dooms the vm >>>>>>>>>>>>>> may not cause an immediate crash. This leaves time >>>>>>>>>>>>>> for logging to >>>>>>>>>>>>>> turn on or off in between the bad action and the >>>>>>>>>>>>>> crash. If you >>>>>>>>>>>>>> don't know when logging was active and when it was >>>>>>>>>>>>>> not, then the >>>>>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>>>>> information. You may not see the message that has the >>>>>>>>>>>>>> answer for >>>>>>>>>>>>>> you because it was not logged, though the action may >>>>>>>>>>>>>> have occurred. >>>>>>>>>>>>>> >>>>>>>>>>>>>> However, if we don't have the framework support for >>>>>>>>>>>>>> this then I >>>>>>>>>>>>>> believe it should be added later. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a good example. A small easy solution, as I >>>>>>>>>>>>>> mentioned before, could be just to distinguish between >>>>>>>>>>>>>> "logging parameters stable since startup" and "logging >>>>>>>>>>>>>> parameters changed at some time". That way you would at >>>>>>>>>>>>>> least know whether to trust the logging output. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>>>>> >>>>>>>>>>>>> I've filed >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >>>>>>>>>>>>> >>>>>>>>>>>>> Max: Did you see my comments about the ConfigurationLock? >>>>>>>>>>>>> It was an inline reply to your first mail. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Marcus >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>> Please review another Unified Logging change. >>>>>>>>>>>>>>>>> They are >>>>>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>>>> might be problematic for the error handler. I >>>>>>>>>>>>>>> suppose the error >>>>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>>>> already holds >>>>>>>>>>>>>>> the lock. Unsure how to resolve this, because >>>>>>>>>>>>>>> skipping to take >>>>>>>>>>>>>>> the lock means that we might crash due to another >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The logging configuration is now printed in >>>>>>>>>>>>>>>>> each hs_err >>>>>>>>>>>>>>>>> file. The output is the same as you would see >>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>>>>>> Logging info >>>>>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, >>>>>>>>>>>>>>>>> and before >>>>>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>>>>> Available log levels: off, trace, debug, info, >>>>>>>>>>>>>>>>> warning, error >>>>>>>>>>>>>>>>> Available log decorators: time (t), uptime >>>>>>>>>>>>>>>>> (u), timemillis >>>>>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), >>>>>>>>>>>>>>>>> tags (tg) >>>>>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>>>>> bot, census, classhisto, classresolve, classinit, >>>>>>>>>>>>>>>>> classload, classloaderdata, classunload, >>>>>>>>>>>>>>>>> classpath, >>>>>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>>>>> monitorinflation, os, phases, plab, promotion, >>>>>>>>>>>>>>>>> preorder, >>>>>>>>>>>>>>>>> protectiondomain, ref, refine, region, remset, >>>>>>>>>>>>>>>>> safepoint, >>>>>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, stacktrace, >>>>>>>>>>>>>>>>> start, >>>>>>>>>>>>>>>>> startuptime, state, stats, stringdedup, >>>>>>>>>>>>>>>>> stringtable, >>>>>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>>>>> verboseverification, verify, vmoperation, vtables >>>>>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From kumar.x.srinivasan at oracle.com Mon Apr 18 14:23:54 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 18 Apr 2016 07:23:54 -0700 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57146544.9050903@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5712BAB9.5040400@oracle.com> <57130544.8000601@gmail.com> <571367B6.5020808@oracle.com> <57146544.9050903@oracle.com> Message-ID: <5714EDFA.7070803@oracle.com> Hi, Looks ok to me. Thanks Kumar > On 17/04/2016 8:38 PM, David Holmes wrote: >> On 17/04/2016 1:38 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> Need to hear from core-libs and/or launcher folk as this touches a >>>> number of pieces of code. >>> >>> I'm waiting more reviewer(s) . >>> >>> BTW, Should I make patches which are based on jdk9/dev repos? >>> My proposal includes hotspot changes. >>> So I want to know whether I can push all changes jdk9/dev/{jdk,hotspot} >>> after reviewing. >> >> No, jdk9/hs please. > > And it will need to go via JPRT so I will sponsor it for you. > > Thanks, > David > >> Thanks, >> David >> >>> I can update my webrev to adapt to jdk9/dev repos if need. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/17 7:20, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> On 16/04/2016 7:29 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> I uploaded new webrev: >>>>> >>>>> - hotspot: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>> >>>>> - jdk: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>> >>>> Ah sneaky! :) Using JNI to by-pass access control so we can set up a >>>> private method to do the name setting, yet avoid any API change that >>>> would require a CCC request. I think I like it. :) >>>> >>>> Need to hear from core-libs and/or launcher folk as this touches a >>>> number of pieces of code. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>>> it won't work unless you change the semantics of setName so I'm not >>>>>> sure what you were thinking here. To take advantage of an arg taking >>>>>> JVM_SetNativThreadName you would need to call it directly as no Java >>>>>> code will call it . ??? >>>>> >>>>> I added a flag for setting native thread name to JNI-attached thread. >>>>> This change can set native thread name if main thread changes to >>>>> JNI-attached thread. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/16 16:11, David Holmes wrote: >>>>>> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> That change in behaviour may be a problem, it could be >>>>>>>> considered a >>>>>>>> regression that setName stops setting the native thread main, even >>>>>>>> though we never really intended it to work in the first place. :( >>>>>>>> Such >>>>>>>> a change needs to go through CCC. >>>>>>> >>>>>>> I understood. >>>>>>> Can I send CCC request? >>>>>>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>>> >>>>>> Sorry you can't file a CCC request, you would need a sponsor for >>>>>> that. >>>>>> But at this stage I don't think I agree with the proposed change >>>>>> because of the change in behaviour - there's no way to restore the >>>>>> "broken" behaviour. >>>>>> >>>>>>> I want to continue to discuss about it on JDK-8154331 [1]. >>>>>> >>>>>> Okay we can do that. >>>>>> >>>>>>> >>>>>>>> Further, we expect the launcher to use the supported JNI interface >>>>>>>> (as >>>>>>>> other processes would), not the internal JVM interface that exists >>>>>>>> for >>>>>>>> the JDK sources to communicate with the JVM. >>>>>>> >>>>>>> I think that we do not use JVM interface if we add new method in >>>>>>> LauncherHelper as below: >>>>>>> ---------------- >>>>>>> diff -r f02139a1ac84 >>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>> @@ -960,4 +960,8 @@ >>>>>>> else >>>>>>> return md.toNameAndVersion() + " (" + loc + ")"; >>>>>>> } >>>>>>> + >>>>>>> + static void setNativeThreadName(String name) { >>>>>>> + Thread.currentThread().setName(name); >>>>>>> + } >>>>>> >>>>>> You could also make that call via JNI directly, so not sure the >>>>>> helper >>>>>> adds much here. But it won't work unless you change the semantics of >>>>>> setName so I'm not sure what you were thinking here. To take >>>>>> advantage >>>>>> of an arg taking JVM_SetNativThreadName you would need to call it >>>>>> directly as no Java code will call it . ??? >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> } >>>>>>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>>>>>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 >>>>>>> 14:19:30 >>>>>>> 2016 +0000 >>>>>>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 >>>>>>> 11:25:53 >>>>>>> 2016 +0900 >>>>>>> @@ -125,6 +125,7 @@ >>>>>>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>>>> static void ShowSettings(JNIEnv* env, char *optString); >>>>>>> static void ListModules(JNIEnv* env, char *optString); >>>>>>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>>>>> >>>>>>> static void SetPaths(int argc, char **argv); >>>>>>> >>>>>>> @@ -325,6 +326,7 @@ >>>>>>> * mainThread.isAlive() to work as expected. >>>>>>> */ >>>>>>> #define LEAVE() \ >>>>>>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>> do { \ >>>>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>> @@ -488,6 +490,9 @@ >>>>>>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>>>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>> >>>>>>> + /* Set native thread name. */ >>>>>>> + SetNativeThreadName(env, "main"); >>>>>>> + >>>>>>> /* Invoke main method. */ >>>>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>> mainArgs); >>>>>>> >>>>>>> @@ -1686,6 +1691,22 @@ >>>>>>> joptString); >>>>>>> } >>>>>>> >>>>>>> +/** >>>>>>> + * Set native thread name as possible. >>>>>>> + */ >>>>>>> +static void >>>>>>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>> +{ >>>>>>> + jmethodID setNativeThreadNameID; >>>>>>> + jstring nameString; >>>>>>> + jclass cls = GetLauncherHelperClass(env); >>>>>>> + NULL_CHECK(cls); >>>>>>> + NULL_CHECK(setNativeThreadNameID = >>>>>>> (*env)->GetStaticMethodID(env, cls, >>>>>>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>>>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>>>>>> nameString); >>>>>>> +} >>>>>>> + >>>>>>> /* >>>>>>> * Prints default usage or the Xusage message, see >>>>>>> sun.launcher.LauncherHelper.java >>>>>>> */ >>>>>>> ---------------- >>>>>>> >>>>>>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>>> >>>>>>>> However this is still a change to the exported JVM interface >>>>>>>> and so >>>>>>>> has to be approved. >>>>>>> >>>>>>> Do you mean that this change needs CCC? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> I think it is a bug based on the comment here: >>>>>>>>>> >>>>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>>>>>>> thread and >>>>>>>>>> JNI attached threads >>>>>>>>> >>>>>>>>> I filed it to JBS as JDK-8154331. >>>>>>>>> I will send review request to hotspot-runtime-dev. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Though that will introduce a change in behaviour by itself as >>>>>>>>>> setName >>>>>>>>>> will no longer set the native name for the main thread. >>>>>>>>> >>>>>>>>> I know. >>>>>>>> >>>>>>>> That change in behaviour may be a problem, it could be >>>>>>>> considered a >>>>>>>> regression that setName stops setting the native thread main, even >>>>>>>> though we never really intended it to work in the first place. :( >>>>>>>> Such >>>>>>>> a change needs to go through CCC. >>>>>>>> >>>>>>>>> I checked changeset history. >>>>>>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and >>>>>>>>> it is >>>>>>>>> backported JDK 8. >>>>>>>> >>>>>>>> Yes this all came in as part of the OSX port in 7u2. >>>>>>>> >>>>>>>>> However, this function seems to be called from >>>>>>>>> Thread#setNativeName() >>>>>>>>> only. >>>>>>>>> In addition, Thread#setNativeName() is private method. >>>>>>>>> >>>>>>>>> Thus I think that we can add an argument to >>>>>>>>> JVM_SetNativeThreadName() >>>>>>>>> for force setting. >>>>>>>>> (e.g. "bool forced") >>>>>>>>> >>>>>>>>> It makes a change of JVM API. >>>>>>>>> However, this function is NOT public, so I think we can add one >>>>>>>>> more >>>>>>>>> argument. >>>>>>>>> >>>>>>>>> What do you think about this? >>>>>>>>> If it is accepted, we can set native thread name from Java >>>>>>>>> launcher. >>>>>>>> >>>>>>>> The private/public aspect of the Java API is not really at issue. >>>>>>>> Yes >>>>>>>> we would add another arg to the JVM function to allow it to >>>>>>>> apply to >>>>>>>> JNI-attached threads as well (I'd prefer the arg reflect that not >>>>>>>> just >>>>>>>> "force"). However this is still a change to the exported JVM >>>>>>>> interface >>>>>>>> and so has to be approved. Further, we expect the launcher to use >>>>>>>> the >>>>>>>> supported JNI interface (as other processes would), not the >>>>>>>> internal >>>>>>>> JVM interface that exists for the JDK sources to communicate with >>>>>>>> the >>>>>>>> JVM. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>>> The fact that the "main" thread is not tagged as being a >>>>>>>>>>>> JNI-attached >>>>>>>>>>>> thread seems accidental to me >>>>>>>>>>> >>>>>>>>>>> Should I file it to JBS? >>>>>>>>>> >>>>>>>>>> I think it is a bug based on the comment here: >>>>>>>>>> >>>>>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>>>>>>> thread and >>>>>>>>>> JNI attached threads >>>>>>>>>> >>>>>>>>>> Though that will introduce a change in behaviour by itself as >>>>>>>>>> setName >>>>>>>>>> will no longer set the native name for the main thread. >>>>>>>>>> >>>>>>>>>>> I think that we can fix as below: >>>>>>>>>>> --------------- >>>>>>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 >>>>>>>>>>> 2016 >>>>>>>>>>> +0200 >>>>>>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 >>>>>>>>>>> 2016 >>>>>>>>>>> +0900 >>>>>>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>>> >>>>>>>>>>> // Attach the main thread to this os thread >>>>>>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>> // must do this before set_active_handles >>>>>>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>>> // Notify JVMTI agents that VM initialization is complete - >>>>>>>>>>> nop if >>>>>>>>>>> no agents. >>>>>>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>>> >>>>>>>>>>> + // Change attach status to "attached" >>>>>>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>>> + >>>>>>>>>> >>>>>>>>>> I think we can do this straight after the JavaThread >>>>>>>>>> constructor. >>>>>>>>>> >>>>>>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>>>>>>> backend."); >>>>>>>>>>> } >>>>>>>>>>> --------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> If it wants to name its native threads then it is free to >>>>>>>>>>>> do so, >>>>>>>>>>> >>>>>>>>>>> Currently, JVM_SetNativeThreadName() cannot change native >>>>>>>>>>> thread >>>>>>>>>>> name >>>>>>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>>>> However, I think that it should be changed if Java developer >>>>>>>>>>> calls >>>>>>>>>>> Thread#setName() explicitly. >>>>>>>>>>> It is not the same of changing native thread name at >>>>>>>>>>> Threads::create_vm(). >>>>>>>>>>> >>>>>>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>>>>>>> What do you think about this? >>>>>>>>>> >>>>>>>>>> The decision to not change the name of JNI-attached threads >>>>>>>>>> was a >>>>>>>>>> deliberate one** - this functionality originated with the OSX >>>>>>>>>> port >>>>>>>>>> and >>>>>>>>>> it was reported that the initial feedback with this feature >>>>>>>>>> was to >>>>>>>>>> ensure it didn't mess with thread names that had been set by the >>>>>>>>>> host >>>>>>>>>> process. If we do as you propose then we will just have an >>>>>>>>>> inconsistency for people to complain about: "why does my native >>>>>>>>>> thread >>>>>>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>>>>>>> >>>>>>>>>> ** If you follow the bugs and related discussions on this, the >>>>>>>>>> semantics and limitations (truncation, current thread only, >>>>>>>>>> non-JNI >>>>>>>>>> threads only) of setting the native thread name were supposed >>>>>>>>>> to be >>>>>>>>>> documented in the release notes - but as far as I can see that >>>>>>>>>> never >>>>>>>>>> happened. :( >>>>>>>>>> >>>>>>>>>> My position on this remains that if it is desirable for the main >>>>>>>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>>>>>>> launcher needs to be setting them using the available platform >>>>>>>>>> APIs. >>>>>>>>>> Unfortunately this is complicated - as evidenced by the VM code >>>>>>>>>> for >>>>>>>>>> this - due to the need to verify API availability. >>>>>>>>>> >>>>>>>>>> Any change in behaviour in relation to Thread.setName would have >>>>>>>>>> to go >>>>>>>>>> through our CCC process I think. But a change in the launcher >>>>>>>>>> would >>>>>>>>>> not. >>>>>>>>>> >>>>>>>>>> Sorry. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> --------------- >>>>>>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 >>>>>>>>>>> 2016 >>>>>>>>>>> +0200 >>>>>>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 >>>>>>>>>>> 2016 >>>>>>>>>>> +0900 >>>>>>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>>>>>>> // Thread naming only supported for the current thread, >>>>>>>>>>> doesn't >>>>>>>>>>> work >>>>>>>>>>> for >>>>>>>>>>> // target threads. >>>>>>>>>>> - if (Thread::current() == thr && >>>>>>>>>>> !thr->has_attached_via_jni()) { >>>>>>>>>>> + if (Thread::current() == thr) { >>>>>>>>>>> // we don't set the name of an attached thread to avoid >>>>>>>>>>> stepping >>>>>>>>>>> // on other programs >>>>>>>>>>> const char *thread_name = >>>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Roger, >>>>>>>>>>>>> Thanks for your comment! >>>>>>>>>>>>> >>>>>>>>>>>>> David, >>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't >>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>> >>>>>>>>>>>>> I tried to call Thread#setName() after initializing VM >>>>>>>>>>>>> (before >>>>>>>>>>>>> calling >>>>>>>>>>>>> main method), >>>>>>>>>>>>> I could set native thread name. >>>>>>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we >>>>>>>>>>>>> can't >>>>>>>>>>>>> set >>>>>>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>>> >>>>>>>>>>>> Right - I came to the same realization earlier this morning. >>>>>>>>>>>> Which, >>>>>>>>>>>> unfortunately, takes me back to the basic premise here that we >>>>>>>>>>>> don't >>>>>>>>>>>> set the name of threads not created by the JVM. The fact that >>>>>>>>>>>> the >>>>>>>>>>>> "main" thread is not tagged as being a JNI-attached thread >>>>>>>>>>>> seems >>>>>>>>>>>> accidental to me - so JVM_SetNativeThreadName is only >>>>>>>>>>>> working by >>>>>>>>>>>> accident for the initial attach, and can't be used for the >>>>>>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >>>>>>>>>>>> named at >>>>>>>>>>>> the native level. >>>>>>>>>>>> >>>>>>>>>>>> I'm afraid my view here is that the launcher has to be treated >>>>>>>>>>>> like >>>>>>>>>>>> any other process that might host a JVM. If it wants to >>>>>>>>>>>> name its >>>>>>>>>>>> native threads then it is free to do so, but I would not be >>>>>>>>>>>> exporting >>>>>>>>>>>> a function from the JVM to do that - it would have to use >>>>>>>>>>>> the OS >>>>>>>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>>>>>>> >>>>>>>>>>>> Sorry. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Comments: >>>>>>>>>>>>>> >>>>>>>>>>>>>> jvm.h: The function names are too similar but perform >>>>>>>>>>>>>> different >>>>>>>>>>>>>> functions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>>>>>>> >>>>>>>>>>>>>> - The first function applies to the current thread, the >>>>>>>>>>>>>> second >>>>>>>>>>>>>> one a >>>>>>>>>>>>>> specific java thread. >>>>>>>>>>>>>> It would seem useful for there to be a comment somewhere >>>>>>>>>>>>>> about >>>>>>>>>>>>>> what >>>>>>>>>>>>>> the new function does. >>>>>>>>>>>>>> >>>>>>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>>>>>>> instead of >>>>>>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>>>> used at >>>>>>>>>>>>>> line 730 >>>>>>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast >>>>>>>>>>>>>> on the >>>>>>>>>>>>>> same >>>>>>>>>>>>>> line as dlsym... >>>>>>>>>>>>>> >>>>>>>>>>>>>> $.02, Roger >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> That is an interesting question which I haven't had >>>>>>>>>>>>>>>> time to >>>>>>>>>>>>>>>> check - >>>>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>> public class Sleep{ >>>>>>>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't >>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I exported new JVM function to set native thread name, >>>>>>>>>>>>>>>>>>> and JLI >>>>>>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> First the launcher belongs to another team so core-libs >>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>>>>> review and approve this (in particular Kumar) - now >>>>>>>>>>>>>>>>>> cc'd. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>>>>>>>>>>>>>>> Thread.setName >>>>>>>>>>>>>>>>>> rather >>>>>>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot >>>>>>>>>>>>>>>>>> changes >>>>>>>>>>>>>>>>>> needed in >>>>>>>>>>>>>>>>>> that case. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>>>>>>>>>>>> Thread#setName() in >>>>>>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> At Thread.init time the thread is not alive, which is why >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> name is not set. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That is an interesting question which I haven't had >>>>>>>>>>>>>>>> time to >>>>>>>>>>>>>>>> check - >>>>>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't >>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thus I think that we have to provide a function to set >>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>> thread name. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we >>>>>>>>>>>>>>>>>>>> do not >>>>>>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> Thu >>>>>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>>>>> Thu >>>>>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread(); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>>>>>>>>>>>>>>>>>> set_active_handles >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread >>>>>>>>>>>>>>>>>>>>>>>>>> name in >>>>>>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, >>>>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already >>>>>>>>>>>>>>>>>>>>>>>>>> starte >>>>>>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad >>>>>>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something >>>>>>>>>>>>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue >>>>>>>>>>>>>>>>>>>>>>>>>> Mar 29 >>>>>>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed >>>>>>>>>>>>>>>>>>>>>>>>>> Mar 30 >>>>>>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = >>>>>>>>>>>>>>>>>>>>>>>>>> "main"; >>>>>>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>>>>> thread); >>>>>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' >>>>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and >>>>>>>>>>>>>>>>>>>>>>>>>> thus >>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is >>>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>>> So I >>>>>>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, >>>>>>>>>>>>>>>>>>>>>>>>>> since we >>>>>>>>>>>>>>>>>>>>>>>>>> want >>>>>>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might >>>>>>>>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java >>>>>>>>>>>>>>>>>>>>>>>>>> Main >>>>>>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java >>>>>>>>>>>>>>>>>>>>>>>>>> launcher - >>>>>>>>>>>>>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I >>>>>>>>>>>>>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name >>>>>>>>>>>>>>>>>>>>>>>>>> via >>>>>>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and >>>>>>>>>>>>>>>>>>>>>>>>>> main >>>>>>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should >>>>>>>>>>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review >>>>>>>>>>>>>>>>>>>>>>>>>> it? >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> From gerard.ziemski at oracle.com Mon Apr 18 14:53:35 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 18 Apr 2016 09:53:35 -0500 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. In-Reply-To: References: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> <077a096cb4dd406997636081fd939f92@DEWDFE13DE09.global.corp.sap> <932CC317-7EEB-49A2-A74F-6371E137F4A6@oracle.com> Message-ID: <1E4DB6BB-7950-4F26-B074-1CDCA8623D43@oracle.com> Thank you for the review Goetz! Can I have a second review for this simple fix please? In this fix we set the max range value to max_jlong (and change the type to uint64_t) since it gets assigned to MaxDirectMemorySize property that is later parsed as ?java long? (in java.base/VM.java:290) https://bugs.openjdk.java.net/browse/JDK-8153835 http://cr.openjdk.java.net/~gziemski/8153835_rev1/ Passes JPRT hotspot and RBT hotspot/test/runtime/CommandLine/OptionsValidation cheers From max.ockner at oracle.com Mon Apr 18 15:24:15 2016 From: max.ockner at oracle.com (Max Ockner) Date: Mon, 18 Apr 2016 11:24:15 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5714E499.5070802@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57109E39.4000404@oracle.com> <5710FAE5.7090000@oracle.com> <5710FCAA.8080107@oracle.com> <5714E22F.3080403@oracle.com> <5714E499.5070802@oracle.com> Message-ID: <5714FC1F.3080504@oracle.com> http://cr.openjdk.java.net/~mockner/8151526.06/ - Renamed describe_no_lock => describe_available - Renamed describe_with_lock => describe_current_configuration - Removed unnecessary import of vmError in logConfiguration.cpp - Fixed typo in comment in logConfiguration.hpp - hs_err file now only uses describe_current_configuration, which was the original intent of this enhancement. VM info still uses describe(). Thanks, Max On 4/18/2016 9:43 AM, Marcus Larsson wrote: > > > On 04/18/2016 03:33 PM, Coleen Phillimore wrote: >> >> >> On 4/15/16 10:37 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/15/2016 04:29 PM, Coleen Phillimore wrote: >>>> >>>> Max, >>>> >>>> I got this confused when looking at this because of the names. >>>> >>>> *+ STEP(395, "(printing log configuration)")* >>>> *+ if (_verbose){* >>>> *+ st->print_cr("Logging:");* >>>> *+ LogConfiguration::describe_no_lock(st);* >>>> *+ LogConfiguration::describe_with_lock(st);* >>>> *+ st->cr();* >>>> *+ }* >>>> *+ * >>>> >>>> I was thinking "wait, you don't want the lock here!" >>>> >>>> I think describe_no_lock() should be named >>>> describe_available_log_levels() >>>> >>>> describe_with_lock() should be names describe_log_configuration(). >>>> >>>> describe() should call these with the lock for the latter. >>> >>> In that case, can we make it describe_available() and >>> describe_outputs()? The first function doesn't only describe levels. >> >> describe_available() seems better. It seems that describe_outputs() >> isn't descriptive, why not describe_[current]_configuration(). > > I just figured we could skip the "configuration" part of it since > we're already in the scope of LogConfiguration::. I'm fine with > describe_[current]_configuration(), it's no big deal. > > Thanks, > Marcus > >> >> Thanks, >> Coleen >>> >>> Thanks, >>> Marcus >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> On 4/15/16 3:54 AM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> On 04/14/2016 06:22 PM, Max Ockner wrote: >>>>>> new webrev: >>>>>> http://cr.openjdk.java.net/~mockner/8151526.05/ >>>>> >>>>> logConfiguration.cpp: >>>>> unnecessary #include on line 39 >>>>> >>>>> logConfiguration.hpp: >>>>> typo in comment, 'ad' -> 'and' >>>>> >>>>> I don't need to see a new webrev for this. Thanks for fixing! >>>>> >>>>> Marcus >>>>> >>>>>> - new describe_* methods are now private >>>>>> - VMError is now a friend class in logConfiguration. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>>>>>> Hello, >>>>>>>> I have made these changes. >>>>>>>> - refactored describe into a portion which uses locking and >>>>>>>> one that does not. >>>>>>>> - in the print_vm_info function in vmError.cpp, describe() is >>>>>>>> used, since this function is called while the program is running. >>>>>>>> - in the report function, the describe_no_lock and >>>>>>>> describe_with_lock functions are both used without taking a >>>>>>>> lock. If it doesnt crash, then fantastic. If it does crash, the >>>>>>>> error handler will skip this step anyway. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>>>>>> >>>>>>> I suggest making the new two functions private in >>>>>>> LogConfiguration, and friending VMError, instead of keeping them >>>>>>> public. That should reduce confusion about which describe-method >>>>>>> to use, and prevent misuse of the describe_with_lock in other >>>>>>> places. >>>>>>> >>>>>>> Otherwise this looks good. >>>>>>> >>>>>>> Thanks, >>>>>>> Marcus >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>>>>>> Hey, >>>>>>>>> >>>>>>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>>>>>> Marcus, >>>>>>>>>> >>>>>>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>>>>>> configuration during a crash without lock and it crashes, the >>>>>>>>>> error handler will eat it up and start at the next step. It >>>>>>>>>> would be fun to write a locking mechanism, but this seems >>>>>>>>>> better to me. >>>>>>>>>> >>>>>>>>>> I will continue to call describe() from VM.info, but I will >>>>>>>>>> refactor the code in describe so that all of the information >>>>>>>>>> can be printed easily without taking a lock. For a crash, >>>>>>>>>> I'll use the refactored print functions to print all the >>>>>>>>>> necessary information without taking a lock. Even if the vm >>>>>>>>>> crashes during this step it is not such a bad thing because >>>>>>>>>> of the robust error handler. >>>>>>>>> >>>>>>>>> Alright, that sounds good! >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Marcus >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>>>>>> Hello again, >>>>>>>>>>>> >>>>>>>>>>>> I have looked into this and I see a possible workaround to >>>>>>>>>>>> the issue raised by Marcus: >>>>>>>>>>>> >>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>>> the error >>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>> already holds >>>>>>>>>>>> the lock. Unsure how to resolve this, because skipping >>>>>>>>>>>> to take >>>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> My proposed solution is this: >>>>>>>>>>>> >>>>>>>>>>>> If the ConfigurationLock is held by another thread during >>>>>>>>>>>> the crash, then I think we could print "Log configuration >>>>>>>>>>>> can not be accessed because ConfigurationLock is currently >>>>>>>>>>>> held by another thread" or something similar. If the >>>>>>>>>>>> ConfigurationLock can be taken by the current thread, then >>>>>>>>>>>> print the configuration. >>>>>>>>>>>> >>>>>>>>>>>> We can accomplish this as follows: >>>>>>>>>>>> >>>>>>>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe >>>>>>>>>>>> class extending ConfigurationLock. >>>>>>>>>>>> >>>>>>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>>>>>> private: >>>>>>>>>>>> bool _success; >>>>>>>>>>>> public: >>>>>>>>>>>> ConfigurationLockMaybe() { >>>>>>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>>>>>> } >>>>>>>>>>>> ~ConfigurationLock() { >>>>>>>>>>>> if(_success){_semaphore.signal();} >>>>>>>>>>>> } >>>>>>>>>>>> bool has_lock(){return _success;} >>>>>>>>>>>> }; >>>>>>>>>>>> >>>>>>>>>>>> _semaphore is a static var in ConfigurationLock, so the >>>>>>>>>>>> same copy is accessed in child classes. >>>>>>>>>>>> >>>>>>>>>>>> Another method >>>>>>>>>>>> LogConfiguration::describe_on_crash(outputStream* out) can >>>>>>>>>>>> use ConfigurationLockMaybe to attempt to print the >>>>>>>>>>>> configuration. >>>>>>>>>>>> >>>>>>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>>>>>> LogConfiguration::describe_on_crash. >>>>>>>>>>> >>>>>>>>>>> Sounds good to me. >>>>>>>>>>> >>>>>>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>>>>>>> better suggestion. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Marcus >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Do we really need a list of all tags and all >>>>>>>>>>>>>>>>>> decorators? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Just going by what we currently put in the hs_err >>>>>>>>>>>>>>>>> file, I think >>>>>>>>>>>>>>>>> this may be the first "Do we really need" we've >>>>>>>>>>>>>>>>> ever asked for >>>>>>>>>>>>>>>>> this type of change. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> All joking aside, I think it is a good idea to >>>>>>>>>>>>>>>>> direct users >>>>>>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Also: I assume what you print is the Log state as >>>>>>>>>>>>>>>>>> it is at the >>>>>>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. >>>>>>>>>>>>>>>>>> with jcmd, >>>>>>>>>>>>>>>>>> would it be possible to see that? At least a >>>>>>>>>>>>>>>>>> warning if >>>>>>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>>>>>> require a >>>>>>>>>>>>>>>>> framework change. It does not look like any marks >>>>>>>>>>>>>>>>> are made when >>>>>>>>>>>>>>>>> the LogConfiguration changes during runtime, and >>>>>>>>>>>>>>>>> we would need >>>>>>>>>>>>>>>>> to record that in order to know what to print when >>>>>>>>>>>>>>>>> we dump into >>>>>>>>>>>>>>>>> hs_err. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yes, this would required the framework to keep some >>>>>>>>>>>>>>>> sort of log >>>>>>>>>>>>>>>> of configuration changes. Is there value in knowing >>>>>>>>>>>>>>>> that the log >>>>>>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think it is useful along with other information. >>>>>>>>>>>>>>> An example case: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Let's say we are logging a message whenever a lock >>>>>>>>>>>>>>> is acquired or >>>>>>>>>>>>>>> released. In a subsystem like this, the action which >>>>>>>>>>>>>>> dooms the vm >>>>>>>>>>>>>>> may not cause an immediate crash. This leaves time >>>>>>>>>>>>>>> for logging to >>>>>>>>>>>>>>> turn on or off in between the bad action and the >>>>>>>>>>>>>>> crash. If you >>>>>>>>>>>>>>> don't know when logging was active and when it was >>>>>>>>>>>>>>> not, then the >>>>>>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>>>>>> information. You may not see the message that has >>>>>>>>>>>>>>> the answer for >>>>>>>>>>>>>>> you because it was not logged, though the action may >>>>>>>>>>>>>>> have occurred. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, if we don't have the framework support for >>>>>>>>>>>>>>> this then I >>>>>>>>>>>>>>> believe it should be added later. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This is a good example. A small easy solution, as I >>>>>>>>>>>>>>> mentioned before, could be just to distinguish between >>>>>>>>>>>>>>> "logging parameters stable since startup" and "logging >>>>>>>>>>>>>>> parameters changed at some time". That way you would at >>>>>>>>>>>>>>> least know whether to trust the logging output. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've filed >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Max: Did you see my comments about the ConfigurationLock? >>>>>>>>>>>>>> It was an inline reply to your first mail. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>> Please review another Unified Logging change. >>>>>>>>>>>>>>>>>> They are >>>>>>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>>>>> might be problematic for the error handler. I >>>>>>>>>>>>>>>> suppose the error >>>>>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>>>>> already holds >>>>>>>>>>>>>>>> the lock. Unsure how to resolve this, because >>>>>>>>>>>>>>>> skipping to take >>>>>>>>>>>>>>>> the lock means that we might crash due to another >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The logging configuration is now printed in >>>>>>>>>>>>>>>>>> each hs_err >>>>>>>>>>>>>>>>>> file. The output is the same as you would see >>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>>>>>>> Logging info >>>>>>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, >>>>>>>>>>>>>>>>>> and before >>>>>>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>>>>>> Available log levels: off, trace, debug, >>>>>>>>>>>>>>>>>> info, warning, error >>>>>>>>>>>>>>>>>> Available log decorators: time (t), uptime >>>>>>>>>>>>>>>>>> (u), timemillis >>>>>>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), >>>>>>>>>>>>>>>>>> tags (tg) >>>>>>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>>>>>> bot, census, classhisto, classresolve, >>>>>>>>>>>>>>>>>> classinit, >>>>>>>>>>>>>>>>>> classload, classloaderdata, classunload, >>>>>>>>>>>>>>>>>> classpath, >>>>>>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>>>>>> monitorinflation, os, phases, plab, >>>>>>>>>>>>>>>>>> promotion, preorder, >>>>>>>>>>>>>>>>>> protectiondomain, ref, refine, region, >>>>>>>>>>>>>>>>>> remset, safepoint, >>>>>>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, >>>>>>>>>>>>>>>>>> stacktrace, start, >>>>>>>>>>>>>>>>>> startuptime, state, stats, stringdedup, >>>>>>>>>>>>>>>>>> stringtable, >>>>>>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>>>>>> verboseverification, verify, vmoperation, >>>>>>>>>>>>>>>>>> vtables >>>>>>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Mon Apr 18 15:40:33 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 18 Apr 2016 11:40:33 -0400 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5714FC1F.3080504@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57109E39.4000404@oracle.com> <5710FAE5.7090000@oracle.com> <5710FCAA.8080107@oracle.com> <5714E22F.3080403@oracle.com> <5714E499.5070802@oracle.com> <5714FC1F.3080504@oracle.com> Message-ID: <5714FFF1.9010806@oracle.com> I think this looks perfect. Thanks! Coleen On 4/18/16 11:24 AM, Max Ockner wrote: > http://cr.openjdk.java.net/~mockner/8151526.06/ > > - Renamed describe_no_lock => describe_available > - Renamed describe_with_lock => describe_current_configuration > - Removed unnecessary import of vmError in logConfiguration.cpp > - Fixed typo in comment in logConfiguration.hpp > - hs_err file now only uses describe_current_configuration, which was > the original intent of this enhancement. VM info still uses describe(). > > Thanks, > Max > > On 4/18/2016 9:43 AM, Marcus Larsson wrote: >> >> >> On 04/18/2016 03:33 PM, Coleen Phillimore wrote: >>> >>> >>> On 4/15/16 10:37 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 04/15/2016 04:29 PM, Coleen Phillimore wrote: >>>>> >>>>> Max, >>>>> >>>>> I got this confused when looking at this because of the names. >>>>> >>>>> *+ STEP(395, "(printing log configuration)")* >>>>> *+ if (_verbose){* >>>>> *+ st->print_cr("Logging:");* >>>>> *+ LogConfiguration::describe_no_lock(st);* >>>>> *+ LogConfiguration::describe_with_lock(st);* >>>>> *+ st->cr();* >>>>> *+ }* >>>>> *+ * >>>>> >>>>> I was thinking "wait, you don't want the lock here!" >>>>> >>>>> I think describe_no_lock() should be named >>>>> describe_available_log_levels() >>>>> >>>>> describe_with_lock() should be names describe_log_configuration(). >>>>> >>>>> describe() should call these with the lock for the latter. >>>> >>>> In that case, can we make it describe_available() and >>>> describe_outputs()? The first function doesn't only describe levels. >>> >>> describe_available() seems better. It seems that >>> describe_outputs() isn't descriptive, why not >>> describe_[current]_configuration(). >> >> I just figured we could skip the "configuration" part of it since >> we're already in the scope of LogConfiguration::. I'm fine with >> describe_[current]_configuration(), it's no big deal. >> >> Thanks, >> Marcus >> >>> >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> On 4/15/16 3:54 AM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 04/14/2016 06:22 PM, Max Ockner wrote: >>>>>>> new webrev: >>>>>>> http://cr.openjdk.java.net/~mockner/8151526.05/ >>>>>> >>>>>> logConfiguration.cpp: >>>>>> unnecessary #include on line 39 >>>>>> >>>>>> logConfiguration.hpp: >>>>>> typo in comment, 'ad' -> 'and' >>>>>> >>>>>> I don't need to see a new webrev for this. Thanks for fixing! >>>>>> >>>>>> Marcus >>>>>> >>>>>>> - new describe_* methods are now private >>>>>>> - VMError is now a friend class in logConfiguration. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>>>>>>> Hello, >>>>>>>>> I have made these changes. >>>>>>>>> - refactored describe into a portion which uses locking and >>>>>>>>> one that does not. >>>>>>>>> - in the print_vm_info function in vmError.cpp, describe() is >>>>>>>>> used, since this function is called while the program is running. >>>>>>>>> - in the report function, the describe_no_lock and >>>>>>>>> describe_with_lock functions are both used without taking a >>>>>>>>> lock. If it doesnt crash, then fantastic. If it does crash, >>>>>>>>> the error handler will skip this step anyway. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>>>>>>> >>>>>>>> I suggest making the new two functions private in >>>>>>>> LogConfiguration, and friending VMError, instead of keeping >>>>>>>> them public. That should reduce confusion about which >>>>>>>> describe-method to use, and prevent misuse of the >>>>>>>> describe_with_lock in other places. >>>>>>>> >>>>>>>> Otherwise this looks good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>>>>>>> Hey, >>>>>>>>>> >>>>>>>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>>>>>>> Marcus, >>>>>>>>>>> >>>>>>>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>>>>>>> configuration during a crash without lock and it crashes, >>>>>>>>>>> the error handler will eat it up and start at the next >>>>>>>>>>> step. It would be fun to write a locking mechanism, but >>>>>>>>>>> this seems better to me. >>>>>>>>>>> >>>>>>>>>>> I will continue to call describe() from VM.info, but I will >>>>>>>>>>> refactor the code in describe so that all of the information >>>>>>>>>>> can be printed easily without taking a lock. For a crash, >>>>>>>>>>> I'll use the refactored print functions to print all the >>>>>>>>>>> necessary information without taking a lock. Even if the vm >>>>>>>>>>> crashes during this step it is not such a bad thing because >>>>>>>>>>> of the robust error handler. >>>>>>>>>> >>>>>>>>>> Alright, that sounds good! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>>>>>>> Hello again, >>>>>>>>>>>>> >>>>>>>>>>>>> I have looked into this and I see a possible workaround to >>>>>>>>>>>>> the issue raised by Marcus: >>>>>>>>>>>>> >>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>>>> the error >>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>> already holds >>>>>>>>>>>>> the lock. Unsure how to resolve this, because skipping >>>>>>>>>>>>> to take >>>>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> My proposed solution is this: >>>>>>>>>>>>> >>>>>>>>>>>>> If the ConfigurationLock is held by another thread during >>>>>>>>>>>>> the crash, then I think we could print "Log configuration >>>>>>>>>>>>> can not be accessed because ConfigurationLock is currently >>>>>>>>>>>>> held by another thread" or something similar. If the >>>>>>>>>>>>> ConfigurationLock can be taken by the current thread, then >>>>>>>>>>>>> print the configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> We can accomplish this as follows: >>>>>>>>>>>>> >>>>>>>>>>>>> In *logConfiguration.cpp*: Create a >>>>>>>>>>>>> ConfigurationLockMaybe class extending ConfigurationLock. >>>>>>>>>>>>> >>>>>>>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>>>>>>> private: >>>>>>>>>>>>> bool _success; >>>>>>>>>>>>> public: >>>>>>>>>>>>> ConfigurationLockMaybe() { >>>>>>>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>>>>>>> } >>>>>>>>>>>>> ~ConfigurationLock() { >>>>>>>>>>>>> if(_success){_semaphore.signal();} >>>>>>>>>>>>> } >>>>>>>>>>>>> bool has_lock(){return _success;} >>>>>>>>>>>>> }; >>>>>>>>>>>>> >>>>>>>>>>>>> _semaphore is a static var in ConfigurationLock, so the >>>>>>>>>>>>> same copy is accessed in child classes. >>>>>>>>>>>>> >>>>>>>>>>>>> Another method >>>>>>>>>>>>> LogConfiguration::describe_on_crash(outputStream* out) can >>>>>>>>>>>>> use ConfigurationLockMaybe to attempt to print the >>>>>>>>>>>>> configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>>>>>>> LogConfiguration::describe_on_crash. >>>>>>>>>>>> >>>>>>>>>>>> Sounds good to me. >>>>>>>>>>>> >>>>>>>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have >>>>>>>>>>>> a better suggestion. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Marcus >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Do we really need a list of all tags and all >>>>>>>>>>>>>>>>>>> decorators? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Just going by what we currently put in the hs_err >>>>>>>>>>>>>>>>>> file, I think >>>>>>>>>>>>>>>>>> this may be the first "Do we really need" we've >>>>>>>>>>>>>>>>>> ever asked for >>>>>>>>>>>>>>>>>> this type of change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> All joking aside, I think it is a good idea to >>>>>>>>>>>>>>>>>> direct users >>>>>>>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also: I assume what you print is the Log state as it >>>>>>>>>>>>>>>>>>> is at the >>>>>>>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. >>>>>>>>>>>>>>>>>>> with jcmd, >>>>>>>>>>>>>>>>>>> would it be possible to see that? At least a >>>>>>>>>>>>>>>>>>> warning if >>>>>>>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>>>>>>> require a >>>>>>>>>>>>>>>>>> framework change. It does not look like any marks >>>>>>>>>>>>>>>>>> are made when >>>>>>>>>>>>>>>>>> the LogConfiguration changes during runtime, and >>>>>>>>>>>>>>>>>> we would need >>>>>>>>>>>>>>>>>> to record that in order to know what to print >>>>>>>>>>>>>>>>>> when we dump into >>>>>>>>>>>>>>>>>> hs_err. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, this would required the framework to keep >>>>>>>>>>>>>>>>> some sort of log >>>>>>>>>>>>>>>>> of configuration changes. Is there value in >>>>>>>>>>>>>>>>> knowing that the log >>>>>>>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think it is useful along with other information. >>>>>>>>>>>>>>>> An example case: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Let's say we are logging a message whenever a lock >>>>>>>>>>>>>>>> is acquired or >>>>>>>>>>>>>>>> released. In a subsystem like this, the action >>>>>>>>>>>>>>>> which dooms the vm >>>>>>>>>>>>>>>> may not cause an immediate crash. This leaves time >>>>>>>>>>>>>>>> for logging to >>>>>>>>>>>>>>>> turn on or off in between the bad action and the >>>>>>>>>>>>>>>> crash. If you >>>>>>>>>>>>>>>> don't know when logging was active and when it was >>>>>>>>>>>>>>>> not, then the >>>>>>>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>>>>>>> information. You may not see the message that has >>>>>>>>>>>>>>>> the answer for >>>>>>>>>>>>>>>> you because it was not logged, though the action >>>>>>>>>>>>>>>> may have occurred. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, if we don't have the framework support for >>>>>>>>>>>>>>>> this then I >>>>>>>>>>>>>>>> believe it should be added later. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is a good example. A small easy solution, as I >>>>>>>>>>>>>>>> mentioned before, could be just to distinguish between >>>>>>>>>>>>>>>> "logging parameters stable since startup" and "logging >>>>>>>>>>>>>>>> parameters changed at some time". That way you would at >>>>>>>>>>>>>>>> least know whether to trust the logging output. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've filed >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Max: Did you see my comments about the >>>>>>>>>>>>>>> ConfigurationLock? It was an inline reply to your first >>>>>>>>>>>>>>> mail. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> Please review another Unified Logging >>>>>>>>>>>>>>>>>>> change. They are >>>>>>>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>>>>>> might be problematic for the error handler. I >>>>>>>>>>>>>>>>> suppose the error >>>>>>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>>>>>> already holds >>>>>>>>>>>>>>>>> the lock. Unsure how to resolve this, because >>>>>>>>>>>>>>>>> skipping to take >>>>>>>>>>>>>>>>> the lock means that we might crash due to another >>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The logging configuration is now printed in >>>>>>>>>>>>>>>>>>> each hs_err >>>>>>>>>>>>>>>>>>> file. The output is the same as you would >>>>>>>>>>>>>>>>>>> see from >>>>>>>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Below is a sample of the hs_err contents. >>>>>>>>>>>>>>>>>>> The Logging info >>>>>>>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, >>>>>>>>>>>>>>>>>>> and before >>>>>>>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>>>>>>> Available log levels: off, trace, debug, >>>>>>>>>>>>>>>>>>> info, warning, error >>>>>>>>>>>>>>>>>>> Available log decorators: time (t), uptime >>>>>>>>>>>>>>>>>>> (u), timemillis >>>>>>>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), >>>>>>>>>>>>>>>>>>> tags (tg) >>>>>>>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>>>>>>> bot, census, classhisto, classresolve, >>>>>>>>>>>>>>>>>>> classinit, >>>>>>>>>>>>>>>>>>> classload, classloaderdata, classunload, >>>>>>>>>>>>>>>>>>> classpath, >>>>>>>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>>>>>>> monitorinflation, os, phases, plab, >>>>>>>>>>>>>>>>>>> promotion, preorder, >>>>>>>>>>>>>>>>>>> protectiondomain, ref, refine, region, >>>>>>>>>>>>>>>>>>> remset, safepoint, >>>>>>>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, >>>>>>>>>>>>>>>>>>> stacktrace, start, >>>>>>>>>>>>>>>>>>> startuptime, state, stats, stringdedup, >>>>>>>>>>>>>>>>>>> stringtable, >>>>>>>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>>>>>>> verboseverification, verify, vmoperation, >>>>>>>>>>>>>>>>>>> vtables >>>>>>>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From volker.simonis at gmail.com Mon Apr 18 16:23:25 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Apr 2016 18:23:25 +0200 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <5714E416.6030300@redhat.com> References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> <5714E416.6030300@redhat.com> Message-ID: We've looked at the proposed changes and we are pretty sure that the cmpxchg done during copy_to_survivor_space in the parallel GC doesn't require the full fence/acquire semantics. But we also agree that this should not be ifdefed PPC64 in shared code. Andrews suggestion of using the new C++11 atomic memory operators is good, although in practice it may be hard to get all the different compilers under the hood. But now that we've even got the corresponding cmpxchg routines with various acquire/release semantics in Java-land in the new jdk.internal.Unsafe package, it would be a pity if it would not be possible to use that functionality within the Hotspot. I think one approach to enable an easy transition would be to do the proposed enhancements (or something similar) to cmpxchg unconditionally in atomic.hpp. For example instead of two extra boolean parameters we could use an enum similar to the one in library_call.cpp: typedef enum { Relaxed, Opaque, Volatile, Acquire, Release } AccessKind; The default value of this parameter should of course be conservative (i.e. Volatile) so we don't change the current behavior. After that individual, performance critical callers of these routines can be examined if they really require the most conservative setting and maybe optimized. What do you think? Regards, Martin and Volker On Mon, Apr 18, 2016 at 3:41 PM, Andrew Haley wrote: > On 04/18/2016 02:01 PM, Carsten Varming wrote: >> An important question is: Should the shared parts of hotspot move towards >> weaker memory models? If yes, then everybody should review code assuming >> the weaker semantics. If no, then there really isn't room for patches like >> this one :(. > > This would surely be useful. For example, the bitmap marking uses a > two-way acquire and release barrier at the moment, and I'm fairly sure > we don't need that. > > I don't think this change should be #ifdef PPC64. That disadvantages > other targets such as AArch64, to no advantage. I understand that > moving this to shared code requires more work, but we should do at > least some of it in the JDK9 timeframe. > > C++11 has a considerably greater variety of atomic memory operators > than the ones in HotSpot. Over time I believe we should migrate to > C++11-like operators in our code base. One way to do this would be to > create new operators which map in a simple way onto the standard ones. > The we can get rid of much of this inline assembly code. > > Andrew. From aph at redhat.com Mon Apr 18 16:45:00 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Apr 2016 17:45:00 +0100 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> <5714E416.6030300@redhat.com> Message-ID: <57150F0C.4060906@redhat.com> On 04/18/2016 05:23 PM, Volker Simonis wrote: > We've looked at the proposed changes and we are pretty sure that the > cmpxchg done during copy_to_survivor_space in the parallel GC doesn't > require the full fence/acquire semantics. But we also agree that this > should not be ifdefed PPC64 in shared code. > > Andrews suggestion of using the new C++11 atomic memory operators is > good, although in practice it may be hard to get all the different > compilers under the hood. What do you mean? > But now that we've even got the corresponding cmpxchg routines with > various acquire/release semantics in Java-land in the new > jdk.internal.Unsafe package, it would be a pity if it would not be > possible to use that functionality within the Hotspot. > > I think one approach to enable an easy transition would be to do the > proposed enhancements (or something similar) to cmpxchg > unconditionally in atomic.hpp. For example instead of two extra > boolean parameters we could use an enum similar to the one in > library_call.cpp: > > typedef enum { Relaxed, Opaque, Volatile, Acquire, Release } AccessKind; Note that cmpxchg has two args: memory order succeed, and memory order fail. > The default value of this parameter should of course be conservative > (i.e. Volatile) so we don't change the current behavior. After that > individual, performance critical callers of these routines can be > examined if they really require the most conservative setting and > maybe optimized. > > What do you think? OK, but I think we should use the standard C++ types from std::memory_order because HotSpot is a C++ program. These are: typedef enum memory_order { memory_order_relaxed, memory_order_consume, memory_order_acquire, memory_order_release, memory_order_acq_rel, memory_order_seq_cst } memory_order; I'm not suggesting they should have exactly these names, but it's a really good idea to insist they have the same semantics. So: { Relaxed, Consume, Acquire, Release, AquireRelease, SeqCst } I know that there is a (fairly) serious attempt to define the semantics of Unsafe memory order so that it's compatible with C++. I'm not sure if Opaque is useful at this level: as far as I can tell from the opaque (:-) documentation it's like a C++ volatile read. I'm sure we're going to need memory_order_consume sooner or later: HotSpot already assumes consume-like behaviour for memory accesses which have address dependencies. It would be nice to make such accesses explicit. Andrew. From christian.tornqvist at oracle.com Mon Apr 18 17:44:08 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 18 Apr 2016 13:44:08 -0400 Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules In-Reply-To: <571106C2.7090305@oracle.com> References: <571106C2.7090305@oracle.com> Message-ID: <6fa401d19999$e95ae7f0$bc10b7d0$@oracle.com> Hi Harold, This looks good! Thanks, Christian -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of harold seigel Sent: Friday, April 15, 2016 11:21 AM To: Hotspot dev runtime Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules Hi, Please review this small change to fix test bug 8154268. The change fixes the test's compilation error by adding @modules to the test. Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154268/ JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154268 Thanks, Harold From harold.seigel at oracle.com Mon Apr 18 17:44:53 2016 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 18 Apr 2016 13:44:53 -0400 Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules In-Reply-To: <6fa401d19999$e95ae7f0$bc10b7d0$@oracle.com> References: <571106C2.7090305@oracle.com> <6fa401d19999$e95ae7f0$bc10b7d0$@oracle.com> Message-ID: <57151D15.8000603@oracle.com> Thanks Christian! Harold On 4/18/2016 1:44 PM, Christian Tornqvist wrote: > Hi Harold, > > This looks good! > > Thanks, > Christian > > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of harold seigel > Sent: Friday, April 15, 2016 11:21 AM > To: Hotspot dev runtime > Subject: RFR(XS) 8154268: [TESTBUG] Compilation of ExportAllUnnamed.java failed, missing @modules > > Hi, > > Please review this small change to fix test bug 8154268. > > The change fixes the test's compilation error by adding @modules to the test. > > Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154268/ > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154268 > > Thanks, Harold > From gerard.ziemski at oracle.com Mon Apr 18 18:14:15 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 18 Apr 2016 13:14:15 -0500 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57120600.6090005@gmail.com> References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> Message-ID: hi Yasumasa, Nice work. I have 2 questions: ======== File: java.c #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? after every single JNI call? In this example instead of NULL_CHECK, should we be using CHECK_EXCEPTION_NULL_LEAVE macro? #2 Should the comment for ?SetNativeThreadName? be ?Set native thread name if possible.? not "Set native thread name as possible.?? cheers > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga wrote: > > Hi David, > > I uploaded new webrev: > > - hotspot: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ > > - jdk: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ > > >> it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? > > I added a flag for setting native thread name to JNI-attached thread. > This change can set native thread name if main thread changes to JNI-attached thread. > > > Thanks, > > Yasumasa > > > On 2016/04/16 16:11, David Holmes wrote: >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> That change in behaviour may be a problem, it could be considered a >>>> regression that setName stops setting the native thread main, even >>>> though we never really intended it to work in the first place. :( Such >>>> a change needs to go through CCC. >>> >>> I understood. >>> Can I send CCC request? >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >> >> Sorry you can't file a CCC request, you would need a sponsor for that. But at this stage I don't think I agree with the proposed change because of the change in behaviour - there's no way to restore the "broken" behaviour. >> >>> I want to continue to discuss about it on JDK-8154331 [1]. >> >> Okay we can do that. >> >>> >>>> Further, we expect the launcher to use the supported JNI interface (as >>>> other processes would), not the internal JVM interface that exists for >>>> the JDK sources to communicate with the JVM. >>> >>> I think that we do not use JVM interface if we add new method in >>> LauncherHelper as below: >>> ---------------- >>> diff -r f02139a1ac84 >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> Wed Apr 13 14:19:30 2016 +0000 >>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> Sat Apr 16 11:25:53 2016 +0900 >>> @@ -960,4 +960,8 @@ >>> else >>> return md.toNameAndVersion() + " (" + loc + ")"; >>> } >>> + >>> + static void setNativeThreadName(String name) { >>> + Thread.currentThread().setName(name); >>> + } >> >> You could also make that call via JNI directly, so not sure the helper adds much here. But it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? >> >> David >> ----- >> >>> } >>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >>> 2016 +0000 >>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >>> 2016 +0900 >>> @@ -125,6 +125,7 @@ >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>> static void ShowSettings(JNIEnv* env, char *optString); >>> static void ListModules(JNIEnv* env, char *optString); >>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>> >>> static void SetPaths(int argc, char **argv); >>> >>> @@ -325,6 +326,7 @@ >>> * mainThread.isAlive() to work as expected. >>> */ >>> #define LEAVE() \ >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>> do { \ >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>> @@ -488,6 +490,9 @@ >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>> >>> + /* Set native thread name. */ >>> + SetNativeThreadName(env, "main"); >>> + >>> /* Invoke main method. */ >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>> >>> @@ -1686,6 +1691,22 @@ >>> joptString); >>> } >>> >>> +/** >>> + * Set native thread name as possible. >>> + */ >>> +static void >>> +SetNativeThreadName(JNIEnv *env, char *name) >>> +{ >>> + jmethodID setNativeThreadNameID; >>> + jstring nameString; >>> + jclass cls = GetLauncherHelperClass(env); >>> + NULL_CHECK(cls); >>> + NULL_CHECK(setNativeThreadNameID = (*env)->GetStaticMethodID(env, cls, >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>> nameString); >>> +} >>> + >>> /* >>> * Prints default usage or the Xusage message, see >>> sun.launcher.LauncherHelper.java >>> */ >>> ---------------- >>> >>> So I want to add new arg to JVM_SetNativeThreadName(). >>> >>>> However this is still a change to the exported JVM interface and so >>>> has to be approved. >>> >>> Do you mean that this change needs CCC? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>> >>> >>> >>> On 2016/04/16 7:26, David Holmes wrote: >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> I think it is a bug based on the comment here: >>>>>> >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>>> JNI attached threads >>>>> >>>>> I filed it to JBS as JDK-8154331. >>>>> I will send review request to hotspot-runtime-dev. >>>>> >>>>> >>>>>> Though that will introduce a change in behaviour by itself as setName >>>>>> will no longer set the native name for the main thread. >>>>> >>>>> I know. >>>> >>>> That change in behaviour may be a problem, it could be considered a >>>> regression that setName stops setting the native thread main, even >>>> though we never really intended it to work in the first place. :( Such >>>> a change needs to go through CCC. >>>> >>>>> I checked changeset history. >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>>>> backported JDK 8. >>>> >>>> Yes this all came in as part of the OSX port in 7u2. >>>> >>>>> However, this function seems to be called from Thread#setNativeName() >>>>> only. >>>>> In addition, Thread#setNativeName() is private method. >>>>> >>>>> Thus I think that we can add an argument to JVM_SetNativeThreadName() >>>>> for force setting. >>>>> (e.g. "bool forced") >>>>> >>>>> It makes a change of JVM API. >>>>> However, this function is NOT public, so I think we can add one more >>>>> argument. >>>>> >>>>> What do you think about this? >>>>> If it is accepted, we can set native thread name from Java launcher. >>>> >>>> The private/public aspect of the Java API is not really at issue. Yes >>>> we would add another arg to the JVM function to allow it to apply to >>>> JNI-attached threads as well (I'd prefer the arg reflect that not just >>>> "force"). However this is still a change to the exported JVM interface >>>> and so has to be approved. Further, we expect the launcher to use the >>>> supported JNI interface (as other processes would), not the internal >>>> JVM interface that exists for the JDK sources to communicate with the >>>> JVM. >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> The fact that the "main" thread is not tagged as being a JNI-attached >>>>>>>> thread seems accidental to me >>>>>>> >>>>>>> Should I file it to JBS? >>>>>> >>>>>> I think it is a bug based on the comment here: >>>>>> >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>>> JNI attached threads >>>>>> >>>>>> Though that will introduce a change in behaviour by itself as setName >>>>>> will no longer set the native name for the main thread. >>>>>> >>>>>>> I think that we can fix as below: >>>>>>> --------------- >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>> #endif // INCLUDE_JVMCI >>>>>>> >>>>>>> // Attach the main thread to this os thread >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>> main_thread->initialize_thread_current(); >>>>>>> // must do this before set_active_handles >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>> // Notify JVMTI agents that VM initialization is complete - nop if >>>>>>> no agents. >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>> >>>>>>> + // Change attach status to "attached" >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>> + >>>>>> >>>>>> I think we can do this straight after the JavaThread constructor. >>>>>> >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>>> backend."); >>>>>>> } >>>>>>> --------------- >>>>>>> >>>>>>> >>>>>>>> If it wants to name its native threads then it is free to do so, >>>>>>> >>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread name >>>>>>> when the caller thread is JNI-attached thread. >>>>>>> However, I think that it should be changed if Java developer calls >>>>>>> Thread#setName() explicitly. >>>>>>> It is not the same of changing native thread name at >>>>>>> Threads::create_vm(). >>>>>>> >>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>>> What do you think about this? >>>>>> >>>>>> The decision to not change the name of JNI-attached threads was a >>>>>> deliberate one** - this functionality originated with the OSX port and >>>>>> it was reported that the initial feedback with this feature was to >>>>>> ensure it didn't mess with thread names that had been set by the host >>>>>> process. If we do as you propose then we will just have an >>>>>> inconsistency for people to complain about: "why does my native thread >>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>>> >>>>>> ** If you follow the bugs and related discussions on this, the >>>>>> semantics and limitations (truncation, current thread only, non-JNI >>>>>> threads only) of setting the native thread name were supposed to be >>>>>> documented in the release notes - but as far as I can see that never >>>>>> happened. :( >>>>>> >>>>>> My position on this remains that if it is desirable for the main >>>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>>> launcher needs to be setting them using the available platform APIs. >>>>>> Unfortunately this is complicated - as evidenced by the VM code for >>>>>> this - due to the need to verify API availability. >>>>>> >>>>>> Any change in behaviour in relation to Thread.setName would have to go >>>>>> through our CCC process I think. But a change in the launcher would >>>>>> not. >>>>>> >>>>>> Sorry. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> --------------- >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>>> // Thread naming only supported for the current thread, doesn't >>>>>>> work >>>>>>> for >>>>>>> // target threads. >>>>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>>>>> + if (Thread::current() == thr) { >>>>>>> // we don't set the name of an attached thread to avoid stepping >>>>>>> // on other programs >>>>>>> const char *thread_name = >>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>> --------------- >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>> Roger, >>>>>>>>> Thanks for your comment! >>>>>>>>> >>>>>>>>> David, >>>>>>>>> >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>> exposing >>>>>>>>>>>> a new JVM function this way. >>>>>>>>> >>>>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>>>> calling >>>>>>>>> main method), >>>>>>>>> I could set native thread name. >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't >>>>>>>>> set >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>> >>>>>>>> Right - I came to the same realization earlier this morning. Which, >>>>>>>> unfortunately, takes me back to the basic premise here that we don't >>>>>>>> set the name of threads not created by the JVM. The fact that the >>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>>>> accident for the initial attach, and can't be used for the >>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently named at >>>>>>>> the native level. >>>>>>>> >>>>>>>> I'm afraid my view here is that the launcher has to be treated like >>>>>>>> any other process that might host a JVM. If it wants to name its >>>>>>>> native threads then it is free to do so, but I would not be exporting >>>>>>>> a function from the JVM to do that - it would have to use the OS >>>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>>> >>>>>>>> Sorry. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Comments: >>>>>>>>>> >>>>>>>>>> jvm.h: The function names are too similar but perform different >>>>>>>>>> functions: >>>>>>>>>> >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>>> >>>>>>>>>> - The first function applies to the current thread, the second >>>>>>>>>> one a >>>>>>>>>> specific java thread. >>>>>>>>>> It would seem useful for there to be a comment somewhere about >>>>>>>>>> what >>>>>>>>>> the new function does. >>>>>>>>>> >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>>> instead of >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>> as is done on unix and mac. >>>>>>>>>> >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>>>>>> line 730 >>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>>>>>> same >>>>>>>>>> line as dlsym... >>>>>>>>>> >>>>>>>>>> $.02, Roger >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>> check - >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>> then >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>>> work >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>> >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>>>>>> thread name (test) was set. >>>>>>>>>>> --------- >>>>>>>>>>> public class Sleep{ >>>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>> } >>>>>>>>>>> } >>>>>>>>>>> --------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>> exposing >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>> >>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>> >>>>>>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>>>>>> need to >>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>>>>>> rather >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>>>> needed in >>>>>>>>>>>>>> that case. >>>>>>>>>>>>> >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>> >>>>>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>>>>> native >>>>>>>>>>>> name is not set. >>>>>>>>>>>> >>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>>> >>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>> check - >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>> then >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>>> work >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>> >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>> exposing >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>>>>>> thread name. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> From kumar.x.srinivasan at oracle.com Mon Apr 18 23:14:21 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 18 Apr 2016 16:14:21 -0700 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> Message-ID: <57156A4D.5000401@oracle.com> Oops on my part, Gerard is right. We need to make SetNativeThreadName exit, if there is an error, otherwise it would enter the VM with an exception at the call site. So I think CHECK_EXCEPTION_NULL_LEAVE is the right thing to do, or we need to have a check and exit at the call site. Kumar > hi Yasumasa, > > Nice work. I have 2 questions: > > ======== > File: java.c > > #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? after every single JNI call? In this example instead of NULL_CHECK, should we be using CHECK_EXCEPTION_NULL_LEAVE macro? > > #2 Should the comment for ?SetNativeThreadName? be ?Set native thread name if possible.? not "Set native thread name as possible.?? > > > cheers > >> On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> I uploaded new webrev: >> >> - hotspot: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >> >> - jdk: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >> >> >>> it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? >> I added a flag for setting native thread name to JNI-attached thread. >> This change can set native thread name if main thread changes to JNI-attached thread. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/16 16:11, David Holmes wrote: >>> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> That change in behaviour may be a problem, it could be considered a >>>>> regression that setName stops setting the native thread main, even >>>>> though we never really intended it to work in the first place. :( Such >>>>> a change needs to go through CCC. >>>> I understood. >>>> Can I send CCC request? >>>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>> Sorry you can't file a CCC request, you would need a sponsor for that. But at this stage I don't think I agree with the proposed change because of the change in behaviour - there's no way to restore the "broken" behaviour. >>> >>>> I want to continue to discuss about it on JDK-8154331 [1]. >>> Okay we can do that. >>> >>>>> Further, we expect the launcher to use the supported JNI interface (as >>>>> other processes would), not the internal JVM interface that exists for >>>>> the JDK sources to communicate with the JVM. >>>> I think that we do not use JVM interface if we add new method in >>>> LauncherHelper as below: >>>> ---------------- >>>> diff -r f02139a1ac84 >>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> Wed Apr 13 14:19:30 2016 +0000 >>>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> Sat Apr 16 11:25:53 2016 +0900 >>>> @@ -960,4 +960,8 @@ >>>> else >>>> return md.toNameAndVersion() + " (" + loc + ")"; >>>> } >>>> + >>>> + static void setNativeThreadName(String name) { >>>> + Thread.currentThread().setName(name); >>>> + } >>> You could also make that call via JNI directly, so not sure the helper adds much here. But it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? >>> >>> David >>> ----- >>> >>>> } >>>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >>>> 2016 +0000 >>>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >>>> 2016 +0900 >>>> @@ -125,6 +125,7 @@ >>>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>> static void ShowSettings(JNIEnv* env, char *optString); >>>> static void ListModules(JNIEnv* env, char *optString); >>>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>> >>>> static void SetPaths(int argc, char **argv); >>>> >>>> @@ -325,6 +326,7 @@ >>>> * mainThread.isAlive() to work as expected. >>>> */ >>>> #define LEAVE() \ >>>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>> do { \ >>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>> @@ -488,6 +490,9 @@ >>>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>> >>>> + /* Set native thread name. */ >>>> + SetNativeThreadName(env, "main"); >>>> + >>>> /* Invoke main method. */ >>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>> >>>> @@ -1686,6 +1691,22 @@ >>>> joptString); >>>> } >>>> >>>> +/** >>>> + * Set native thread name as possible. >>>> + */ >>>> +static void >>>> +SetNativeThreadName(JNIEnv *env, char *name) >>>> +{ >>>> + jmethodID setNativeThreadNameID; >>>> + jstring nameString; >>>> + jclass cls = GetLauncherHelperClass(env); >>>> + NULL_CHECK(cls); >>>> + NULL_CHECK(setNativeThreadNameID = (*env)->GetStaticMethodID(env, cls, >>>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>>> nameString); >>>> +} >>>> + >>>> /* >>>> * Prints default usage or the Xusage message, see >>>> sun.launcher.LauncherHelper.java >>>> */ >>>> ---------------- >>>> >>>> So I want to add new arg to JVM_SetNativeThreadName(). >>>> >>>>> However this is still a change to the exported JVM interface and so >>>>> has to be approved. >>>> Do you mean that this change needs CCC? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>> >>>> >>>> >>>> On 2016/04/16 7:26, David Holmes wrote: >>>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> I think it is a bug based on the comment here: >>>>>>> >>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>>>> JNI attached threads >>>>>> I filed it to JBS as JDK-8154331. >>>>>> I will send review request to hotspot-runtime-dev. >>>>>> >>>>>> >>>>>>> Though that will introduce a change in behaviour by itself as setName >>>>>>> will no longer set the native name for the main thread. >>>>>> I know. >>>>> That change in behaviour may be a problem, it could be considered a >>>>> regression that setName stops setting the native thread main, even >>>>> though we never really intended it to work in the first place. :( Such >>>>> a change needs to go through CCC. >>>>> >>>>>> I checked changeset history. >>>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>>>>> backported JDK 8. >>>>> Yes this all came in as part of the OSX port in 7u2. >>>>> >>>>>> However, this function seems to be called from Thread#setNativeName() >>>>>> only. >>>>>> In addition, Thread#setNativeName() is private method. >>>>>> >>>>>> Thus I think that we can add an argument to JVM_SetNativeThreadName() >>>>>> for force setting. >>>>>> (e.g. "bool forced") >>>>>> >>>>>> It makes a change of JVM API. >>>>>> However, this function is NOT public, so I think we can add one more >>>>>> argument. >>>>>> >>>>>> What do you think about this? >>>>>> If it is accepted, we can set native thread name from Java launcher. >>>>> The private/public aspect of the Java API is not really at issue. Yes >>>>> we would add another arg to the JVM function to allow it to apply to >>>>> JNI-attached threads as well (I'd prefer the arg reflect that not just >>>>> "force"). However this is still a change to the exported JVM interface >>>>> and so has to be approved. Further, we expect the launcher to use the >>>>> supported JNI interface (as other processes would), not the internal >>>>> JVM interface that exists for the JDK sources to communicate with the >>>>> JVM. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> The fact that the "main" thread is not tagged as being a JNI-attached >>>>>>>>> thread seems accidental to me >>>>>>>> Should I file it to JBS? >>>>>>> I think it is a bug based on the comment here: >>>>>>> >>>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and >>>>>>> JNI attached threads >>>>>>> >>>>>>> Though that will introduce a change in behaviour by itself as setName >>>>>>> will no longer set the native name for the main thread. >>>>>>> >>>>>>>> I think that we can fix as below: >>>>>>>> --------------- >>>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>> #endif // INCLUDE_JVMCI >>>>>>>> >>>>>>>> // Attach the main thread to this os thread >>>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>> main_thread->initialize_thread_current(); >>>>>>>> // must do this before set_active_handles >>>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>> // Notify JVMTI agents that VM initialization is complete - nop if >>>>>>>> no agents. >>>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>> >>>>>>>> + // Change attach status to "attached" >>>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>> + >>>>>>> I think we can do this straight after the JavaThread constructor. >>>>>>> >>>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>>>>> backend."); >>>>>>>> } >>>>>>>> --------------- >>>>>>>> >>>>>>>> >>>>>>>>> If it wants to name its native threads then it is free to do so, >>>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread name >>>>>>>> when the caller thread is JNI-attached thread. >>>>>>>> However, I think that it should be changed if Java developer calls >>>>>>>> Thread#setName() explicitly. >>>>>>>> It is not the same of changing native thread name at >>>>>>>> Threads::create_vm(). >>>>>>>> >>>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>>>>>>> What do you think about this? >>>>>>> The decision to not change the name of JNI-attached threads was a >>>>>>> deliberate one** - this functionality originated with the OSX port and >>>>>>> it was reported that the initial feedback with this feature was to >>>>>>> ensure it didn't mess with thread names that had been set by the host >>>>>>> process. If we do as you propose then we will just have an >>>>>>> inconsistency for people to complain about: "why does my native thread >>>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>>>> >>>>>>> ** If you follow the bugs and related discussions on this, the >>>>>>> semantics and limitations (truncation, current thread only, non-JNI >>>>>>> threads only) of setting the native thread name were supposed to be >>>>>>> documented in the release notes - but as far as I can see that never >>>>>>> happened. :( >>>>>>> >>>>>>> My position on this remains that if it is desirable for the main >>>>>>> thread (and DestroyJavaVM thread) to have native names then the >>>>>>> launcher needs to be setting them using the available platform APIs. >>>>>>> Unfortunately this is complicated - as evidenced by the VM code for >>>>>>> this - due to the need to verify API availability. >>>>>>> >>>>>>> Any change in behaviour in relation to Thread.setName would have to go >>>>>>> through our CCC process I think. But a change in the launcher would >>>>>>> not. >>>>>>> >>>>>>> Sorry. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> --------------- >>>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 >>>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 >>>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>>>>> // Thread naming only supported for the current thread, doesn't >>>>>>>> work >>>>>>>> for >>>>>>>> // target threads. >>>>>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { >>>>>>>> + if (Thread::current() == thr) { >>>>>>>> // we don't set the name of an attached thread to avoid stepping >>>>>>>> // on other programs >>>>>>>> const char *thread_name = >>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>> --------------- >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>> >>>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Roger, >>>>>>>>>> Thanks for your comment! >>>>>>>>>> >>>>>>>>>> David, >>>>>>>>>> >>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>> exposing >>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>> I tried to call Thread#setName() after initializing VM (before >>>>>>>>>> calling >>>>>>>>>> main method), >>>>>>>>>> I could set native thread name. >>>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't >>>>>>>>>> set >>>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>> Right - I came to the same realization earlier this morning. Which, >>>>>>>>> unfortunately, takes me back to the basic premise here that we don't >>>>>>>>> set the name of threads not created by the JVM. The fact that the >>>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>>>>>>>> accident for the initial attach, and can't be used for the >>>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently named at >>>>>>>>> the native level. >>>>>>>>> >>>>>>>>> I'm afraid my view here is that the launcher has to be treated like >>>>>>>>> any other process that might host a JVM. If it wants to name its >>>>>>>>> native threads then it is free to do so, but I would not be exporting >>>>>>>>> a function from the JVM to do that - it would have to use the OS >>>>>>>>> specific API's for that on a platform-by-platform basis. >>>>>>>>> >>>>>>>>> Sorry. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Comments: >>>>>>>>>>> >>>>>>>>>>> jvm.h: The function names are too similar but perform different >>>>>>>>>>> functions: >>>>>>>>>>> >>>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>>>>>>>> >>>>>>>>>>> - The first function applies to the current thread, the second >>>>>>>>>>> one a >>>>>>>>>>> specific java thread. >>>>>>>>>>> It would seem useful for there to be a comment somewhere about >>>>>>>>>>> what >>>>>>>>>>> the new function does. >>>>>>>>>>> >>>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>>>>>>>>>> instead of >>>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>> as is done on unix and mac. >>>>>>>>>>> >>>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at >>>>>>>>>>> line 730 >>>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the >>>>>>>>>>> same >>>>>>>>>>> line as dlsym... >>>>>>>>>>> >>>>>>>>>>> $.02, Roger >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>> check - >>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>>> then >>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>>>> work >>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native >>>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>> --------- >>>>>>>>>>>> public class Sleep{ >>>>>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>> } >>>>>>>>>>>> } >>>>>>>>>>>> --------- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>> exposing >>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I exported new JVM function to set native thread name, and JLI >>>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>>> First the launcher belongs to another team so core-libs will >>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName >>>>>>>>>>>>>>> rather >>>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>>>>>>>>>>>>>> needed in >>>>>>>>>>>>>>> that case. >>>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>>> At Thread.init time the thread is not alive, which is why the >>>>>>>>>>>>> native >>>>>>>>>>>>> name is not set. >>>>>>>>>>>>> >>>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>>>>>>>>>> That is an interesting question which I haven't had time to >>>>>>>>>>>>> check - >>>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread >>>>>>>>>>>>> then >>>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should >>>>>>>>>>>>> work >>>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>> >>>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>>>>>>>>>>>> exposing >>>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> Thus I think that we have to provide a function to set native >>>>>>>>>>>>>> thread name. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not >>>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles >>>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in >>>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte >>>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 >>>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 >>>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; >>>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); >>>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I >>>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want >>>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have >>>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. >>>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I think >>>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via >>>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> From yasuenag at gmail.com Mon Apr 18 23:28:32 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 19 Apr 2016 08:28:32 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <56F41AFF.4090002@oracle.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> Message-ID: Hi Gerard, 2016/04/19 3:14 "Gerard Ziemski" : > > hi Yasumasa, > > Nice work. I have 2 questions: > > ======== > File: java.c > > #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? after every single JNI call? In this example instead of NULL_CHECK, should we be using CHECK_EXCEPTION_NULL_LEAVE macro? It is not critical if we encounter error at JNI function call because we cannot set native thread name only. So I think that we do not need to leave from launcher process. > #2 Should the comment for ?SetNativeThreadName? be ?Set native thread name if possible.? not "Set native thread name as possible.?? Sorry for my bad English :-) Thanks, Yasumasa > cheers > > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga wrote: > > > > Hi David, > > > > I uploaded new webrev: > > > > - hotspot: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ > > > > - jdk: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ > > > > > >> it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? > > > > I added a flag for setting native thread name to JNI-attached thread. > > This change can set native thread name if main thread changes to JNI-attached thread. > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2016/04/16 16:11, David Holmes wrote: > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: > >>> Hi David, > >>> > >>>> That change in behaviour may be a problem, it could be considered a > >>>> regression that setName stops setting the native thread main, even > >>>> though we never really intended it to work in the first place. :( Such > >>>> a change needs to go through CCC. > >>> > >>> I understood. > >>> Can I send CCC request? > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) > >> > >> Sorry you can't file a CCC request, you would need a sponsor for that. But at this stage I don't think I agree with the proposed change because of the change in behaviour - there's no way to restore the "broken" behaviour. > >> > >>> I want to continue to discuss about it on JDK-8154331 [1]. > >> > >> Okay we can do that. > >> > >>> > >>>> Further, we expect the launcher to use the supported JNI interface (as > >>>> other processes would), not the internal JVM interface that exists for > >>>> the JDK sources to communicate with the JVM. > >>> > >>> I think that we do not use JVM interface if we add new method in > >>> LauncherHelper as below: > >>> ---------------- > >>> diff -r f02139a1ac84 > >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java > >>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java > >>> Wed Apr 13 14:19:30 2016 +0000 > >>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java > >>> Sat Apr 16 11:25:53 2016 +0900 > >>> @@ -960,4 +960,8 @@ > >>> else > >>> return md.toNameAndVersion() + " (" + loc + ")"; > >>> } > >>> + > >>> + static void setNativeThreadName(String name) { > >>> + Thread.currentThread().setName(name); > >>> + } > >> > >> You could also make that call via JNI directly, so not sure the helper adds much here. But it won't work unless you change the semantics of setName so I'm not sure what you were thinking here. To take advantage of an arg taking JVM_SetNativThreadName you would need to call it directly as no Java code will call it . ??? > >> > >> David > >> ----- > >> > >>> } > >>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c > >>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 > >>> 2016 +0000 > >>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 > >>> 2016 +0900 > >>> @@ -125,6 +125,7 @@ > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); > >>> static void ShowSettings(JNIEnv* env, char *optString); > >>> static void ListModules(JNIEnv* env, char *optString); > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); > >>> > >>> static void SetPaths(int argc, char **argv); > >>> > >>> @@ -325,6 +326,7 @@ > >>> * mainThread.isAlive() to work as expected. > >>> */ > >>> #define LEAVE() \ > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ > >>> do { \ > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ > >>> @@ -488,6 +490,9 @@ > >>> mainArgs = CreateApplicationArgs(env, argv, argc); > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); > >>> > >>> + /* Set native thread name. */ > >>> + SetNativeThreadName(env, "main"); > >>> + > >>> /* Invoke main method. */ > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); > >>> > >>> @@ -1686,6 +1691,22 @@ > >>> joptString); > >>> } > >>> > >>> +/** > >>> + * Set native thread name as possible. > >>> + */ > >>> +static void > >>> +SetNativeThreadName(JNIEnv *env, char *name) > >>> +{ > >>> + jmethodID setNativeThreadNameID; > >>> + jstring nameString; > >>> + jclass cls = GetLauncherHelperClass(env); > >>> + NULL_CHECK(cls); > >>> + NULL_CHECK(setNativeThreadNameID = (*env)->GetStaticMethodID(env, cls, > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); > >>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, > >>> nameString); > >>> +} > >>> + > >>> /* > >>> * Prints default usage or the Xusage message, see > >>> sun.launcher.LauncherHelper.java > >>> */ > >>> ---------------- > >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). > >>> > >>>> However this is still a change to the exported JVM interface and so > >>>> has to be approved. > >>> > >>> Do you mean that this change needs CCC? > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>> [1] > >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html > >>> > >>> > >>> > >>> On 2016/04/16 7:26, David Holmes wrote: > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: > >>>>> Hi David, > >>>>> > >>>>>> I think it is a bug based on the comment here: > >>>>>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and > >>>>>> JNI attached threads > >>>>> > >>>>> I filed it to JBS as JDK-8154331. > >>>>> I will send review request to hotspot-runtime-dev. > >>>>> > >>>>> > >>>>>> Though that will introduce a change in behaviour by itself as setName > >>>>>> will no longer set the native name for the main thread. > >>>>> > >>>>> I know. > >>>> > >>>> That change in behaviour may be a problem, it could be considered a > >>>> regression that setName stops setting the native thread main, even > >>>> though we never really intended it to work in the first place. :( Such > >>>> a change needs to go through CCC. > >>>> > >>>>> I checked changeset history. > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is > >>>>> backported JDK 8. > >>>> > >>>> Yes this all came in as part of the OSX port in 7u2. > >>>> > >>>>> However, this function seems to be called from Thread#setNativeName() > >>>>> only. > >>>>> In addition, Thread#setNativeName() is private method. > >>>>> > >>>>> Thus I think that we can add an argument to JVM_SetNativeThreadName() > >>>>> for force setting. > >>>>> (e.g. "bool forced") > >>>>> > >>>>> It makes a change of JVM API. > >>>>> However, this function is NOT public, so I think we can add one more > >>>>> argument. > >>>>> > >>>>> What do you think about this? > >>>>> If it is accepted, we can set native thread name from Java launcher. > >>>> > >>>> The private/public aspect of the Java API is not really at issue. Yes > >>>> we would add another arg to the JVM function to allow it to apply to > >>>> JNI-attached threads as well (I'd prefer the arg reflect that not just > >>>> "force"). However this is still a change to the exported JVM interface > >>>> and so has to be approved. Further, we expect the launcher to use the > >>>> supported JNI interface (as other processes would), not the internal > >>>> JVM interface that exists for the JDK sources to communicate with the > >>>> JVM. > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>>> > >>>>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: > >>>>>> Hi Yasumasa, > >>>>>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>>> The fact that the "main" thread is not tagged as being a JNI-attached > >>>>>>>> thread seems accidental to me > >>>>>>> > >>>>>>> Should I file it to JBS? > >>>>>> > >>>>>> I think it is a bug based on the comment here: > >>>>>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main thread and > >>>>>> JNI attached threads > >>>>>> > >>>>>> Though that will introduce a change in behaviour by itself as setName > >>>>>> will no longer set the native name for the main thread. > >>>>>> > >>>>>>> I think that we can fix as below: > >>>>>>> --------------- > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 2016 +0200 > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 2016 +0900 > >>>>>>> @@ -3592,7 +3592,7 @@ > >>>>>>> #endif // INCLUDE_JVMCI > >>>>>>> > >>>>>>> // Attach the main thread to this os thread > >>>>>>> - JavaThread* main_thread = new JavaThread(); > >>>>>>> + JavaThread* main_thread = new JavaThread(true); > >>>>>>> main_thread->set_thread_state(_thread_in_vm); > >>>>>>> main_thread->initialize_thread_current(); > >>>>>>> // must do this before set_active_handles > >>>>>>> @@ -3776,6 +3776,9 @@ > >>>>>>> // Notify JVMTI agents that VM initialization is complete - nop if > >>>>>>> no agents. > >>>>>>> JvmtiExport::post_vm_initialized(); > >>>>>>> > >>>>>>> + // Change attach status to "attached" > >>>>>>> + main_thread->set_done_attaching_via_jni(); > >>>>>>> + > >>>>>> > >>>>>> I think we can do this straight after the JavaThread constructor. > >>>>>> > >>>>>>> if (TRACE_START() != JNI_OK) { > >>>>>>> vm_exit_during_initialization("Failed to start tracing > >>>>>>> backend."); > >>>>>>> } > >>>>>>> --------------- > >>>>>>> > >>>>>>> > >>>>>>>> If it wants to name its native threads then it is free to do so, > >>>>>>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change native thread name > >>>>>>> when the caller thread is JNI-attached thread. > >>>>>>> However, I think that it should be changed if Java developer calls > >>>>>>> Thread#setName() explicitly. > >>>>>>> It is not the same of changing native thread name at > >>>>>>> Threads::create_vm(). > >>>>>>> > >>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. > >>>>>>> What do you think about this? > >>>>>> > >>>>>> The decision to not change the name of JNI-attached threads was a > >>>>>> deliberate one** - this functionality originated with the OSX port and > >>>>>> it was reported that the initial feedback with this feature was to > >>>>>> ensure it didn't mess with thread names that had been set by the host > >>>>>> process. If we do as you propose then we will just have an > >>>>>> inconsistency for people to complain about: "why does my native thread > >>>>>> only have a name if I call cur.setName(cur.getName()) ?" > >>>>>> > >>>>>> ** If you follow the bugs and related discussions on this, the > >>>>>> semantics and limitations (truncation, current thread only, non-JNI > >>>>>> threads only) of setting the native thread name were supposed to be > >>>>>> documented in the release notes - but as far as I can see that never > >>>>>> happened. :( > >>>>>> > >>>>>> My position on this remains that if it is desirable for the main > >>>>>> thread (and DestroyJavaVM thread) to have native names then the > >>>>>> launcher needs to be setting them using the available platform APIs. > >>>>>> Unfortunately this is complicated - as evidenced by the VM code for > >>>>>> this - due to the need to verify API availability. > >>>>>> > >>>>>> Any change in behaviour in relation to Thread.setName would have to go > >>>>>> through our CCC process I think. But a change in the launcher would > >>>>>> not. > >>>>>> > >>>>>> Sorry. > >>>>>> > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>> --------------- > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 2016 +0200 > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 2016 +0900 > >>>>>>> @@ -3187,7 +3187,7 @@ > >>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); > >>>>>>> // Thread naming only supported for the current thread, doesn't > >>>>>>> work > >>>>>>> for > >>>>>>> // target threads. > >>>>>>> - if (Thread::current() == thr && !thr->has_attached_via_jni()) { > >>>>>>> + if (Thread::current() == thr) { > >>>>>>> // we don't set the name of an attached thread to avoid stepping > >>>>>>> // on other programs > >>>>>>> const char *thread_name = > >>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); > >>>>>>> --------------- > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> Yasumasa > >>>>>>> > >>>>>>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: > >>>>>>>>> Roger, > >>>>>>>>> Thanks for your comment! > >>>>>>>>> > >>>>>>>>> David, > >>>>>>>>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like > >>>>>>>>>>>> exposing > >>>>>>>>>>>> a new JVM function this way. > >>>>>>>>> > >>>>>>>>> I tried to call Thread#setName() after initializing VM (before > >>>>>>>>> calling > >>>>>>>>> main method), > >>>>>>>>> I could set native thread name. > >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we can't > >>>>>>>>> set > >>>>>>>>> native thread name for DestroyJavaVM. > >>>>>>>> > >>>>>>>> Right - I came to the same realization earlier this morning. Which, > >>>>>>>> unfortunately, takes me back to the basic premise here that we don't > >>>>>>>> set the name of threads not created by the JVM. The fact that the > >>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by > >>>>>>>> accident for the initial attach, and can't be used for the > >>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently named at > >>>>>>>> the native level. > >>>>>>>> > >>>>>>>> I'm afraid my view here is that the launcher has to be treated like > >>>>>>>> any other process that might host a JVM. If it wants to name its > >>>>>>>> native threads then it is free to do so, but I would not be exporting > >>>>>>>> a function from the JVM to do that - it would have to use the OS > >>>>>>>> specific API's for that on a platform-by-platform basis. > >>>>>>>> > >>>>>>>> Sorry. > >>>>>>>> > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> > >>>>>>>>> Yasumasa > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> Comments: > >>>>>>>>>> > >>>>>>>>>> jvm.h: The function names are too similar but perform different > >>>>>>>>>> functions: > >>>>>>>>>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName > >>>>>>>>>> > >>>>>>>>>> - The first function applies to the current thread, the second > >>>>>>>>>> one a > >>>>>>>>>> specific java thread. > >>>>>>>>>> It would seem useful for there to be a comment somewhere about > >>>>>>>>>> what > >>>>>>>>>> the new function does. > >>>>>>>>>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) > >>>>>>>>>> instead of > >>>>>>>>>> (SetNativeThreadName0_t) > >>>>>>>>>> as is done on unix and mac. > >>>>>>>>>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: > >>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs used at > >>>>>>>>>> line 730 > >>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast on the > >>>>>>>>>> same > >>>>>>>>>> line as dlsym... > >>>>>>>>>> > >>>>>>>>>> $.02, Roger > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: > >>>>>>>>>>>> That is an interesting question which I haven't had time to > >>>>>>>>>>>> check - > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread > >>>>>>>>>>>> then > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should > >>>>>>>>>>>> work > >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of > >>>>>>>>>>>> JNI-attached threads :( ) > >>>>>>>>>>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed native > >>>>>>>>>>> thread name (test) was set. > >>>>>>>>>>> --------- > >>>>>>>>>>> public class Sleep{ > >>>>>>>>>>> public static void main(String[] args) throws Exception{ > >>>>>>>>>>> Thread.currentThread().setName("test"); > >>>>>>>>>>> Thread.sleep(3600000); > >>>>>>>>>>> } > >>>>>>>>>>> } > >>>>>>>>>>> --------- > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like > >>>>>>>>>>>> exposing > >>>>>>>>>>>> a new JVM function this way. > >>>>>>>>>>> > >>>>>>>>>>> I will update webrev after hearing Kumar's comment. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> > >>>>>>>>>>> Yasumasa > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: > >>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: > >>>>>>>>>>>>>>> Hi David, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks for your comment. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I exported new JVM function to set native thread name, and JLI > >>>>>>>>>>>>>>> uses it > >>>>>>>>>>>>>>> in new webrev. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> First the launcher belongs to another team so core-libs will > >>>>>>>>>>>>>> need to > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks! > >>>>>>>>>>>>> I'm waiting to review :-) > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to Thread.setName > >>>>>>>>>>>>>> rather > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes > >>>>>>>>>>>>>> needed in > >>>>>>>>>>>>>> that case. > >>>>>>>>>>>>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in > >>>>>>>>>>>>> Thread#init(), > >>>>>>>>>>>>> but I could not change native thread name. > >>>>>>>>>>>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, which is why the > >>>>>>>>>>>> native > >>>>>>>>>>>> name is not set. > >>>>>>>>>>>> > >>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. > >>>>>>>>>>>> > >>>>>>>>>>>> That is an interesting question which I haven't had time to > >>>>>>>>>>>> check - > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached thread > >>>>>>>>>>>> then > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion should > >>>>>>>>>>>> work > >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of > >>>>>>>>>>>> JNI-attached threads :( ) > >>>>>>>>>>>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like > >>>>>>>>>>>> exposing > >>>>>>>>>>>> a new JVM function this way. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> David > >>>>>>>>>>>> ----- > >>>>>>>>>>>> > >>>>>>>>>>>>> Thus I think that we have to provide a function to set native > >>>>>>>>>>>>> thread name. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yasumasa > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> [1] > >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> David > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Could you review again? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - hotspot: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> - jdk: > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yasumasa > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: > >>>>>>>>>>>>>>>> I'll answer on this original thread as well ... > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi Yasumasa, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on > >>>>>>>>>>>>>>>> vacation). > >>>>>>>>>>>>>>>> This > >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we do not > >>>>>>>>>>>>>>>> set the > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the > >>>>>>>>>>>>>>>> "main" > >>>>>>>>>>>>>>>> thread. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: > >>>>>>>>>>>>>>>>> Thanks Robbin, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Yasumasa > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" : > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> /Robbin > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> /Robbin > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. > >>>>>>>>>>>>>>>>>>>> Could you review it? > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Yasumasa > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" < robbin.ehn at oracle.com > >>>>>>>>>>>>>>>>>>>>>> >: > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>> >>: > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp > >>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu > >>>>>>>>>>>>>>>>>>>>>> Mar 24 > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 > >>>>>>>>>>>>>>>>>>>>>> +0000 > >>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu > >>>>>>>>>>>>>>>>>>>>>> Mar 24 > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 > >>>>>>>>>>>>>>>>>>>>>> +0100 > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new JavaThread(); > >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->set_thread_state(_thread_in_vm); > >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); > >>>>>>>>>>>>>>>>>>>>>> >> > + main_thread->set_native_thread_name("main"); > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before set_active_handles > >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread name in > >>>>>>>>>>>>>>>>>>>>>> Thread > >>>>>>>>>>>>>>>>>>>>>> class. > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native > >>>>>>>>>>>>>>>>>>>>>> thread > >>>>>>>>>>>>>>>>>>>>>> name > >>>>>>>>>>>>>>>>>>>>>> will be > >>>>>>>>>>>>>>>>>>>>>> set at > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already starte > >>>>>>>>>>>>>>>>>>>>>> in VM. > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name > >>>>>>>>>>>>>>>>>>>>>> should > >>>>>>>>>>>>>>>>>>>>>> be the > >>>>>>>>>>>>>>>>>>>>>> same. > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like > >>>>>>>>>>>>>>>>>>>>>> this is > >>>>>>>>>>>>>>>>>>>>>> nicer, no? > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue Mar 29 > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 > >>>>>>>>>>>>>>>>>>>>>> 2016 > >>>>>>>>>>>>>>>>>>>>>> +0200 > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed Mar 30 > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 > >>>>>>>>>>>>>>>>>>>>>> 2016 > >>>>>>>>>>>>>>>>>>>>>> +0200 > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread > >>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle > >>>>>>>>>>>>>>>>>>>>>> thread_group, > >>>>>>>>>>>>>>>>>>>>>> JavaThread* > >>>>>>>>>>>>>>>>>>>>>> thread, > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { > >>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = "main"; > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = > >>>>>>>>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> true, > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = > >>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), thread); > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), > >>>>>>>>>>>>>>>>>>>>>> NormPriority); > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); > >>>>>>>>>>>>>>>>>>>>>> > - > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = > >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > >>>>>>>>>>>>>>>>>>>>>> > + > >>>>>>>>>>>>>>>>>>>>>> > + > >>>>>>>>>>>>>>>>>>>>>> thread->set_native_thread_name(initial_thread_name); > >>>>>>>>>>>>>>>>>>>>>> > + > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = > >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str(initial_thread_name, > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks! > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and > >>>>>>>>>>>>>>>>>>>>>> naming > >>>>>>>>>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>>>>>>> thread > >>>>>>>>>>>>>>>>>>>>>> just > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and thus > >>>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>> process) is > >>>>>>>>>>>>>>>>>>>>>> 'java' but > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not > >>>>>>>>>>>>>>>>>>>>>> JavaThread. > >>>>>>>>>>>>>>>>>>>>>> It is > >>>>>>>>>>>>>>>>>>>>>> waiting > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for JavaThread. So I > >>>>>>>>>>>>>>>>>>>>>> think that > >>>>>>>>>>>>>>>>>>>>>> we do > >>>>>>>>>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since we want > >>>>>>>>>>>>>>>>>>>>>> java and > >>>>>>>>>>>>>>>>>>>>>> native > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might have > >>>>>>>>>>>>>>>>>>>>>> some > >>>>>>>>>>>>>>>>>>>>>> dependents. > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main > >>>>>>>>>>>>>>>>>>>>>> Thread'. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java launcher - e.g. > >>>>>>>>>>>>>>>>>>>>>> Apache > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, I think > >>>>>>>>>>>>>>>>>>>>>> that we > >>>>>>>>>>>>>>>>>>>>>> have to > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> No > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> /Robbin > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > /Robbin > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa Suenaga wrote: > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread name via > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main > >>>>>>>>>>>>>>>>>>>>>> thread is > >>>>>>>>>>>>>>>>>>>>>> JavaThread. > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have > >>>>>>>>>>>>>>>>>>>>>> native > >>>>>>>>>>>>>>>>>>>>>> thread > >>>>>>>>>>>>>>>>>>>>>> name. > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> > From david.holmes at oracle.com Tue Apr 19 00:03:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 10:03:39 +1000 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> Message-ID: <571575DB.9090009@oracle.com> Hi Carsten, On 18/04/2016 11:01 PM, Carsten Varming wrote: > Dear Hiroshi and David, > > I took a brief look at the patch and the idea looks good to me, in fact, > a bunch of the garbage collectors could benefit from similar changes (G1 > and ParNew both use oopDesc::forward_to_atomic which does not call > cas_set_mark, and they could both benefit from the weaker semantics). > > An important question is: Should the shared parts of hotspot move > towards weaker memory models? If yes, then everybody should review code > assuming the weaker semantics. If no, then there really isn't room for > patches like this one :(. The shared code should be written in a form that is correct on the weakest memory model we support - always using the appropriate Atomic and/or OrderAccess operations. On individual platforms those operations then reduce - sometimes to no-ops - based on the platform semantics. But that also requires we have a comprehensive set of Atomic and/or OrderAccess operations to choose from, so that we don't define algorithms that are unnecessarily excessive in their use of memory barriers. That said, establishing that a given algorithm+data-structure can be coded in a more relaxed form is a significant challenge in terms of "proving" correctness and adequate testing. I expect conservatism to rule in many places. More on Volker's response ... Thanks, David > The patch needs some work (IMHO). The name cas_set_mark must be renamed > to reflect the weaker semantics, and the ifdefs in the shared code > should be removed. All platforms should be changed as the Atomic API is > extended, and platforms with weaker memory models should implement the > weaker semantics. Finally, oopDesc::forward_to_atomic should use the > weaker semantics, preferable by calling cas_set_mark instead of calling > into Atomic directly. > > BTW. what is going on in oopDesc::forward_to_atomic? If curMark != > oldMark, then curMark must have been marked (a similar fact is checked > by "assert(is_forwarded())" (modulo a short race)), oldMark is set to > curMark and then oldMark->is_marked is checked in the look condition. > Why is there a loop? It seems much simpler if the assert is changed to a > "guarantee(curMark->is_marked)" and the loop is changed to an if > statement. Oh, and an assert is probably sufficient. > > My 2 cents, > Carsten > > On Mon, Apr 18, 2016 at 12:38 AM, David Holmes > wrote: > > Hi Hiroshi, > > On 18/04/2016 12:15 PM, Hiroshi H Horii wrote: > > Hi David, > > Thank you for your replying and sorry that I didn't append my > diff file > when the discussion was forwarded to this mailing list. I > appended my > original diff file (hg diff -g) to this mail. > > > It is fine for ppc to have variations of cmpxchg with > different memory > > barrier semantics, but the shared API must not be affected > as there is a > > requirement that the basic form of this operation provide "full > > bi-directional fence" semantics. Note that these semantics > are not in > > place to fulfill Java Memory Model requirements, but are an > internal > > contract in hotspot. > > Sure. Probably, it is better for me to modify my patch because it > changes the internal contract. I will create a new patch that > adds new > cmpxchg functions for ppc. > > > I think this is only usable from PPC specific code, not from the > shared code as per your original patch. The oopDesc::cas_set_mark > may be written to expect the full bi-directional fence that is > required by the atomic.hpp contract. If we break that contract we > would have to prove correctness along all code paths using that code > - well the ppc64 folk would have to do that :). But I would object > to the platform-specific code in the shared file - sorry. > > Thanks, > David > > > Also can you get someone to host the webrev > > for you on cr.openjdk.java.net ? > Or else include the diff in the bug > report. > > I will ask someone to create webrev after my next patch is created. > > > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > David Holmes > wrote on 04/16/2016 16:43:20: > > > From: David Holmes > > > To: Christian Thalinger >, Hiroshi H > > Horii/Japan/IBM at IBMJP > > Cc: Tim Ellison >, ppc-aix-port- > > dev at openjdk.java.net , > hotspot-runtime-dev at openjdk.java.net > > > Date: 04/16/2016 16:46 > > Subject: Re: enhancement of cmpxchg and copy_to_survivor for > ppc64 > > > > > Hi Hiroshi, > > > > As the diff file does not survive the mail process I can't > see the > > actual proposed changes. There doesn't seem to be a bug for > this so > > could you please file one. Also can you get someone to host > the webrev > > for you on cr.openjdk.java.net ? > Or else include the diff in the bug > report. > > > > It is fine for ppc to have variations of cmpxchg with > different memory > > barrier semantics, but the shared API must not be affected > as there is a > > requirement that the basic form of this operation provide "full > > bi-directional fence" semantics. Note that these semantics > are not in > > place to fulfill Java Memory Model requirements, but are an > internal > > contract in hotspot. > > > > Thanks, > > David > > > > On 12/04/2016 3:59 AM, Christian Thalinger wrote: > > > [This should be on hotspot-runtime-dev. BCC?ing > hotspot-compiler-dev.] > > > > > >> On Apr 8, 2016, at 12:53 AM, Hiroshi H Horii > > wrote: > > >> > > >> Dear all: > > >> > > >> Can I please request reviews for the following change? > > >> This change was created for JDK 9 and ppc64. > > >> > > >> Description: > > >> This change adds options of compare-and-exchange for POWER > architecture. > > >> As described in atomic_linux_ppc.inline.hpp, the current > implementation of > > >> cmpxchg is fence_cmpxchg_acquire. This implementation is > useful for > > >> general purposes because twice calls of sync before and after > cmpxchg will > > >> keep consistency. However, they sometimes cause overheads > because > > >> sync instructions are very expensive in the current POWER > chip design. > > >> With this change, callers can explicitly specify to run > fence and > > acquire with > > >> two additional bool parameters. Because their default > values are > "true", > > >> it is not necessary to modify existing cmpxchg calls. > > >> > > >> In addition, with the new parameters of cmpxchg, this > change improves > > >> performance of copy_to_survivor in the parallel GC. > > >> copy_to_survivor changes forward pointers by using > cmpxchg. This > > >> operation doesn't require any sync instructions, in my > understanding. > > >> A pointer is changed at most once in a GC and when > cmpxchg fails, > > >> the latest pointer is available for the caller. > > >> > > >> When I evaluated SPECjbb2013 (slightly customized because > obsolete > grizzly > > >> doesn't support new version format of Java 9), pause time > of young > GC was > > >> reduced from 10% to 20%. > > >> > > >> Summary of source code changes: > > >> > > >> * src/share/vm/runtime/atomic.hpp > > >> * src/share/vm/runtime/atomic.cpp > > >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > > >> - Add two arguments of fence and acquire to > cmpxchg only > for PPC64. > > >> Though cmpxchg in atomic_linux_ppc.inline.hpp > has some > branches, > > >> they are reduced while inlining to callers. > > >> > > >> * src/share/vm/oops/oop.inline.hpp > > >> - Changed cas_set_mark to call cmpxchg without > fence and > acquire. > > >> cas_set_mark is called only by cas_forward_to > that is > > called only by > > >> copy_to_survivor_space and oop_promotion_failed in > > >> psPromotionManager. > > >> > > >> Code change: > > >> > > >> Please see an attached diff file that was generated > with "hg > diff -g" > > >> under the latest hotspot directory. > > >> > > >> Passed test: > > >> SPECjbb2013 (customized) > > >> > > >> * I believe some other cmpxchg will be optimized by > reducing fence > > >> or acquire because twice calls of sync are too > conservative > toimplement > > >> Java memory model. > > >> > > >> > > >> > > >> Regards, > > >> Hiroshi > > >> ----------------------- > > >> Hiroshi Horii, Ph.D. > > >> IBM Research - Tokyo > > >> > > > > > > > From david.holmes at oracle.com Tue Apr 19 01:54:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 11:54:50 +1000 Subject: RFR (S): 8153751: Windows Atomic and OrderAccess are not emitting explicit compiler barriers In-Reply-To: <57077322.3000009@oracle.com> References: <57077322.3000009@oracle.com> Message-ID: <57158FEA.4090000@oracle.com> Hi Erik, Sorry for the delay on this. On 8/04/2016 7:00 PM, Erik ?sterlund wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153751 > Webrev: http://cr.openjdk.java.net/~eosterlund/8153751/webrev.00/ > > It turns out that on Windows, compiler barriers are not used for > Atomic:: code and some code in OrderAccess. It is assumed that the > non-volatile accesses will not be reordered across __asm statements, as > the current memory model should prevent. But I have not found any > guarantees that this is the case for __asm. Agreed - not that I would expect it to be clearly documented even if true. There is no reason to assume that any arbitrary _asm statement automatically acts as a compiler barrier, though some may. > The closest source I could find is the documentation for the > MemoryBarrier macro that uses an __asm statement to produce a hardware > membar. The documentation says the following: "Creates a hardware memory > barrier (fence) that prevents the CPU from re-ordering read and write > operations. It may also prevent the compiler from re-ordering read and > write operations." > > Note the "MAY" prevent compiler reordering. (*facepalm*) This sounds to > me like __asm really does not guarantee compiler reordering across __asm > at all. Yeah that sounds like it was written by someone who really didn't understand the issues. :( > A suspected victim of this reordering is here: > https://bugs.openjdk.java.net/browse/JDK-8033545 I don't really see how that particular bug would be helped by additional compiler-barriers. As I understand the report it was the elision of a non-volatile load that caused the problem, not a reordering. But anyway ... > To make the use of these classes more safe, I propose to simply add > explicit compiler barriers in this windows code. It should not make any > difference, as I am only enforcing compiler reordering rules that should > already hold. Okay, I agree with the proposed changes - the CompilerBarrierScope should effectively have no impact on generated code, other than prohibiting code motion. > This small patch fixes this. The only thing to note is that the __asm > statements that put things in %eax and avoid returning anything. Could you elaborate on that please ?? > Testing: JPRT Did you compare the generated object code before and after to see if it actually changed anything? Thanks, David ----- > Thanks, > /Erik From david.holmes at oracle.com Tue Apr 19 02:30:25 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 12:30:25 +1000 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5714FC1F.3080504@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57109E39.4000404@oracle.com> <5710FAE5.7090000@oracle.com> <5710FCAA.8080107@oracle.com> <5714E22F.3080403@oracle.com> <5714E499.5070802@oracle.com> <5714FC1F.3080504@oracle.com> Message-ID: <57159841.5020802@oracle.com> On 19/04/2016 1:24 AM, Max Ockner wrote: > http://cr.openjdk.java.net/~mockner/8151526.06/ > > - Renamed describe_no_lock => describe_available > - Renamed describe_with_lock => describe_current_configuration > - Removed unnecessary import of vmError in logConfiguration.cpp > - Fixed typo in comment in logConfiguration.hpp > - hs_err file now only uses describe_current_configuration, which was > the original intent of this enhancement. VM info still uses describe(). Thanks Max this looks much better! David > Thanks, > Max > > On 4/18/2016 9:43 AM, Marcus Larsson wrote: >> >> >> On 04/18/2016 03:33 PM, Coleen Phillimore wrote: >>> >>> >>> On 4/15/16 10:37 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 04/15/2016 04:29 PM, Coleen Phillimore wrote: >>>>> >>>>> Max, >>>>> >>>>> I got this confused when looking at this because of the names. >>>>> >>>>> *+ STEP(395, "(printing log configuration)")* >>>>> *+ if (_verbose){* >>>>> *+ st->print_cr("Logging:");* >>>>> *+ LogConfiguration::describe_no_lock(st);* >>>>> *+ LogConfiguration::describe_with_lock(st);* >>>>> *+ st->cr();* >>>>> *+ }* >>>>> *+ * >>>>> >>>>> I was thinking "wait, you don't want the lock here!" >>>>> >>>>> I think describe_no_lock() should be named >>>>> describe_available_log_levels() >>>>> >>>>> describe_with_lock() should be names describe_log_configuration(). >>>>> >>>>> describe() should call these with the lock for the latter. >>>> >>>> In that case, can we make it describe_available() and >>>> describe_outputs()? The first function doesn't only describe levels. >>> >>> describe_available() seems better. It seems that describe_outputs() >>> isn't descriptive, why not describe_[current]_configuration(). >> >> I just figured we could skip the "configuration" part of it since >> we're already in the scope of LogConfiguration::. I'm fine with >> describe_[current]_configuration(), it's no big deal. >> >> Thanks, >> Marcus >> >>> >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> On 4/15/16 3:54 AM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 04/14/2016 06:22 PM, Max Ockner wrote: >>>>>>> new webrev: >>>>>>> http://cr.openjdk.java.net/~mockner/8151526.05/ >>>>>> >>>>>> logConfiguration.cpp: >>>>>> unnecessary #include on line 39 >>>>>> >>>>>> logConfiguration.hpp: >>>>>> typo in comment, 'ad' -> 'and' >>>>>> >>>>>> I don't need to see a new webrev for this. Thanks for fixing! >>>>>> >>>>>> Marcus >>>>>> >>>>>>> - new describe_* methods are now private >>>>>>> - VMError is now a friend class in logConfiguration. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>>>>>>> Hello, >>>>>>>>> I have made these changes. >>>>>>>>> - refactored describe into a portion which uses locking and >>>>>>>>> one that does not. >>>>>>>>> - in the print_vm_info function in vmError.cpp, describe() is >>>>>>>>> used, since this function is called while the program is running. >>>>>>>>> - in the report function, the describe_no_lock and >>>>>>>>> describe_with_lock functions are both used without taking a >>>>>>>>> lock. If it doesnt crash, then fantastic. If it does crash, the >>>>>>>>> error handler will skip this step anyway. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>>>>>>> >>>>>>>> I suggest making the new two functions private in >>>>>>>> LogConfiguration, and friending VMError, instead of keeping them >>>>>>>> public. That should reduce confusion about which describe-method >>>>>>>> to use, and prevent misuse of the describe_with_lock in other >>>>>>>> places. >>>>>>>> >>>>>>>> Otherwise this looks good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>>>>>>> Hey, >>>>>>>>>> >>>>>>>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>>>>>>> Marcus, >>>>>>>>>>> >>>>>>>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>>>>>>> configuration during a crash without lock and it crashes, the >>>>>>>>>>> error handler will eat it up and start at the next step. It >>>>>>>>>>> would be fun to write a locking mechanism, but this seems >>>>>>>>>>> better to me. >>>>>>>>>>> >>>>>>>>>>> I will continue to call describe() from VM.info, but I will >>>>>>>>>>> refactor the code in describe so that all of the information >>>>>>>>>>> can be printed easily without taking a lock. For a crash, >>>>>>>>>>> I'll use the refactored print functions to print all the >>>>>>>>>>> necessary information without taking a lock. Even if the vm >>>>>>>>>>> crashes during this step it is not such a bad thing because >>>>>>>>>>> of the robust error handler. >>>>>>>>>> >>>>>>>>>> Alright, that sounds good! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>>>>>>> Hello again, >>>>>>>>>>>>> >>>>>>>>>>>>> I have looked into this and I see a possible workaround to >>>>>>>>>>>>> the issue raised by Marcus: >>>>>>>>>>>>> >>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>>>> the error >>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>> already holds >>>>>>>>>>>>> the lock. Unsure how to resolve this, because skipping >>>>>>>>>>>>> to take >>>>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> My proposed solution is this: >>>>>>>>>>>>> >>>>>>>>>>>>> If the ConfigurationLock is held by another thread during >>>>>>>>>>>>> the crash, then I think we could print "Log configuration >>>>>>>>>>>>> can not be accessed because ConfigurationLock is currently >>>>>>>>>>>>> held by another thread" or something similar. If the >>>>>>>>>>>>> ConfigurationLock can be taken by the current thread, then >>>>>>>>>>>>> print the configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> We can accomplish this as follows: >>>>>>>>>>>>> >>>>>>>>>>>>> In *logConfiguration.cpp*: Create a ConfigurationLockMaybe >>>>>>>>>>>>> class extending ConfigurationLock. >>>>>>>>>>>>> >>>>>>>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>>>>>>> private: >>>>>>>>>>>>> bool _success; >>>>>>>>>>>>> public: >>>>>>>>>>>>> ConfigurationLockMaybe() { >>>>>>>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>>>>>>> } >>>>>>>>>>>>> ~ConfigurationLock() { >>>>>>>>>>>>> if(_success){_semaphore.signal();} >>>>>>>>>>>>> } >>>>>>>>>>>>> bool has_lock(){return _success;} >>>>>>>>>>>>> }; >>>>>>>>>>>>> >>>>>>>>>>>>> _semaphore is a static var in ConfigurationLock, so the >>>>>>>>>>>>> same copy is accessed in child classes. >>>>>>>>>>>>> >>>>>>>>>>>>> Another method >>>>>>>>>>>>> LogConfiguration::describe_on_crash(outputStream* out) can >>>>>>>>>>>>> use ConfigurationLockMaybe to attempt to print the >>>>>>>>>>>>> configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>>>>>>> LogConfiguration::describe_on_crash. >>>>>>>>>>>> >>>>>>>>>>>> Sounds good to me. >>>>>>>>>>>> >>>>>>>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have a >>>>>>>>>>>> better suggestion. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Marcus >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Do we really need a list of all tags and all >>>>>>>>>>>>>>>>>>> decorators? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Just going by what we currently put in the hs_err >>>>>>>>>>>>>>>>>> file, I think >>>>>>>>>>>>>>>>>> this may be the first "Do we really need" we've >>>>>>>>>>>>>>>>>> ever asked for >>>>>>>>>>>>>>>>>> this type of change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> All joking aside, I think it is a good idea to >>>>>>>>>>>>>>>>>> direct users >>>>>>>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also: I assume what you print is the Log state as >>>>>>>>>>>>>>>>>>> it is at the >>>>>>>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. >>>>>>>>>>>>>>>>>>> with jcmd, >>>>>>>>>>>>>>>>>>> would it be possible to see that? At least a >>>>>>>>>>>>>>>>>>> warning if >>>>>>>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>>>>>>> require a >>>>>>>>>>>>>>>>>> framework change. It does not look like any marks >>>>>>>>>>>>>>>>>> are made when >>>>>>>>>>>>>>>>>> the LogConfiguration changes during runtime, and >>>>>>>>>>>>>>>>>> we would need >>>>>>>>>>>>>>>>>> to record that in order to know what to print when >>>>>>>>>>>>>>>>>> we dump into >>>>>>>>>>>>>>>>>> hs_err. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, this would required the framework to keep some >>>>>>>>>>>>>>>>> sort of log >>>>>>>>>>>>>>>>> of configuration changes. Is there value in knowing >>>>>>>>>>>>>>>>> that the log >>>>>>>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think it is useful along with other information. >>>>>>>>>>>>>>>> An example case: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Let's say we are logging a message whenever a lock >>>>>>>>>>>>>>>> is acquired or >>>>>>>>>>>>>>>> released. In a subsystem like this, the action which >>>>>>>>>>>>>>>> dooms the vm >>>>>>>>>>>>>>>> may not cause an immediate crash. This leaves time >>>>>>>>>>>>>>>> for logging to >>>>>>>>>>>>>>>> turn on or off in between the bad action and the >>>>>>>>>>>>>>>> crash. If you >>>>>>>>>>>>>>>> don't know when logging was active and when it was >>>>>>>>>>>>>>>> not, then the >>>>>>>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>>>>>>> information. You may not see the message that has >>>>>>>>>>>>>>>> the answer for >>>>>>>>>>>>>>>> you because it was not logged, though the action may >>>>>>>>>>>>>>>> have occurred. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, if we don't have the framework support for >>>>>>>>>>>>>>>> this then I >>>>>>>>>>>>>>>> believe it should be added later. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is a good example. A small easy solution, as I >>>>>>>>>>>>>>>> mentioned before, could be just to distinguish between >>>>>>>>>>>>>>>> "logging parameters stable since startup" and "logging >>>>>>>>>>>>>>>> parameters changed at some time". That way you would at >>>>>>>>>>>>>>>> least know whether to trust the logging output. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've filed >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Max: Did you see my comments about the ConfigurationLock? >>>>>>>>>>>>>>> It was an inline reply to your first mail. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> Please review another Unified Logging change. >>>>>>>>>>>>>>>>>>> They are >>>>>>>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>>>>>> might be problematic for the error handler. I >>>>>>>>>>>>>>>>> suppose the error >>>>>>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>>>>>> already holds >>>>>>>>>>>>>>>>> the lock. Unsure how to resolve this, because >>>>>>>>>>>>>>>>> skipping to take >>>>>>>>>>>>>>>>> the lock means that we might crash due to another >>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The logging configuration is now printed in >>>>>>>>>>>>>>>>>>> each hs_err >>>>>>>>>>>>>>>>>>> file. The output is the same as you would see >>>>>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Below is a sample of the hs_err contents. The >>>>>>>>>>>>>>>>>>> Logging info >>>>>>>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, >>>>>>>>>>>>>>>>>>> and before >>>>>>>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>>>>>>> Available log levels: off, trace, debug, >>>>>>>>>>>>>>>>>>> info, warning, error >>>>>>>>>>>>>>>>>>> Available log decorators: time (t), uptime >>>>>>>>>>>>>>>>>>> (u), timemillis >>>>>>>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), >>>>>>>>>>>>>>>>>>> tags (tg) >>>>>>>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>>>>>>> bot, census, classhisto, classresolve, >>>>>>>>>>>>>>>>>>> classinit, >>>>>>>>>>>>>>>>>>> classload, classloaderdata, classunload, >>>>>>>>>>>>>>>>>>> classpath, >>>>>>>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>>>>>>> monitorinflation, os, phases, plab, >>>>>>>>>>>>>>>>>>> promotion, preorder, >>>>>>>>>>>>>>>>>>> protectiondomain, ref, refine, region, >>>>>>>>>>>>>>>>>>> remset, safepoint, >>>>>>>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, >>>>>>>>>>>>>>>>>>> stacktrace, start, >>>>>>>>>>>>>>>>>>> startuptime, state, stats, stringdedup, >>>>>>>>>>>>>>>>>>> stringtable, >>>>>>>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>>>>>>> verboseverification, verify, vmoperation, >>>>>>>>>>>>>>>>>>> vtables >>>>>>>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From alexander.kulyakhtin at oracle.com Tue Apr 5 11:54:09 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 5 Apr 2016 04:54:09 -0700 (PDT) Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Message-ID: Hi Cheleswer, I doubt Thread.sleep() can ensure a program state. As Philip has pointed out, some synchronization object would, probably, be more appropriate. + // Ensuring that Jstack will always run after NamedThread is started + Thread.sleep(2000); Best regards, Alexander ----- Original Message ----- From: cheleswer.sahu at oracle.com To: hotspot-runtime-dev at openjdk.java.net, serviceability-dev at openjdk.java.net Sent: Tuesday, April 5, 2016 1:23:57 PM GMT +03:00 Iraq Subject: RFR[9u-dev]: 8153319: new test serviceability/tmtools/jstack/JstackThreadTest.java fails Hi, Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8153319 . Webrev link: http://cr.openjdk.java.net/~csahu/8153319/ Bug Brief: Test is failing on some platforms. Problem Identified: Newly created child thread (NamedThread) is finished its execution before main thread calls ?jstack?, which result in test failure. Solution Proposed: Set the child thread in sleep state for forever and make sure that ?jstack ? tool always gets executed after ? NamedThread? is started. Regards, Cheleswer From pbenedict at apache.org Wed Apr 13 18:03:38 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 13 Apr 2016 13:03:38 -0500 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <0980D0EB-BAF1-4C76-9A82-D3F6BCCFA423@oracle.com> References: <570E690B.2060703@oracle.com> <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> <570E81A0.5050904@oracle.com> <0980D0EB-BAF1-4C76-9A82-D3F6BCCFA423@oracle.com> Message-ID: Since getCallerClass will be removed in 10, @Deprecated should also have its condemned=true Cheers, Paul On Wed, Apr 13, 2016 at 12:43 PM, Mandy Chung wrote: > > > On Apr 13, 2016, at 10:28 AM, Chris Hegarty > wrote: > > > > Mandy, > > > > On 13/04/16 18:15, Mandy Chung wrote: > >> > >>> On Apr 13, 2016, at 8:43 AM, Chris Hegarty > wrote: > >>> > >>> This review is for the second significant part of the changes for JEP > >>> 260 [1]. When created, the jdk.unsupported module [2] initially > >>> contained the sun.misc package. This issue is will move all the > >>> non-Critical APIs out of sun.reflect, leaving only the critical ones, > at > >>> which point sun.reflect can be moved to the jdk.unsupported module. > >>> > >>> http://cr.openjdk.java.net/~chegar/8137058/ > >>> https://bugs.openjdk.java.net/browse/JDK-8137058 > >>> > >>> Summary of the changes: > >>> > >>> - Move all existing sun.reflect types to jdk.internal.reflect, and > >>> fix up references in the libraries, and the VM, to use the new internal > >>> location. > >> > >> I hope the getCallerClass(int depth) method is moved out of > jdk.internal.reflect.Reflection. JDK is not using it and it?s retained for > existing libraries to migrate to the new StackWalker API. Of course the > cost is to add a native library and the build infra work has made this > straight-forward. > > > > In my patch jdk.internal.reflect.Reflection.getCallerClass(int) > > is retained only to avoid the need for an unsupported.so, but > > if you feel strongly that is should go, then I can make the > > change. > > I?m less concerned of a native library but its name led me to have a > second thought. I can leave with keeping > jdk.internal.reflect.Reflection::getCallerClass(int depth) for another > reason. > > > > >> I agree with Alan that the @deprecated javadoc of > sun.reflect.Reflection::getCallerClass should be updated to make it clear. > What about: > >> > >> /** > >> * @deprecated This method is an internal API and will be removed in > JDK 10. > >> * Use {@link StackWalker} to walk the stack and obtain the caller class > >> * with {@link StackWalker.StackFrame#getDeclaringClass} instead. > >> */ > > > > That seems reasonable. The version number should be present > > in the @Deprecated forRemoval element too. I'll make the change. > > Thanks. > > > > >> This patch will likely impact existing libraries that filter out > reflection frames (IIRC Groovy and log4j may be examples) doing > Class::getName().startsWith(?sun.reflect?). It may worth call out this > incompatibility in JEP 260. > > > > I'll add a note. > > > >> StackStreamFactory.java shows an example: > >> > >> 1085 if (c.getName().startsWith("sun.reflect") && > >> > >> This should be changed to ?jdk.internal.reflect?. > > > > Ah I missed this. Strangely all tests are passing without > > this change. I'll make the change. > > This is just like an assertion that should never reach there. It throws an > internal error if a class starts with sun.reflect but not a reflective > method. > > > > >> test/java/lang/StackWalker/EmbeddedStackWalkTest.java and maybe a few > other stack walker tests. You may want to check any other of any similar > pattern in the JDK code/tests (I think I got them all) > > > > I did update some StackWalker tests, but missed this one ( it > > passes for me ). I'll check all of them. > > It may be a check with several conditions or assertion like the above. > > Mandy From joel.borggren.franck at gmail.com Wed Apr 13 20:44:51 2016 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Wed, 13 Apr 2016 20:44:51 +0000 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <570E690B.2060703@oracle.com> References: <570E690B.2060703@oracle.com> Message-ID: Hi Chris, FWIW changes looks good to me. cheers /Joel On Wed, 13 Apr 2016 at 17:43 Chris Hegarty wrote: > This review is for the second significant part of the changes for JEP > 260 [1]. When created, the jdk.unsupported module [2] initially > contained the sun.misc package. This issue is will move all the > non-Critical APIs out of sun.reflect, leaving only the critical ones, at > which point sun.reflect can be moved to the jdk.unsupported module. > > http://cr.openjdk.java.net/~chegar/8137058/ > https://bugs.openjdk.java.net/browse/JDK-8137058 > > Summary of the changes: > > - Move all existing sun.reflect types to jdk.internal.reflect, and > fix up references in the libraries, and the VM, to use the new internal > location. > > - Update tests, as appropriate, to use the new location. > > - Add the minimal set of critical APIs to jdk.unsupported/sun.reflect. > These ultimately delegate to the internal versions. Additionally, a > few new tests have been added to exercise these. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8132928 > [2] https://bugs.openjdk.java.net/browse/JDK-8153737 > From kevin.rushforth at oracle.com Wed Apr 13 21:34:25 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 13 Apr 2016 14:34:25 -0700 Subject: RFR [9] 8137058: Clear out all non-Critical APIs from sun.reflect and move to jdk.unsupported In-Reply-To: <570E81A0.5050904@oracle.com> References: <570E690B.2060703@oracle.com> <5C58C15B-48AA-4AA1-8C10-45268968B1BB@oracle.com> <570E81A0.5050904@oracle.com> Message-ID: <570EBB61.4010008@oracle.com> Hi, Chris Hegarty wrote: > Mandy, > > On 13/04/16 18:15, Mandy Chung wrote: >> >>> On Apr 13, 2016, at 8:43 AM, Chris Hegarty >>> wrote: >>> >>> This review is for the second significant part of the changes for JEP >>> 260 [1]. When created, the jdk.unsupported module [2] initially >>> contained the sun.misc package. This issue is will move all the >>> non-Critical APIs out of sun.reflect, leaving only the critical >>> ones, at >>> which point sun.reflect can be moved to the jdk.unsupported module. >>> >>> http://cr.openjdk.java.net/~chegar/8137058/ >>> https://bugs.openjdk.java.net/browse/JDK-8137058 >>> >>> Summary of the changes: >>> >>> - Move all existing sun.reflect types to jdk.internal.reflect, and >>> fix up references in the libraries, and the VM, to use the new internal >>> location. >> >> I hope the getCallerClass(int depth) method is moved out of >> jdk.internal.reflect.Reflection. JDK is not using it and it?s >> retained for existing libraries to migrate to the new StackWalker >> API. Of course the cost is to add a native library and the build >> infra work has made this straight-forward. > > In my patch jdk.internal.reflect.Reflection.getCallerClass(int) > is retained only to avoid the need for an unsupported.so, but > if you feel strongly that is should go, then I can make the > change. > >> I agree with Alan that the @deprecated javadoc of >> sun.reflect.Reflection::getCallerClass should be updated to make it >> clear. What about: >> >> /** >> * @deprecated This method is an internal API and will be removed in >> JDK 10. >> * Use {@link StackWalker} to walk the stack and obtain the caller >> class >> * with {@link StackWalker.StackFrame#getDeclaringClass} instead. >> */ > > That seems reasonable. The version number should be present > in the @Deprecated forRemoval element too. I'll make the change. > >> This patch will likely impact existing libraries that filter out >> reflection frames (IIRC Groovy and log4j may be examples) doing >> Class::getName().startsWith(?sun.reflect?). It may worth call out >> this incompatibility in JEP 260. > > I'll add a note. > >> StackStreamFactory.java shows an example: >> >> 1085 if (c.getName().startsWith("sun.reflect") && >> >> This should be changed to ?jdk.internal.reflect?. > > Ah I missed this. Strangely all tests are passing without > this change. I'll make the change. > >> test/java/lang/StackWalker/EmbeddedStackWalkTest.java and maybe a few >> other stack walker tests. You may want to check any other of any >> similar pattern in the JDK code/tests (I think I got them all) > > I did update some StackWalker tests, but missed this one ( it > passes for me ). I'll check all of them. > >> The hotspot change drops the package name prefix in javaClasses.hpp >> which is inconsistent with other classes. I found including >> jdk_internal_reflect_ in the class name is useful. Coleen and >> others from the hotspot team may have opinion on this. > > Ok. > >> FX will need to adjust for this patch (cc?ing Kevin to prepare for this) > > Ah ok, thanks for copying Kevin. Yes, thanks Mandy. JavaFX uses sun.reflect.CallerSensitive and sun.reflect.Reflection (both in FXML) so I will file an FX bug to track the need to fix the module dependences. -- Kevin > I'll send a note to the list once the webrev is updated. > > -Chris. From david.holmes at oracle.com Tue Apr 19 00:12:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 10:12:27 +1000 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> <5714E416.6030300@redhat.com> Message-ID: <571577EB.1080907@oracle.com> On 19/04/2016 2:23 AM, Volker Simonis wrote: > We've looked at the proposed changes and we are pretty sure that the > cmpxchg done during copy_to_survivor_space in the parallel GC doesn't > require the full fence/acquire semantics. But we also agree that this > should not be ifdefed PPC64 in shared code. > > Andrews suggestion of using the new C++11 atomic memory operators is > good, although in practice it may be hard to get all the different > compilers under the hood. > > But now that we've even got the corresponding cmpxchg routines with > various acquire/release semantics in Java-land in the new > jdk.internal.Unsafe package, it would be a pity if it would not be > possible to use that functionality within the Hotspot. > > I think one approach to enable an easy transition would be to do the > proposed enhancements (or something similar) to cmpxchg > unconditionally in atomic.hpp. For example instead of two extra > boolean parameters we could use an enum similar to the one in > library_call.cpp: > > typedef enum { Relaxed, Opaque, Volatile, Acquire, Release } AccessKind; > > The default value of this parameter should of course be conservative > (i.e. Volatile) so we don't change the current behavior. After that > individual, performance critical callers of these routines can be > examined if they really require the most conservative setting and > maybe optimized. > > What do you think? I think expanding our Atomic and OrderAccess API's to align with the C++11 atomic and memory-ordering APIs is a good thing to do - even if we don't actually switch to direct compiler support for a while yet. It may be challenging to efficiently implement all of the C++11 semantics directly in the meantime. However this is too late for JDK 9 I think, with FC (for hotspot) on May 12. Though addressing the immediate concern, without trying to generalize to full C++11 semantic support may be feasible - eg add a "relaxed cas" for use in one or two particular pieces of code. Thanks, David > Regards, > Martin and Volker > > On Mon, Apr 18, 2016 at 3:41 PM, Andrew Haley wrote: >> On 04/18/2016 02:01 PM, Carsten Varming wrote: >>> An important question is: Should the shared parts of hotspot move towards >>> weaker memory models? If yes, then everybody should review code assuming >>> the weaker semantics. If no, then there really isn't room for patches like >>> this one :(. >> >> This would surely be useful. For example, the bitmap marking uses a >> two-way acquire and release barrier at the moment, and I'm fairly sure >> we don't need that. >> >> I don't think this change should be #ifdef PPC64. That disadvantages >> other targets such as AArch64, to no advantage. I understand that >> moving this to shared code requires more work, but we should do at >> least some of it in the JDK9 timeframe. >> >> C++11 has a considerably greater variety of atomic memory operators >> than the ones in HotSpot. Over time I believe we should migrate to >> C++11-like operators in our code base. One way to do this would be to >> create new operators which map in a simple way onto the standard ones. >> The we can get rid of much of this inline assembly code. >> >> Andrew. From david.holmes at oracle.com Tue Apr 19 05:04:37 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 15:04:37 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> Message-ID: <5715BC65.3010302@oracle.com> Hi Yasumasa, Thanks for persevering with this to get it into the current form. Sorry I haven't been able to do a detailed review until now. On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: > Hi Gerard, > > 2016/04/19 3:14 "Gerard Ziemski" >: > > > > hi Yasumasa, > > > > Nice work. I have 2 questions: > > > > ======== > > File: java.c > > > > #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? > after every single JNI call? In this example instead of NULL_CHECK, > should we be using CHECK_EXCEPTION_NULL_LEAVE macro? > > It is not critical if we encounter error at JNI function call because > we cannot set native thread name only. > So I think that we do not need to leave from launcher process. I agree we do not need to abort if an exception occurs (and in fact I don't think an exception is even possible from this code), but we should ensure any pending exception is cleared before any futher JNI calls might be made. Note that NULL_CHECK is already used extensively throughout the launcher code - so if this usage is wrong then it is all wrong! More on this code below ... Other comments: hotspot/src/share/vm/prims/jvm.cpp Please add a comment to the method now that you removed the internal comment: // Sets the native thread name for a JavaThread. If specifically // requested JNI-attached threads can also have their native name set; // otherwise we do not modify JNI-attached threads as it may interfere // with the application that created them. --- jdk/src/java.base/share/classes/java/lang/Thread.java Please add the following comments: + // Don't modify JNI-attached threads setNativeName(name, false); + // May be called directly via JNI or reflection (when permitted) to + // allow JNI-attached threads to set their native name private native void setNativeName(String name, boolean allowAttachedThread); --- jd/src/java.base/share/native/libjli/java.c 328 #define LEAVE() \ 329 SetNativeThreadName(env, "DestroyJavaVM"); \ I was going to suggest this be set later, but realized we have to be attached to do this and that happens inside DestroyJavaVM. :) + /* Set native thread name. */ + SetNativeThreadName(env, "main"); The comment is redundant given the name of the method. That aside I'm not sure why you do this so late in the process, I would have done it immediately after here: 386 if (!InitializeJVM(&vm, &env, &ifn)) { 387 JLI_ReportErrorMessage(JVM_ERROR1); 388 exit(1); 389 } + SetNativeThreadName(env, "main"); + /** + * Set native thread name as possible. + */ Other than the as->if change I'm unclear where the "possible" bit comes into play - why would it not be possible? 1705 NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); 1706 NULL_CHECK(currentThreadID = (*env)->GetStaticMethodID(env, cls, 1707 "currentThread", "()Ljava/lang/Thread;")); 1708 NULL_CHECK(currentThread = (*env)->CallStaticObjectMethod(env, cls, 1709 currentThreadID)); 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, cls, 1711 "setNativeName", "(Ljava/lang/String;Z)V")); 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, 1714 nameString, JNI_TRUE); As above NULL_CHECK is fine here, but we should check for and clear any pending exception after CallVoidMethod. One thing I dislike about the current structure is that we have to go from char* to java.lang.String to call setNativeName which then calls JVM_SetNativeThreadName which converts the j.l.String back to a char* ! Overall I wonder about the affect on startup cost. But if there is an issue we can revisit this. Thanks, David ----- > > #2 Should the comment for ?SetNativeThreadName? be ?Set native thread > name if possible.? not "Set native thread name as possible.?? > > Sorry for my bad English :-) > > Thanks, > > Yasumasa > > > cheers > > > > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga > wrote: > > > > > > Hi David, > > > > > > I uploaded new webrev: > > > > > > - hotspot: > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ > > > > > > - jdk: > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ > > > > > > > > >> it won't work unless you change the semantics of setName so I'm > not sure what you were thinking here. To take advantage of an arg taking > JVM_SetNativThreadName you would need to call it directly as no Java > code will call it . ??? > > > > > > I added a flag for setting native thread name to JNI-attached thread. > > > This change can set native thread name if main thread changes to > JNI-attached thread. > > > > > > > > > Thanks, > > > > > > Yasumasa > > > > > > > > > On 2016/04/16 16:11, David Holmes wrote: > > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: > > >>> Hi David, > > >>> > > >>>> That change in behaviour may be a problem, it could be considered a > > >>>> regression that setName stops setting the native thread main, even > > >>>> though we never really intended it to work in the first place. > :( Such > > >>>> a change needs to go through CCC. > > >>> > > >>> I understood. > > >>> Can I send CCC request? > > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) > > >> > > >> Sorry you can't file a CCC request, you would need a sponsor for > that. But at this stage I don't think I agree with the proposed change > because of the change in behaviour - there's no way to restore the > "broken" behaviour. > > >> > > >>> I want to continue to discuss about it on JDK-8154331 [1]. > > >> > > >> Okay we can do that. > > >> > > >>> > > >>>> Further, we expect the launcher to use the supported JNI > interface (as > > >>>> other processes would), not the internal JVM interface that > exists for > > >>>> the JDK sources to communicate with the JVM. > > >>> > > >>> I think that we do not use JVM interface if we add new method in > > >>> LauncherHelper as below: > > >>> ---------------- > > >>> diff -r f02139a1ac84 > > >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java > > >>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java > > >>> Wed Apr 13 14:19:30 2016 +0000 > > >>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java > > >>> Sat Apr 16 11:25:53 2016 +0900 > > >>> @@ -960,4 +960,8 @@ > > >>> else > > >>> return md.toNameAndVersion() + " (" + loc + ")"; > > >>> } > > >>> + > > >>> + static void setNativeThreadName(String name) { > > >>> + Thread.currentThread().setName(name); > > >>> + } > > >> > > >> You could also make that call via JNI directly, so not sure the > helper adds much here. But it won't work unless you change the semantics > of setName so I'm not sure what you were thinking here. To take > advantage of an arg taking JVM_SetNativThreadName you would need to call > it directly as no Java code will call it . ??? > > >> > > >> David > > >> ----- > > >> > > >>> } > > >>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c > > >>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 > > >>> 2016 +0000 > > >>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 > > >>> 2016 +0900 > > >>> @@ -125,6 +125,7 @@ > > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); > > >>> static void ShowSettings(JNIEnv* env, char *optString); > > >>> static void ListModules(JNIEnv* env, char *optString); > > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); > > >>> > > >>> static void SetPaths(int argc, char **argv); > > >>> > > >>> @@ -325,6 +326,7 @@ > > >>> * mainThread.isAlive() to work as expected. > > >>> */ > > >>> #define LEAVE() \ > > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ > > >>> do { \ > > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ > > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ > > >>> @@ -488,6 +490,9 @@ > > >>> mainArgs = CreateApplicationArgs(env, argv, argc); > > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); > > >>> > > >>> + /* Set native thread name. */ > > >>> + SetNativeThreadName(env, "main"); > > >>> + > > >>> /* Invoke main method. */ > > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); > > >>> > > >>> @@ -1686,6 +1691,22 @@ > > >>> joptString); > > >>> } > > >>> > > >>> +/** > > >>> + * Set native thread name as possible. > > >>> + */ > > >>> +static void > > >>> +SetNativeThreadName(JNIEnv *env, char *name) > > >>> +{ > > >>> + jmethodID setNativeThreadNameID; > > >>> + jstring nameString; > > >>> + jclass cls = GetLauncherHelperClass(env); > > >>> + NULL_CHECK(cls); > > >>> + NULL_CHECK(setNativeThreadNameID = > (*env)->GetStaticMethodID(env, cls, > > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); > > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); > > >>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, > > >>> nameString); > > >>> +} > > >>> + > > >>> /* > > >>> * Prints default usage or the Xusage message, see > > >>> sun.launcher.LauncherHelper.java > > >>> */ > > >>> ---------------- > > >>> > > >>> So I want to add new arg to JVM_SetNativeThreadName(). > > >>> > > >>>> However this is still a change to the exported JVM interface and so > > >>>> has to be approved. > > >>> > > >>> Do you mean that this change needs CCC? > > >>> > > >>> > > >>> Thanks, > > >>> > > >>> Yasumasa > > >>> > > >>> > > >>> [1] > > >>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html > > >>> > > >>> > > >>> > > >>> On 2016/04/16 7:26, David Holmes wrote: > > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: > > >>>>> Hi David, > > >>>>> > > >>>>>> I think it is a bug based on the comment here: > > >>>>>> > > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main > thread and > > >>>>>> JNI attached threads > > >>>>> > > >>>>> I filed it to JBS as JDK-8154331. > > >>>>> I will send review request to hotspot-runtime-dev. > > >>>>> > > >>>>> > > >>>>>> Though that will introduce a change in behaviour by itself as > setName > > >>>>>> will no longer set the native name for the main thread. > > >>>>> > > >>>>> I know. > > >>>> > > >>>> That change in behaviour may be a problem, it could be considered a > > >>>> regression that setName stops setting the native thread main, even > > >>>> though we never really intended it to work in the first place. > :( Such > > >>>> a change needs to go through CCC. > > >>>> > > >>>>> I checked changeset history. > > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is > > >>>>> backported JDK 8. > > >>>> > > >>>> Yes this all came in as part of the OSX port in 7u2. > > >>>> > > >>>>> However, this function seems to be called from > Thread#setNativeName() > > >>>>> only. > > >>>>> In addition, Thread#setNativeName() is private method. > > >>>>> > > >>>>> Thus I think that we can add an argument to > JVM_SetNativeThreadName() > > >>>>> for force setting. > > >>>>> (e.g. "bool forced") > > >>>>> > > >>>>> It makes a change of JVM API. > > >>>>> However, this function is NOT public, so I think we can add one > more > > >>>>> argument. > > >>>>> > > >>>>> What do you think about this? > > >>>>> If it is accepted, we can set native thread name from Java > launcher. > > >>>> > > >>>> The private/public aspect of the Java API is not really at > issue. Yes > > >>>> we would add another arg to the JVM function to allow it to apply to > > >>>> JNI-attached threads as well (I'd prefer the arg reflect that > not just > > >>>> "force"). However this is still a change to the exported JVM > interface > > >>>> and so has to be approved. Further, we expect the launcher to > use the > > >>>> supported JNI interface (as other processes would), not the internal > > >>>> JVM interface that exists for the JDK sources to communicate > with the > > >>>> JVM. > > >>>> > > >>>> David > > >>>> ----- > > >>>> > > >>>>> > > >>>>> Thanks, > > >>>>> > > >>>>> Yasumasa > > >>>>> > > >>>>> > > >>>>> On 2016/04/15 19:16, David Holmes wrote: > > >>>>>> Hi Yasumasa, > > >>>>>> > > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: > > >>>>>>> Hi David, > > >>>>>>> > > >>>>>>>> The fact that the "main" thread is not tagged as being a > JNI-attached > > >>>>>>>> thread seems accidental to me > > >>>>>>> > > >>>>>>> Should I file it to JBS? > > >>>>>> > > >>>>>> I think it is a bug based on the comment here: > > >>>>>> > > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main > thread and > > >>>>>> JNI attached threads > > >>>>>> > > >>>>>> Though that will introduce a change in behaviour by itself as > setName > > >>>>>> will no longer set the native name for the main thread. > > >>>>>> > > >>>>>>> I think that we can fix as below: > > >>>>>>> --------------- > > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp > > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 > 2016 +0200 > > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 > 2016 +0900 > > >>>>>>> @@ -3592,7 +3592,7 @@ > > >>>>>>> #endif // INCLUDE_JVMCI > > >>>>>>> > > >>>>>>> // Attach the main thread to this os thread > > >>>>>>> - JavaThread* main_thread = new JavaThread(); > > >>>>>>> + JavaThread* main_thread = new JavaThread(true); > > >>>>>>> main_thread->set_thread_state(_thread_in_vm); > > >>>>>>> main_thread->initialize_thread_current(); > > >>>>>>> // must do this before set_active_handles > > >>>>>>> @@ -3776,6 +3776,9 @@ > > >>>>>>> // Notify JVMTI agents that VM initialization is complete > - nop if > > >>>>>>> no agents. > > >>>>>>> JvmtiExport::post_vm_initialized(); > > >>>>>>> > > >>>>>>> + // Change attach status to "attached" > > >>>>>>> + main_thread->set_done_attaching_via_jni(); > > >>>>>>> + > > >>>>>> > > >>>>>> I think we can do this straight after the JavaThread constructor. > > >>>>>> > > >>>>>>> if (TRACE_START() != JNI_OK) { > > >>>>>>> vm_exit_during_initialization("Failed to start tracing > > >>>>>>> backend."); > > >>>>>>> } > > >>>>>>> --------------- > > >>>>>>> > > >>>>>>> > > >>>>>>>> If it wants to name its native threads then it is free to do so, > > >>>>>>> > > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change native > thread name > > >>>>>>> when the caller thread is JNI-attached thread. > > >>>>>>> However, I think that it should be changed if Java developer > calls > > >>>>>>> Thread#setName() explicitly. > > >>>>>>> It is not the same of changing native thread name at > > >>>>>>> Threads::create_vm(). > > >>>>>>> > > >>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. > > >>>>>>> What do you think about this? > > >>>>>> > > >>>>>> The decision to not change the name of JNI-attached threads was a > > >>>>>> deliberate one** - this functionality originated with the OSX > port and > > >>>>>> it was reported that the initial feedback with this feature was to > > >>>>>> ensure it didn't mess with thread names that had been set by > the host > > >>>>>> process. If we do as you propose then we will just have an > > >>>>>> inconsistency for people to complain about: "why does my > native thread > > >>>>>> only have a name if I call cur.setName(cur.getName()) ?" > > >>>>>> > > >>>>>> ** If you follow the bugs and related discussions on this, the > > >>>>>> semantics and limitations (truncation, current thread only, > non-JNI > > >>>>>> threads only) of setting the native thread name were supposed > to be > > >>>>>> documented in the release notes - but as far as I can see that > never > > >>>>>> happened. :( > > >>>>>> > > >>>>>> My position on this remains that if it is desirable for the main > > >>>>>> thread (and DestroyJavaVM thread) to have native names then the > > >>>>>> launcher needs to be setting them using the available platform > APIs. > > >>>>>> Unfortunately this is complicated - as evidenced by the VM > code for > > >>>>>> this - due to the need to verify API availability. > > >>>>>> > > >>>>>> Any change in behaviour in relation to Thread.setName would > have to go > > >>>>>> through our CCC process I think. But a change in the launcher > would > > >>>>>> not. > > >>>>>> > > >>>>>> Sorry. > > >>>>>> > > >>>>>> David > > >>>>>> ----- > > >>>>>> > > >>>>>>> --------------- > > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 > 2016 +0200 > > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 > 2016 +0900 > > >>>>>>> @@ -3187,7 +3187,7 @@ > > >>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); > > >>>>>>> // Thread naming only supported for the current thread, > doesn't > > >>>>>>> work > > >>>>>>> for > > >>>>>>> // target threads. > > >>>>>>> - if (Thread::current() == thr && > !thr->has_attached_via_jni()) { > > >>>>>>> + if (Thread::current() == thr) { > > >>>>>>> // we don't set the name of an attached thread to avoid > stepping > > >>>>>>> // on other programs > > >>>>>>> const char *thread_name = > > >>>>>>> > java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); > > >>>>>>> --------------- > > >>>>>>> > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> > > >>>>>>> Yasumasa > > >>>>>>> > > >>>>>>> > > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: > > >>>>>>>>> Roger, > > >>>>>>>>> Thanks for your comment! > > >>>>>>>>> > > >>>>>>>>> David, > > >>>>>>>>> > > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like > > >>>>>>>>>>>> exposing > > >>>>>>>>>>>> a new JVM function this way. > > >>>>>>>>> > > >>>>>>>>> I tried to call Thread#setName() after initializing VM (before > > >>>>>>>>> calling > > >>>>>>>>> main method), > > >>>>>>>>> I could set native thread name. > > >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we > can't > > >>>>>>>>> set > > >>>>>>>>> native thread name for DestroyJavaVM. > > >>>>>>>> > > >>>>>>>> Right - I came to the same realization earlier this morning. > Which, > > >>>>>>>> unfortunately, takes me back to the basic premise here that > we don't > > >>>>>>>> set the name of threads not created by the JVM. The fact > that the > > >>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems > > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by > > >>>>>>>> accident for the initial attach, and can't be used for the > > >>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently > named at > > >>>>>>>> the native level. > > >>>>>>>> > > >>>>>>>> I'm afraid my view here is that the launcher has to be > treated like > > >>>>>>>> any other process that might host a JVM. If it wants to name its > > >>>>>>>> native threads then it is free to do so, but I would not be > exporting > > >>>>>>>> a function from the JVM to do that - it would have to use the OS > > >>>>>>>> specific API's for that on a platform-by-platform basis. > > >>>>>>>> > > >>>>>>>> Sorry. > > >>>>>>>> > > >>>>>>>> David > > >>>>>>>> ----- > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> Thanks, > > >>>>>>>>> > > >>>>>>>>> Yasumasa > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: > > >>>>>>>>>> Hi, > > >>>>>>>>>> > > >>>>>>>>>> Comments: > > >>>>>>>>>> > > >>>>>>>>>> jvm.h: The function names are too similar but perform > different > > >>>>>>>>>> functions: > > >>>>>>>>>> > > >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName > > >>>>>>>>>> > > >>>>>>>>>> - The first function applies to the current thread, the > second > > >>>>>>>>>> one a > > >>>>>>>>>> specific java thread. > > >>>>>>>>>> It would seem useful for there to be a comment somewhere > about > > >>>>>>>>>> what > > >>>>>>>>>> the new function does. > > >>>>>>>>>> > > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) > > >>>>>>>>>> instead of > > >>>>>>>>>> (SetNativeThreadName0_t) > > >>>>>>>>>> as is done on unix and mac. > > >>>>>>>>>> > > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: > > >>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs > used at > > >>>>>>>>>> line 730 > > >>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast > on the > > >>>>>>>>>> same > > >>>>>>>>>> line as dlsym... > > >>>>>>>>>> > > >>>>>>>>>> $.02, Roger > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: > > >>>>>>>>>>>> That is an interesting question which I haven't had time to > > >>>>>>>>>>>> check - > > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached > thread > > >>>>>>>>>>>> then > > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion > should > > >>>>>>>>>>>> work > > >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of > > >>>>>>>>>>>> JNI-attached threads :( ) > > >>>>>>>>>>> > > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed > native > > >>>>>>>>>>> thread name (test) was set. > > >>>>>>>>>>> --------- > > >>>>>>>>>>> public class Sleep{ > > >>>>>>>>>>> public static void main(String[] args) throws Exception{ > > >>>>>>>>>>> Thread.currentThread().setName("test"); > > >>>>>>>>>>> Thread.sleep(3600000); > > >>>>>>>>>>> } > > >>>>>>>>>>> } > > >>>>>>>>>>> --------- > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like > > >>>>>>>>>>>> exposing > > >>>>>>>>>>>> a new JVM function this way. > > >>>>>>>>>>> > > >>>>>>>>>>> I will update webrev after hearing Kumar's comment. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Thanks, > > >>>>>>>>>>> > > >>>>>>>>>>> Yasumasa > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: > > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: > > >>>>>>>>>>>>> Hi, > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: > > >>>>>>>>>>>>>> Hi, > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: > > >>>>>>>>>>>>>>> Hi David, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Thanks for your comment. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> I exported new JVM function to set native thread > name, and JLI > > >>>>>>>>>>>>>>> uses it > > >>>>>>>>>>>>>>> in new webrev. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> First the launcher belongs to another team so > core-libs will > > >>>>>>>>>>>>>> need to > > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Thanks! > > >>>>>>>>>>>>> I'm waiting to review :-) > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> Personally I would have used a Java upcall to > Thread.setName > > >>>>>>>>>>>>>> rather > > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes > > >>>>>>>>>>>>>> needed in > > >>>>>>>>>>>>>> that case. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in > > >>>>>>>>>>>>> Thread#init(), > > >>>>>>>>>>>>> but I could not change native thread name. > > >>>>>>>>>>>> > > >>>>>>>>>>>> At Thread.init time the thread is not alive, which is > why the > > >>>>>>>>>>>> native > > >>>>>>>>>>>> name is not set. > > >>>>>>>>>>>> > > >>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. > > >>>>>>>>>>>> > > >>>>>>>>>>>> That is an interesting question which I haven't had time to > > >>>>>>>>>>>> check - > > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached > thread > > >>>>>>>>>>>> then > > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion > should > > >>>>>>>>>>>> work > > >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of > > >>>>>>>>>>>> JNI-attached threads :( ) > > >>>>>>>>>>>> > > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like > > >>>>>>>>>>>> exposing > > >>>>>>>>>>>> a new JVM function this way. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Thanks, > > >>>>>>>>>>>> David > > >>>>>>>>>>>> ----- > > >>>>>>>>>>>> > > >>>>>>>>>>>>> Thus I think that we have to provide a function to set > native > > >>>>>>>>>>>>> thread name. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Thanks, > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Yasumasa > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> [1] > > >>>>>>>>>>>>> > https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> Thanks, > > >>>>>>>>>>>>>> David > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Could you review again? > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> - hotspot: > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> - jdk: > > >>>>>>>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Thanks, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Yasumasa > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: > > >>>>>>>>>>>>>>>> I'll answer on this original thread as well ... > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Hi Yasumasa, > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on > > >>>>>>>>>>>>>>>> vacation). > > >>>>>>>>>>>>>>>> This > > >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we > do not > > >>>>>>>>>>>>>>>> set the > > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the > > >>>>>>>>>>>>>>>> "main" > > >>>>>>>>>>>>>>>> thread. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> David > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: > > >>>>>>>>>>>>>>>>> Thanks Robbin, > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> Yasumasa > > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >: > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> /Robbin > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Thanks, looks good. > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> /Robbin > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Hi, > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. > > >>>>>>>>>>>>>>>>>>>> Could you review it? > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Thanks, > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> Yasumasa > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Hi, > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" > > > >>>>>>>>>>>>>>>>>>>>>> >>: > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, > > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >>>: > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 > > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp > > >>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu > > >>>>>>>>>>>>>>>>>>>>>> Mar 24 > > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 > > >>>>>>>>>>>>>>>>>>>>>> +0000 > > >>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu > > >>>>>>>>>>>>>>>>>>>>>> Mar 24 > > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 > > >>>>>>>>>>>>>>>>>>>>>> +0100 > > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ > > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new > JavaThread(); > > >>>>>>>>>>>>>>>>>>>>>> >> > > main_thread->set_thread_state(_thread_in_vm); > > >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); > > >>>>>>>>>>>>>>>>>>>>>> >> > + > main_thread->set_native_thread_name("main"); > > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before > set_active_handles > > >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> > main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread > name in > > >>>>>>>>>>>>>>>>>>>>>> Thread > > >>>>>>>>>>>>>>>>>>>>>> class. > > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). > > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native > > >>>>>>>>>>>>>>>>>>>>>> thread > > >>>>>>>>>>>>>>>>>>>>>> name > > >>>>>>>>>>>>>>>>>>>>>> will be > > >>>>>>>>>>>>>>>>>>>>>> set at > > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already > starte > > >>>>>>>>>>>>>>>>>>>>>> in VM. > > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in > > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). > > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name > > >>>>>>>>>>>>>>>>>>>>>> should > > >>>>>>>>>>>>>>>>>>>>>> be the > > >>>>>>>>>>>>>>>>>>>>>> same. > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like > > >>>>>>>>>>>>>>>>>>>>>> this is > > >>>>>>>>>>>>>>>>>>>>>> nicer, no? > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue > Mar 29 > > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 > > >>>>>>>>>>>>>>>>>>>>>> 2016 > > >>>>>>>>>>>>>>>>>>>>>> +0200 > > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed > Mar 30 > > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 > > >>>>>>>>>>>>>>>>>>>>>> 2016 > > >>>>>>>>>>>>>>>>>>>>>> +0200 > > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ > > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread > > >>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle > > >>>>>>>>>>>>>>>>>>>>>> thread_group, > > >>>>>>>>>>>>>>>>>>>>>> JavaThread* > > >>>>>>>>>>>>>>>>>>>>>> thread, > > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { > > >>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = > "main"; > > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = > > >>>>>>>>>>>>>>>>>>>>>> > SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> true, > > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); > > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = > > >>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); > > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ > > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), > thread); > > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), > > >>>>>>>>>>>>>>>>>>>>>> NormPriority); > > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); > > >>>>>>>>>>>>>>>>>>>>>> > - > > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = > > >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", > > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > > >>>>>>>>>>>>>>>>>>>>>> > + > > >>>>>>>>>>>>>>>>>>>>>> > + > > >>>>>>>>>>>>>>>>>>>>>> > thread->set_native_thread_name(initial_thread_name); > > >>>>>>>>>>>>>>>>>>>>>> > + > > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = > > >>>>>>>>>>>>>>>>>>>>>> > java_lang_String::create_from_str(initial_thread_name, > > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); > > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Thanks! > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and > > >>>>>>>>>>>>>>>>>>>>>> naming > > >>>>>>>>>>>>>>>>>>>>>> this > > >>>>>>>>>>>>>>>>>>>>>> thread > > >>>>>>>>>>>>>>>>>>>>>> just > > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and > thus > > >>>>>>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>>>> process) is > > >>>>>>>>>>>>>>>>>>>>>> 'java' but > > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not > > >>>>>>>>>>>>>>>>>>>>>> JavaThread. > > >>>>>>>>>>>>>>>>>>>>>> It is > > >>>>>>>>>>>>>>>>>>>>>> waiting > > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with > > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). > > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for > JavaThread. So I > > >>>>>>>>>>>>>>>>>>>>>> think that > > >>>>>>>>>>>>>>>>>>>>>> we do > > >>>>>>>>>>>>>>>>>>>>>> not > > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since > we want > > >>>>>>>>>>>>>>>>>>>>>> java and > > >>>>>>>>>>>>>>>>>>>>>> native > > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might > have > > >>>>>>>>>>>>>>>>>>>>>> some > > >>>>>>>>>>>>>>>>>>>>>> dependents. > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 > > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND > > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java > > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main > > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main > > >>>>>>>>>>>>>>>>>>>>>> Thread'. > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> I do not think so. > > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java > launcher - e.g. > > >>>>>>>>>>>>>>>>>>>>>> Apache > > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, > I think > > >>>>>>>>>>>>>>>>>>>>>> that we > > >>>>>>>>>>>>>>>>>>>>>> have to > > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. > > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> No > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> Thanks again! > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> /Robbin > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Thanks, > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> Yasumasa > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > Thanks > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > /Robbin > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> > > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin > > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa > Suenaga wrote: > > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread > name via > > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). > > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main > > >>>>>>>>>>>>>>>>>>>>>> thread is > > >>>>>>>>>>>>>>>>>>>>>> JavaThread. > > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have > > >>>>>>>>>>>>>>>>>>>>>> native > > >>>>>>>>>>>>>>>>>>>>>> thread > > >>>>>>>>>>>>>>>>>>>>>> name. > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. > > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa > > >>>>>>>>>>>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>> > > > From marcus.larsson at oracle.com Tue Apr 19 06:39:55 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 19 Apr 2016 08:39:55 +0200 Subject: RFR: 8151526: Print -Xlog configuration in the hs_err_pid file In-Reply-To: <5714FC1F.3080504@oracle.com> References: <56FAD0E3.5090508@oracle.com> <56FD679C.8070803@oracle.com> <56FE3514.5050104@oracle.com> <57080CF9.6010405@oracle.com> <570B5E29.6040709@oracle.com> <570BB367.7060408@oracle.com> <570BE0B7.4000406@oracle.com> <570CEE1D.2070306@oracle.com> <570D0DCF.9030806@oracle.com> <570D309B.5010109@oracle.com> <570E9EF4.6000406@oracle.com> <570F5514.9040805@oracle.com> <570FC3B2.4040805@oracle.com> <57109E39.4000404@oracle.com> <5710FAE5.7090000@oracle.com> <5710FCAA.8080107@oracle.com> <5714E22F.3080403@oracle.com> <5714E499.5070802@oracle.com> <5714FC1F.3080504@oracle.com> Message-ID: <5715D2BB.3010504@oracle.com> On 04/18/2016 05:24 PM, Max Ockner wrote: > http://cr.openjdk.java.net/~mockner/8151526.06/ Looks good to me as well! Thanks, Marcus > > - Renamed describe_no_lock => describe_available > - Renamed describe_with_lock => describe_current_configuration > - Removed unnecessary import of vmError in logConfiguration.cpp > - Fixed typo in comment in logConfiguration.hpp > - hs_err file now only uses describe_current_configuration, which was > the original intent of this enhancement. VM info still uses describe(). > > Thanks, > Max > > On 4/18/2016 9:43 AM, Marcus Larsson wrote: >> >> >> On 04/18/2016 03:33 PM, Coleen Phillimore wrote: >>> >>> >>> On 4/15/16 10:37 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 04/15/2016 04:29 PM, Coleen Phillimore wrote: >>>>> >>>>> Max, >>>>> >>>>> I got this confused when looking at this because of the names. >>>>> >>>>> *+ STEP(395, "(printing log configuration)")* >>>>> *+ if (_verbose){* >>>>> *+ st->print_cr("Logging:");* >>>>> *+ LogConfiguration::describe_no_lock(st);* >>>>> *+ LogConfiguration::describe_with_lock(st);* >>>>> *+ st->cr();* >>>>> *+ }* >>>>> *+ * >>>>> >>>>> I was thinking "wait, you don't want the lock here!" >>>>> >>>>> I think describe_no_lock() should be named >>>>> describe_available_log_levels() >>>>> >>>>> describe_with_lock() should be names describe_log_configuration(). >>>>> >>>>> describe() should call these with the lock for the latter. >>>> >>>> In that case, can we make it describe_available() and >>>> describe_outputs()? The first function doesn't only describe levels. >>> >>> describe_available() seems better. It seems that >>> describe_outputs() isn't descriptive, why not >>> describe_[current]_configuration(). >> >> I just figured we could skip the "configuration" part of it since >> we're already in the scope of LogConfiguration::. I'm fine with >> describe_[current]_configuration(), it's no big deal. >> >> Thanks, >> Marcus >> >>> >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> On 4/15/16 3:54 AM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 04/14/2016 06:22 PM, Max Ockner wrote: >>>>>>> new webrev: >>>>>>> http://cr.openjdk.java.net/~mockner/8151526.05/ >>>>>> >>>>>> logConfiguration.cpp: >>>>>> unnecessary #include on line 39 >>>>>> >>>>>> logConfiguration.hpp: >>>>>> typo in comment, 'ad' -> 'and' >>>>>> >>>>>> I don't need to see a new webrev for this. Thanks for fixing! >>>>>> >>>>>> Marcus >>>>>> >>>>>>> - new describe_* methods are now private >>>>>>> - VMError is now a friend class in logConfiguration. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>> On 4/14/2016 4:30 AM, Marcus Larsson wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 04/13/2016 09:33 PM, Max Ockner wrote: >>>>>>>>> Hello, >>>>>>>>> I have made these changes. >>>>>>>>> - refactored describe into a portion which uses locking and >>>>>>>>> one that does not. >>>>>>>>> - in the print_vm_info function in vmError.cpp, describe() is >>>>>>>>> used, since this function is called while the program is running. >>>>>>>>> - in the report function, the describe_no_lock and >>>>>>>>> describe_with_lock functions are both used without taking a >>>>>>>>> lock. If it doesnt crash, then fantastic. If it does crash, >>>>>>>>> the error handler will skip this step anyway. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~mockner/8151526.04 >>>>>>>> >>>>>>>> I suggest making the new two functions private in >>>>>>>> LogConfiguration, and friending VMError, instead of keeping >>>>>>>> them public. That should reduce confusion about which >>>>>>>> describe-method to use, and prevent misuse of the >>>>>>>> describe_with_lock in other places. >>>>>>>> >>>>>>>> Otherwise this looks good. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Marcus >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 4/12/2016 1:30 PM, Marcus Larsson wrote: >>>>>>>>>> Hey, >>>>>>>>>> >>>>>>>>>> On 2016-04-12 17:01, Max Ockner wrote: >>>>>>>>>>> Marcus, >>>>>>>>>>> >>>>>>>>>>> I just spoke with Coleen about this. If I attempt to print >>>>>>>>>>> configuration during a crash without lock and it crashes, >>>>>>>>>>> the error handler will eat it up and start at the next >>>>>>>>>>> step. It would be fun to write a locking mechanism, but >>>>>>>>>>> this seems better to me. >>>>>>>>>>> >>>>>>>>>>> I will continue to call describe() from VM.info, but I will >>>>>>>>>>> refactor the code in describe so that all of the information >>>>>>>>>>> can be printed easily without taking a lock. For a crash, >>>>>>>>>>> I'll use the refactored print functions to print all the >>>>>>>>>>> necessary information without taking a lock. Even if the vm >>>>>>>>>>> crashes during this step it is not such a bad thing because >>>>>>>>>>> of the robust error handler. >>>>>>>>>> >>>>>>>>>> Alright, that sounds good! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Marcus >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> On 4/12/2016 8:46 AM, Marcus Larsson wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> On 04/11/2016 07:36 PM, Max Ockner wrote: >>>>>>>>>>>>> Hello again, >>>>>>>>>>>>> >>>>>>>>>>>>> I have looked into this and I see a possible workaround to >>>>>>>>>>>>> the issue raised by Marcus: >>>>>>>>>>>>> >>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>> might be problematic for the error handler. I suppose >>>>>>>>>>>>> the error >>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>> already holds >>>>>>>>>>>>> the lock. Unsure how to resolve this, because skipping >>>>>>>>>>>>> to take >>>>>>>>>>>>> the lock means that we might crash due to another thread >>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> My proposed solution is this: >>>>>>>>>>>>> >>>>>>>>>>>>> If the ConfigurationLock is held by another thread during >>>>>>>>>>>>> the crash, then I think we could print "Log configuration >>>>>>>>>>>>> can not be accessed because ConfigurationLock is currently >>>>>>>>>>>>> held by another thread" or something similar. If the >>>>>>>>>>>>> ConfigurationLock can be taken by the current thread, then >>>>>>>>>>>>> print the configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> We can accomplish this as follows: >>>>>>>>>>>>> >>>>>>>>>>>>> In *logConfiguration.cpp*: Create a >>>>>>>>>>>>> ConfigurationLockMaybe class extending ConfigurationLock. >>>>>>>>>>>>> >>>>>>>>>>>>> class ConfigurationLockMaybe : ConfigurationLock { >>>>>>>>>>>>> private: >>>>>>>>>>>>> bool _success; >>>>>>>>>>>>> public: >>>>>>>>>>>>> ConfigurationLockMaybe() { >>>>>>>>>>>>> if (_semaphore.trywait()){_success = true;} >>>>>>>>>>>>> } >>>>>>>>>>>>> ~ConfigurationLock() { >>>>>>>>>>>>> if(_success){_semaphore.signal();} >>>>>>>>>>>>> } >>>>>>>>>>>>> bool has_lock(){return _success;} >>>>>>>>>>>>> }; >>>>>>>>>>>>> >>>>>>>>>>>>> _semaphore is a static var in ConfigurationLock, so the >>>>>>>>>>>>> same copy is accessed in child classes. >>>>>>>>>>>>> >>>>>>>>>>>>> Another method >>>>>>>>>>>>> LogConfiguration::describe_on_crash(outputStream* out) can >>>>>>>>>>>>> use ConfigurationLockMaybe to attempt to print the >>>>>>>>>>>>> configuration. >>>>>>>>>>>>> >>>>>>>>>>>>> In *vmError.cpp*: Replace LogConfiguration::describe with >>>>>>>>>>>>> LogConfiguration::describe_on_crash. >>>>>>>>>>>> >>>>>>>>>>>> Sounds good to me. >>>>>>>>>>>> >>>>>>>>>>>> ConfigurationLockMaybe sounds a bit weird but I don't have >>>>>>>>>>>> a better suggestion. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Marcus >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>>>> On 4/11/2016 10:23 AM, Max Ockner wrote: >>>>>>>>>>>>>> I missed this before. I'm going to investigate. >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/11/2016 4:19 AM, Marcus Larsson wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 04/11/2016 09:00 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Apr 8, 2016 at 9:56 PM, Max Ockner >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I forgot to respond to this: >>>>>>>>>>>>>>>> On 4/1/2016 4:45 AM, Marcus Larsson wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 03/31/2016 08:08 PM, Max Ockner wrote: >>>>>>>>>>>>>>>>>> (Replies in line) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 3/30/2016 9:31 AM, Thomas St?fe wrote: >>>>>>>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Disclaimer: not a (R)eviewer. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Do we really need a list of all tags and all >>>>>>>>>>>>>>>>>>> decorators? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Just going by what we currently put in the hs_err >>>>>>>>>>>>>>>>>> file, I think >>>>>>>>>>>>>>>>>> this may be the first "Do we really need" we've >>>>>>>>>>>>>>>>>> ever asked for >>>>>>>>>>>>>>>>>> this type of change. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> All joking aside, I think it is a good idea to >>>>>>>>>>>>>>>>>> direct users >>>>>>>>>>>>>>>>>> toward proper UL usage whenever we have a chance. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Also: I assume what you print is the Log state as it >>>>>>>>>>>>>>>>>>> is at the >>>>>>>>>>>>>>>>>>> time the hs-err file is printed. If logging was >>>>>>>>>>>>>>>>>>> enabled/changed during lifetime of the VM, e.g. >>>>>>>>>>>>>>>>>>> with jcmd, >>>>>>>>>>>>>>>>>>> would it be possible to see that? At least a >>>>>>>>>>>>>>>>>>> warning if >>>>>>>>>>>>>>>>>>> logging was not enabled from the start on. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Would it be possible? Yes, but I think this would >>>>>>>>>>>>>>>>>> require a >>>>>>>>>>>>>>>>>> framework change. It does not look like any marks >>>>>>>>>>>>>>>>>> are made when >>>>>>>>>>>>>>>>>> the LogConfiguration changes during runtime, and >>>>>>>>>>>>>>>>>> we would need >>>>>>>>>>>>>>>>>> to record that in order to know what to print >>>>>>>>>>>>>>>>>> when we dump into >>>>>>>>>>>>>>>>>> hs_err. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, this would required the framework to keep >>>>>>>>>>>>>>>>> some sort of log >>>>>>>>>>>>>>>>> of configuration changes. Is there value in >>>>>>>>>>>>>>>>> knowing that the log >>>>>>>>>>>>>>>>> configuration changed since startup? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I think it is useful along with other information. >>>>>>>>>>>>>>>> An example case: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Let's say we are logging a message whenever a lock >>>>>>>>>>>>>>>> is acquired or >>>>>>>>>>>>>>>> released. In a subsystem like this, the action >>>>>>>>>>>>>>>> which dooms the vm >>>>>>>>>>>>>>>> may not cause an immediate crash. This leaves time >>>>>>>>>>>>>>>> for logging to >>>>>>>>>>>>>>>> turn on or off in between the bad action and the >>>>>>>>>>>>>>>> crash. If you >>>>>>>>>>>>>>>> don't know when logging was active and when it was >>>>>>>>>>>>>>>> not, then the >>>>>>>>>>>>>>>> absence of a particular message does not give you much >>>>>>>>>>>>>>>> information. You may not see the message that has >>>>>>>>>>>>>>>> the answer for >>>>>>>>>>>>>>>> you because it was not logged, though the action >>>>>>>>>>>>>>>> may have occurred. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> However, if we don't have the framework support for >>>>>>>>>>>>>>>> this then I >>>>>>>>>>>>>>>> believe it should be added later. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is a good example. A small easy solution, as I >>>>>>>>>>>>>>>> mentioned before, could be just to distinguish between >>>>>>>>>>>>>>>> "logging parameters stable since startup" and "logging >>>>>>>>>>>>>>>> parameters changed at some time". That way you would at >>>>>>>>>>>>>>>> least know whether to trust the logging output. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But you are right, this can be added later. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've filed >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153945 for this. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Max: Did you see my comments about the >>>>>>>>>>>>>>> ConfigurationLock? It was an inline reply to your first >>>>>>>>>>>>>>> mail. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>>>>> Kind Regards, Thomas >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 29, 2016 at 9:00 PM, Max Ockner >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> > wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>>>>>> Please review another Unified Logging >>>>>>>>>>>>>>>>>>> change. They are >>>>>>>>>>>>>>>>>>> almost done, and we are serious this time. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> bug: >>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151526 >>>>>>>>>>>>>>>>>>> webrev: >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~mockner/8151526.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> LogConfiguration::describe() takes the >>>>>>>>>>>>>>>>> ConfigurationLock, which >>>>>>>>>>>>>>>>> might be problematic for the error handler. I >>>>>>>>>>>>>>>>> suppose the error >>>>>>>>>>>>>>>>> handler could potentially deadlock if its thread >>>>>>>>>>>>>>>>> already holds >>>>>>>>>>>>>>>>> the lock. Unsure how to resolve this, because >>>>>>>>>>>>>>>>> skipping to take >>>>>>>>>>>>>>>>> the lock means that we might crash due to another >>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>>> changing the configuration as we read it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Marcus >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The logging configuration is now printed in >>>>>>>>>>>>>>>>>>> each hs_err >>>>>>>>>>>>>>>>>>> file. The output is the same as you would >>>>>>>>>>>>>>>>>>> see from >>>>>>>>>>>>>>>>>>> -Xlog:logging=trace and it is obtained from >>>>>>>>>>>>>>>>>>> LogConfiguration::describe(). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Below is a sample of the hs_err contents. >>>>>>>>>>>>>>>>>>> The Logging info >>>>>>>>>>>>>>>>>>> is printed after VM Arguments and Whitebox, >>>>>>>>>>>>>>>>>>> and before >>>>>>>>>>>>>>>>>>> Environment Variables. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> VM Arguments: >>>>>>>>>>>>>>>>>>> java_command: Kaboom >>>>>>>>>>>>>>>>>>> java_class_path (initial): . >>>>>>>>>>>>>>>>>>> Launcher Type: SUN_STANDARD >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Logging: >>>>>>>>>>>>>>>>>>> Available log levels: off, trace, debug, >>>>>>>>>>>>>>>>>>> info, warning, error >>>>>>>>>>>>>>>>>>> Available log decorators: time (t), uptime >>>>>>>>>>>>>>>>>>> (u), timemillis >>>>>>>>>>>>>>>>>>> (tm), uptimemillis (um), timenanos (tn), >>>>>>>>>>>>>>>>>>> uptimenanos (un), >>>>>>>>>>>>>>>>>>> hostname (hn), pid (p), tid (ti), level (l), >>>>>>>>>>>>>>>>>>> tags (tg) >>>>>>>>>>>>>>>>>>> Available log tags: alloc, age, barrier, >>>>>>>>>>>>>>>>>>> biasedlocking, >>>>>>>>>>>>>>>>>>> bot, census, classhisto, classresolve, >>>>>>>>>>>>>>>>>>> classinit, >>>>>>>>>>>>>>>>>>> classload, classloaderdata, classunload, >>>>>>>>>>>>>>>>>>> classpath, >>>>>>>>>>>>>>>>>>> compaction, cpu, cset, defaultmethods, ergo, >>>>>>>>>>>>>>>>>>> exceptions, >>>>>>>>>>>>>>>>>>> exit, freelist, gc, heap, humongous, ihop, >>>>>>>>>>>>>>>>>>> itables, jni, >>>>>>>>>>>>>>>>>>> liveness, logging, marking, metaspace, modules, >>>>>>>>>>>>>>>>>>> monitorinflation, os, phases, plab, >>>>>>>>>>>>>>>>>>> promotion, preorder, >>>>>>>>>>>>>>>>>>> protectiondomain, ref, refine, region, >>>>>>>>>>>>>>>>>>> remset, safepoint, >>>>>>>>>>>>>>>>>>> safepointcleanup, scavenge, scrub, >>>>>>>>>>>>>>>>>>> stacktrace, start, >>>>>>>>>>>>>>>>>>> startuptime, state, stats, stringdedup, >>>>>>>>>>>>>>>>>>> stringtable, >>>>>>>>>>>>>>>>>>> survivor, sweep, task, thread, tlab, time, >>>>>>>>>>>>>>>>>>> verboseverification, verify, vmoperation, >>>>>>>>>>>>>>>>>>> vtables >>>>>>>>>>>>>>>>>>> Log output configuration: >>>>>>>>>>>>>>>>>>> #0: stdout all=off uptime,level,tags, >>>>>>>>>>>>>>>>>>> #1: stderr all=warning uptime,level,tags, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Environment Variables: >>>>>>>>>>>>>>>>>>> JAVA_HOME=/scratch/mockner/UL/8151526/build/linux-x86_64-normal-server-fastdebug/images/jdk >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> PATH=/home/mockner/tools/webrev:/bin:/usr/bin:/usr/local/bin:/usr/sbin:/home/mockner/bin:/home/mockner/linux/bin >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> SHELL=/bin/bash >>>>>>>>>>>>>>>>>>> OS=Linux >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From marcus.larsson at oracle.com Tue Apr 19 09:07:03 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 19 Apr 2016 11:07:03 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <570F80B1.5020602@oracle.com> References: <570F80B1.5020602@oracle.com> Message-ID: <5715F537.2040904@oracle.com> Hi, On 04/14/2016 01:36 PM, Robbin Ehn wrote: > Hi all, > > Please review: > > This moves jvmti trace output to the tag jvmti on trace level. > > The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have > a lot of functionality, e.g. can filter on func, in/out, etc, so it if > left as is. > > TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti > tag is set. > > Webrev: http://cr.openjdk.java.net/~rehn/8154041/ In jvmtiExport.cpp: Maybe we should remove the commented trace calls while at it? I'm thinking of lines 639-641 and 677-681. Maybe they could be un-commented as well, I'm not sure. Also, there is (pre-existing) trailing whitespace in a bunch of the messages which I think we can remove (line 2203 for example). Other than that, I think this looks good! Thanks, Marcus > Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 > > Thanks! > > /Robbin From marcus.larsson at oracle.com Tue Apr 19 09:16:01 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 19 Apr 2016 11:16:01 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <570F8499.7070604@oracle.com> References: <570F8499.7070604@oracle.com> Message-ID: <5715F751.1060406@oracle.com> Hi, On 04/14/2016 01:52 PM, Robbin Ehn wrote: > Hi all, > > Please review: > > This moves jvmti object-tagging output to the tag-set > jvmti,objecttagging on debug level. > > The TraceJVMTIObjectTagging argument is deprecated and aliased with: > "-Xlog:jvmti+objecttagging=debug" > > Did this on top of: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html > > but only part common is the jvmti tag (logTag.hpp). > > Webrev: http://cr.openjdk.java.net/~rehn/8154059/ I think 'objecttagging' is a bit too long. Maybe we could just call it 'tagging'? I'm fine with leaving it as is as well, just wanted to suggest the alternative. Looks good in any case! Thanks, Marcus > Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 > > Thanks! > > /Robbin > From robbin.ehn at oracle.com Tue Apr 19 09:43:34 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 11:43:34 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <5715F537.2040904@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> Message-ID: <5715FDC6.6040209@oracle.com> Hi Marcus, On 04/19/2016 11:07 AM, Marcus Larsson wrote: > Hi, > > On 04/14/2016 01:36 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review: >> >> This moves jvmti trace output to the tag jvmti on trace level. >> >> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have >> a lot of functionality, e.g. can filter on func, in/out, etc, so it if >> left as is. >> >> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti >> tag is set. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ > > In jvmtiExport.cpp: > Maybe we should remove the commented trace calls while at it? I'm > thinking of lines 639-641 and 677-681. Maybe they could be un-commented > as well, I'm not sure. I removed them. > > Also, there is (pre-existing) trailing whitespace in a bunch of the > messages which I think we can remove (line 2203 for example). I removed these also. I updated webrev: Incremental: http://cr.openjdk.java.net/~rehn/8154041/v2-v1/ Full: http://cr.openjdk.java.net/~rehn/8154041/v2/ > > Other than that, I think this looks good! Thanks ! /Robbin > > Thanks, > Marcus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >> >> Thanks! >> >> /Robbin > From robbin.ehn at oracle.com Tue Apr 19 09:46:26 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 11:46:26 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <5715F751.1060406@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> Message-ID: <5715FE72.7080104@oracle.com> Hi Marcus, On 04/19/2016 11:16 AM, Marcus Larsson wrote: > Hi, > > On 04/14/2016 01:52 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review: >> >> This moves jvmti object-tagging output to the tag-set >> jvmti,objecttagging on debug level. >> >> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >> "-Xlog:jvmti+objecttagging=debug" >> >> Did this on top of: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >> >> but only part common is the jvmti tag (logTag.hpp). >> >> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ > > I think 'objecttagging' is a bit too long. Maybe we could just call it > 'tagging'? I'm fine with leaving it as is as well, just wanted to > suggest the alternative. If the "second" reviewer concur, I'll change it. > > Looks good in any case! Thanks! /Robbin > > Thanks, > Marcus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >> >> Thanks! >> >> /Robbin >> > From serguei.spitsyn at oracle.com Tue Apr 19 09:47:25 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 02:47:25 -0700 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <5715FDC6.6040209@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> <5715FDC6.6040209@oracle.com> Message-ID: <5715FEAD.80802@oracle.com> Hi Robbin, The fix looks good. Also, I'm Ok with the removal of comments. Thanks, Serguei On 4/19/16 02:43, Robbin Ehn wrote: > Hi Marcus, > > On 04/19/2016 11:07 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/14/2016 01:36 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Please review: >>> >>> This moves jvmti trace output to the tag jvmti on trace level. >>> >>> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have >>> a lot of functionality, e.g. can filter on func, in/out, etc, so it if >>> left as is. >>> >>> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti >>> tag is set. >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ >> >> In jvmtiExport.cpp: >> Maybe we should remove the commented trace calls while at it? I'm >> thinking of lines 639-641 and 677-681. Maybe they could be un-commented >> as well, I'm not sure. > > I removed them. > >> >> Also, there is (pre-existing) trailing whitespace in a bunch of the >> messages which I think we can remove (line 2203 for example). > > I removed these also. > > I updated webrev: > Incremental: http://cr.openjdk.java.net/~rehn/8154041/v2-v1/ > Full: http://cr.openjdk.java.net/~rehn/8154041/v2/ > >> >> Other than that, I think this looks good! > > Thanks ! > > /Robbin > >> >> Thanks, >> Marcus >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >>> >>> Thanks! >>> >>> /Robbin >> From robbin.ehn at oracle.com Tue Apr 19 10:00:03 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 12:00:03 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <5715FEAD.80802@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> <5715FDC6.6040209@oracle.com> <5715FEAD.80802@oracle.com> Message-ID: <571601A3.7040502@oracle.com> Hi Serguei, Thanks! /Robbin On 04/19/2016 11:47 AM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > The fix looks good. > Also, I'm Ok with the removal of comments. > > Thanks, > Serguei > > > On 4/19/16 02:43, Robbin Ehn wrote: >> Hi Marcus, >> >> On 04/19/2016 11:07 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/14/2016 01:36 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Please review: >>>> >>>> This moves jvmti trace output to the tag jvmti on trace level. >>>> >>>> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" have >>>> a lot of functionality, e.g. can filter on func, in/out, etc, so it if >>>> left as is. >>>> >>>> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti >>>> tag is set. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ >>> >>> In jvmtiExport.cpp: >>> Maybe we should remove the commented trace calls while at it? I'm >>> thinking of lines 639-641 and 677-681. Maybe they could be un-commented >>> as well, I'm not sure. >> >> I removed them. >> >>> >>> Also, there is (pre-existing) trailing whitespace in a bunch of the >>> messages which I think we can remove (line 2203 for example). >> >> I removed these also. >> >> I updated webrev: >> Incremental: http://cr.openjdk.java.net/~rehn/8154041/v2-v1/ >> Full: http://cr.openjdk.java.net/~rehn/8154041/v2/ >> >>> >>> Other than that, I think this looks good! >> >> Thanks ! >> >> /Robbin >> >>> >>> Thanks, >>> Marcus >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >>>> >>>> Thanks! >>>> >>>> /Robbin >>> > From serguei.spitsyn at oracle.com Tue Apr 19 10:05:58 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 Apr 2016 03:05:58 -0700 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <5715FE72.7080104@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> Message-ID: <57160306.3050107@oracle.com> Hi Robbin, The fix loos good. I'd like to have the tag-set name shorter but prefer "objecttagging" over "tagging". Also, I'm thinking if the tag-set name should include the "jvmti" prefix. But, please, use your judgement as it has to be consistent with the overall design. Thanks, Serguei On 4/19/16 02:46, Robbin Ehn wrote: > Hi Marcus, > > On 04/19/2016 11:16 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Please review: >>> >>> This moves jvmti object-tagging output to the tag-set >>> jvmti,objecttagging on debug level. >>> >>> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >>> "-Xlog:jvmti+objecttagging=debug" >>> >>> Did this on top of: >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>> >>> >>> but only part common is the jvmti tag (logTag.hpp). >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >> >> I think 'objecttagging' is a bit too long. Maybe we could just call it >> 'tagging'? I'm fine with leaving it as is as well, just wanted to >> suggest the alternative. > > If the "second" reviewer concur, I'll change it. > >> >> Looks good in any case! > > Thanks! > > /Robbin > >> >> Thanks, >> Marcus >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>> >>> Thanks! >>> >>> /Robbin >>> >> From robbin.ehn at oracle.com Tue Apr 19 11:16:45 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 13:16:45 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <57160306.3050107@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> <57160306.3050107@oracle.com> Message-ID: <5716139D.2040408@oracle.com> Hi Serguei, Thanks! /Robbin On 04/19/2016 12:05 PM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > The fix loos good. > I'd like to have the tag-set name shorter but prefer "objecttagging" > over "tagging". > Also, I'm thinking if the tag-set name should include the "jvmti" prefix. > But, please, use your judgement as it has to be consistent with the > overall design. > > Thanks, > Serguei > > > On 4/19/16 02:46, Robbin Ehn wrote: >> Hi Marcus, >> >> On 04/19/2016 11:16 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Please review: >>>> >>>> This moves jvmti object-tagging output to the tag-set >>>> jvmti,objecttagging on debug level. >>>> >>>> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >>>> "-Xlog:jvmti+objecttagging=debug" >>>> >>>> Did this on top of: >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>>> >>>> >>>> but only part common is the jvmti tag (logTag.hpp). >>>> >>>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >>> >>> I think 'objecttagging' is a bit too long. Maybe we could just call it >>> 'tagging'? I'm fine with leaving it as is as well, just wanted to >>> suggest the alternative. >> >> If the "second" reviewer concur, I'll change it. >> >>> >>> Looks good in any case! >> >> Thanks! >> >> /Robbin >> >>> >>> Thanks, >>> Marcus >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>>> >>>> Thanks! >>>> >>>> /Robbin >>>> >>> > From gerard.ziemski at oracle.com Tue Apr 19 12:54:58 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 19 Apr 2016 07:54:58 -0500 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5715BC65.3010302@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <57! 15BC65.3010302@oracle.com> Message-ID: <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> > On Apr 19, 2016, at 12:04 AM, David Holmes wrote: > > On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >> Hi Gerard, >> >> 2016/04/19 3:14 "Gerard Ziemski" > >: >> > >> > hi Yasumasa, >> > >> > Nice work. I have 2 questions: >> > >> > ======== >> > File: java.c >> > >> > #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >> after every single JNI call? In this example instead of NULL_CHECK, >> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >> >> It is not critical if we encounter error at JNI function call because >> we cannot set native thread name only. >> So I think that we do not need to leave from launcher process. > > I agree we do not need to abort if an exception occurs (and in fact I don't think an exception is even possible from this code), but we should ensure any pending exception is cleared before any futher JNI calls might be made. Note that NULL_CHECK is already used extensively throughout the launcher code - so if this usage is wrong then it is all wrong! More on this code below ... Isn?t there a risk that: (*env)->CallVoidMethod(env, currentThread, setNativeNameID, + nameString, JNI_TRUE); will raise an exception? In the least, shouldn?t we clear any possible pending exceptions at the beginning of ?SetNativeThreadName?, as you say, but also at the very end? cheers From david.holmes at oracle.com Tue Apr 19 12:59:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 22:59:40 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> Message-ID: <57162BBC.7010400@oracle.com> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: > >> On Apr 19, 2016, at 12:04 AM, David Holmes wrote: >> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>> Hi Gerard, >>> >>> 2016/04/19 3:14 "Gerard Ziemski" >> >: >>>> >>>> hi Yasumasa, >>>> >>>> Nice work. I have 2 questions: >>>> >>>> ======== >>>> File: java.c >>>> >>>> #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>> after every single JNI call? In this example instead of NULL_CHECK, >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>> >>> It is not critical if we encounter error at JNI function call because >>> we cannot set native thread name only. >>> So I think that we do not need to leave from launcher process. >> >> I agree we do not need to abort if an exception occurs (and in fact I don't think an exception is even possible from this code), but we should ensure any pending exception is cleared before any futher JNI calls might be made. Note that NULL_CHECK is already used extensively throughout the launcher code - so if this usage is wrong then it is all wrong! More on this code below ... > > Isn?t there a risk that: > > (*env)->CallVoidMethod(env, currentThread, setNativeNameID, > + nameString, JNI_TRUE); > > will raise an exception? > > In the least, shouldn?t we clear any possible pending exceptions at the beginning of ?SetNativeThreadName?, as you say, but also at the very end? I was actually saying at the end, after the call (even though I don't think any exceptions are possible - except for "async" exceptions of course). We shouldn't be able to get to the call with any exception pending as in that case the JNI calls will be returning NULL and we will exit - again this pattern is used extensively in the launcher. David > > cheers > From daniel.daugherty at oracle.com Tue Apr 19 16:06:48 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Apr 2016 09:06:48 -0700 (PDT) Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <5716139D.2040408@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> <57160306.3050107@oracle.com> <5716139D.2040408@oracle.com> Message-ID: <57165798.2020103@oracle.com> Please, no shorter than 'objtag'. Object needs to be in there somewhere... 'tagging' is just too general. Dan On 4/19/16 5:16 AM, Robbin Ehn wrote: > Hi Serguei, > > Thanks! > > /Robbin > > On 04/19/2016 12:05 PM, serguei.spitsyn at oracle.com wrote: >> Hi Robbin, >> >> The fix loos good. >> I'd like to have the tag-set name shorter but prefer "objecttagging" >> over "tagging". >> Also, I'm thinking if the tag-set name should include the "jvmti" >> prefix. >> But, please, use your judgement as it has to be consistent with the >> overall design. >> >> Thanks, >> Serguei >> >> >> On 4/19/16 02:46, Robbin Ehn wrote: >>> Hi Marcus, >>> >>> On 04/19/2016 11:16 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>>>> Hi all, >>>>> >>>>> Please review: >>>>> >>>>> This moves jvmti object-tagging output to the tag-set >>>>> jvmti,objecttagging on debug level. >>>>> >>>>> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >>>>> "-Xlog:jvmti+objecttagging=debug" >>>>> >>>>> Did this on top of: >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>>>> >>>>> >>>>> >>>>> but only part common is the jvmti tag (logTag.hpp). >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >>>> >>>> I think 'objecttagging' is a bit too long. Maybe we could just call it >>>> 'tagging'? I'm fine with leaving it as is as well, just wanted to >>>> suggest the alternative. >>> >>> If the "second" reviewer concur, I'll change it. >>> >>>> >>>> Looks good in any case! >>> >>> Thanks! >>> >>> /Robbin >>> >>>> >>>> Thanks, >>>> Marcus >>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin >>>>> >>>> >> From coleen.phillimore at oracle.com Tue Apr 19 14:51:08 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 19 Apr 2016 07:51:08 -0700 (PDT) Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <5715F537.2040904@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> Message-ID: <571645DC.2030509@oracle.com> http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiImpl.hpp.udiff.html Usually the print() functions have no arguments and the print_on() functions have the outputStream arguments. Could you add print_on() instead? print() is usually void print() { print_on(tty); } http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiExport.cpp.udiff.html It would be nice to not have these as macros, and have inline static functions but if JvmtiTrace::event_trace_flags(evt) doesn't evaluate to a constant, I guess you need them. http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiEventController.cpp.udiff.html Same here. Otherwise looks good. From this RFR it looks like you were going to add a tag 'ec' and 'ieost' which are meaningless combinations of letters, but I don't see this tag addition. Thanks, Coleen On 4/19/16 5:07 AM, Marcus Larsson wrote: > Hi, > > On 04/14/2016 01:36 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review: >> >> This moves jvmti trace output to the tag jvmti on trace level. >> >> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" >> have a lot of functionality, e.g. can filter on func, in/out, etc, so >> it if left as is. >> >> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti >> tag is set. >> >> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ > > In jvmtiExport.cpp: > Maybe we should remove the commented trace calls while at it? I'm > thinking of lines 639-641 and 677-681. Maybe they could be > un-commented as well, I'm not sure. > > Also, there is (pre-existing) trailing whitespace in a bunch of the > messages which I think we can remove (line 2203 for example). > > Other than that, I think this looks good! > > Thanks, > Marcus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >> >> Thanks! >> >> /Robbin > From kumar.x.srinivasan at oracle.com Tue Apr 19 17:00:27 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 19 Apr 2016 10:00:27 -0700 (PDT) Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57162BBC.7010400@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> Message-ID: <5716642B.8010207@oracle.com> Hi David, 493 /* Set native thread name. */ 494 SetNativeThreadName(env, "main"); 495 496 /* Invoke main method. */ 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); Supposing an exception is thrown in 494 (a very remote case), will we not re-enter the VM in 497 with an exception ? Kumar > On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >> >>> On Apr 19, 2016, at 12:04 AM, David Holmes >>> wrote: >>> >>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>> Hi Gerard, >>>> >>>> 2016/04/19 3:14 "Gerard Ziemski" >>> >: >>>>> >>>>> hi Yasumasa, >>>>> >>>>> Nice work. I have 2 questions: >>>>> >>>>> ======== >>>>> File: java.c >>>>> >>>>> #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>>> after every single JNI call? In this example instead of NULL_CHECK, >>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>> >>>> It is not critical if we encounter error at JNI function call because >>>> we cannot set native thread name only. >>>> So I think that we do not need to leave from launcher process. >>> >>> I agree we do not need to abort if an exception occurs (and in fact >>> I don't think an exception is even possible from this code), but we >>> should ensure any pending exception is cleared before any futher JNI >>> calls might be made. Note that NULL_CHECK is already used >>> extensively throughout the launcher code - so if this usage is wrong >>> then it is all wrong! More on this code below ... >> >> Isn?t there a risk that: >> >> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >> + nameString, JNI_TRUE); >> >> will raise an exception? >> >> In the least, shouldn?t we clear any possible pending exceptions at >> the beginning of ?SetNativeThreadName?, as you say, but also at the >> very end? > > I was actually saying at the end, after the call (even though I don't > think any exceptions are possible - except for "async" exceptions of > course). We shouldn't be able to get to the call with any exception > pending as in that case the JNI calls will be returning NULL and we > will exit - again this pattern is used extensively in the launcher. > > David > >> >> cheers >> From harold.seigel at oracle.com Tue Apr 19 18:53:10 2016 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 19 Apr 2016 11:53:10 -0700 (PDT) Subject: RFR(XS) 8152846: Creation of ModuleEntryTable Investigate Need For OrderAccess::storestore() In-Reply-To: <5712077B.1090605@oracle.com> References: <5703FB65.7060504@oracle.com> <5712077B.1090605@oracle.com> Message-ID: <57167E96.1020608@oracle.com> Hi David, Thanks for looking at this. I agree that the storestore is needed and will open a new bug to address this. Harold On 4/16/2016 5:35 AM, David Holmes wrote: > Hi Harold, > > On 6/04/2016 3:52 AM, harold seigel wrote: >> Hi, >> >> Please review this small change to fix bug 8152846. >> >> This change removes an unneeded OrderAccess::storestore() call. >> >> Webrev: http://javaweb.us.oracle.com/~hseigel/webrev/bug_8152846/ > > Please ensure you provide an accessible webrev link please. > > I have a concern with this code. I think the storeStore as written was > in the wrong place. The main concern with lock-free read of a field > like _packages is that if you see a non-null value then you also see > all the stores that were made as part of the construction of the > object _packages refers to. In that regard I think the original code: > > // Ensure _packages is stable, since it is examined without a lock > OrderAccess::storestore(); > _packages = new > PackageEntryTable(PackageEntryTable::_packagetable_entry_size); > } > return _packages; > > Should really have bee: > > temp = new > PackageEntryTable(PackageEntryTable::_packagetable_entry_size); > OrderAccess::storeStore(); > _packages = tmp; > ... > > though to be sure we need to examine the lock-free usage of _packages. > > David > ----- > >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8152846 >> >> The fix was tested with JCK API, Lang, and VM tests, the UTE >> non-colocated quick tests, and the hotspot, JDK vm, java/io, java/lang, >> java/util, and java/security tests. Testing with UTE colocated tests is >> in progress. >> >> Thanks, Harold From erik.osterlund at oracle.com Tue Apr 19 18:13:41 2016 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 19 Apr 2016 11:13:41 -0700 (PDT) Subject: RFR (S): 8153751: Windows Atomic and OrderAccess are not emitting explicit compiler barriers In-Reply-To: <57158FEA.4090000@oracle.com> References: <57077322.3000009@oracle.com> <57158FEA.4090000@oracle.com> Message-ID: <4000D31A-BE4A-430E-8E81-63E094FAA2AE@oracle.com> Hi David, Thanks for reviewing this! > On 19 apr. 2016, at 03:54, David Holmes wrote: > > Hi Erik, > > Sorry for the delay on this. > >> On 8/04/2016 7:00 PM, Erik ?sterlund wrote: >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153751 >> Webrev: http://cr.openjdk.java.net/~eosterlund/8153751/webrev.00/ >> >> It turns out that on Windows, compiler barriers are not used for >> Atomic:: code and some code in OrderAccess. It is assumed that the >> non-volatile accesses will not be reordered across __asm statements, as >> the current memory model should prevent. But I have not found any >> guarantees that this is the case for __asm. > > Agreed - not that I would expect it to be clearly documented even if true. There is no reason to assume that any arbitrary _asm statement automatically acts as a compiler barrier, though some may. Agreed. >> The closest source I could find is the documentation for the >> MemoryBarrier macro that uses an __asm statement to produce a hardware >> membar. The documentation says the following: "Creates a hardware memory >> barrier (fence) that prevents the CPU from re-ordering read and write >> operations. It may also prevent the compiler from re-ordering read and >> write operations." >> >> Note the "MAY" prevent compiler reordering. (*facepalm*) This sounds to >> me like __asm really does not guarantee compiler reordering across __asm >> at all. > > Yeah that sounds like it was written by someone who really didn't understand the issues. :( Yeah any "may prevent X" seems like a suboptimal guarantee. >> A suspected victim of this reordering is here: >> https://bugs.openjdk.java.net/browse/JDK-8033545 > > I don't really see how that particular bug would be helped by additional compiler-barriers. As I understand the report it was the elision of a non-volatile load that caused the problem, not a reordering. But anyway ... The current memory model should prevent reordering, even with non-volatile fields, across cmpxchg/fence. The issue can be seen as the compiler allowing the re-load after the CAS as being allowed to float up, across the CAS, all the way up to the original load, where it is eliminated as redundant. Compiler barriers (should) prevent this illegal compiler reordering by invalidating all memory assumptions that causes the non-volatile field to not be reloaded. I do agree though that writing lock-free code with non-volatile fields is just asking for trouble, which is why I have a separate webrev where I made all the GC-related fields we CAS on volatile by default. They should be volatile regardless. > >> To make the use of these classes more safe, I propose to simply add >> explicit compiler barriers in this windows code. It should not make any >> difference, as I am only enforcing compiler reordering rules that should >> already hold. > > Okay, I agree with the proposed changes - the CompilerBarrierScope should effectively have no impact on generated code, other than prohibiting code motion. Agreed, but... > >> This small patch fixes this. The only thing to note is that the __asm >> statements that put things in %eax and avoid returning anything. > > Could you elaborate on that please ?? ...there are some methods that should return a value but do not and instead rely on the return value in the asm block being in the %eax register which per the C ABI is where return values are stored. The compiler is explicitly told to not complain that there is no return statement. And on debug builds the scope thing generates some code that would break this, unless care is taken. And fortunately it is taken so it's fine. (split those methods out to internal methods where the assumptions still hold) > >> Testing: JPRT > > Did you compare the generated object code before and after to see if it actually changed anything? It did in debug mode as per note above. Thanks a lot for reviewing! :) /Erik > > Thanks, > David > ----- > >> Thanks, >> /Erik From robbin.ehn at oracle.com Tue Apr 19 19:23:08 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 21:23:08 +0200 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <57165798.2020103@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> <57160306.3050107@oracle.com> <5716139D.2040408@oracle.com> <57165798.2020103@oracle.com> Message-ID: <5716859C.3010204@oracle.com> Hi Dan, This was pushed with: -Xlog:jvmti+objecttagging=debug /Robbin On 04/19/2016 06:06 PM, Daniel D. Daugherty wrote: > Please, no shorter than 'objtag'. Object needs to be in there > somewhere... 'tagging' is just too general. > > Dan > > > On 4/19/16 5:16 AM, Robbin Ehn wrote: >> Hi Serguei, >> >> Thanks! >> >> /Robbin >> >> On 04/19/2016 12:05 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Robbin, >>> >>> The fix loos good. >>> I'd like to have the tag-set name shorter but prefer "objecttagging" >>> over "tagging". >>> Also, I'm thinking if the tag-set name should include the "jvmti" >>> prefix. >>> But, please, use your judgement as it has to be consistent with the >>> overall design. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/19/16 02:46, Robbin Ehn wrote: >>>> Hi Marcus, >>>> >>>> On 04/19/2016 11:16 AM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review: >>>>>> >>>>>> This moves jvmti object-tagging output to the tag-set >>>>>> jvmti,objecttagging on debug level. >>>>>> >>>>>> The TraceJVMTIObjectTagging argument is deprecated and aliased with: >>>>>> "-Xlog:jvmti+objecttagging=debug" >>>>>> >>>>>> Did this on top of: >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>>>>> >>>>>> >>>>>> >>>>>> but only part common is the jvmti tag (logTag.hpp). >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >>>>> >>>>> I think 'objecttagging' is a bit too long. Maybe we could just >>>>> call it >>>>> 'tagging'? I'm fine with leaving it as is as well, just wanted to >>>>> suggest the alternative. >>>> >>>> If the "second" reviewer concur, I'll change it. >>>> >>>>> >>>>> Looks good in any case! >>>> >>>> Thanks! >>>> >>>> /Robbin >>>> >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>>>>> >>>>>> Thanks! >>>>>> >>>>>> /Robbin >>>>>> >>>>> >>> > From daniel.daugherty at oracle.com Tue Apr 19 19:25:26 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Apr 2016 13:25:26 -0600 Subject: RFR: 8154059: JVMTI ObjectTagging to UL In-Reply-To: <5716859C.3010204@oracle.com> References: <570F8499.7070604@oracle.com> <5715F751.1060406@oracle.com> <5715FE72.7080104@oracle.com> <57160306.3050107@oracle.com> <5716139D.2040408@oracle.com> <57165798.2020103@oracle.com> <5716859C.3010204@oracle.com> Message-ID: <57168626.1040303@oracle.com> Yup. I saw that after I was caught up with my hg/Mercurial notifications mailbox... My general (unfiltered) Inbox gets priority since that's where code review happen... :-) Dan On 4/19/16 1:23 PM, Robbin Ehn wrote: > Hi Dan, > > This was pushed with: > > -Xlog:jvmti+objecttagging=debug > > /Robbin > > On 04/19/2016 06:06 PM, Daniel D. Daugherty wrote: >> Please, no shorter than 'objtag'. Object needs to be in there >> somewhere... 'tagging' is just too general. >> >> Dan >> >> >> On 4/19/16 5:16 AM, Robbin Ehn wrote: >>> Hi Serguei, >>> >>> Thanks! >>> >>> /Robbin >>> >>> On 04/19/2016 12:05 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Robbin, >>>> >>>> The fix loos good. >>>> I'd like to have the tag-set name shorter but prefer "objecttagging" >>>> over "tagging". >>>> Also, I'm thinking if the tag-set name should include the "jvmti" >>>> prefix. >>>> But, please, use your judgement as it has to be consistent with the >>>> overall design. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 4/19/16 02:46, Robbin Ehn wrote: >>>>> Hi Marcus, >>>>> >>>>> On 04/19/2016 11:16 AM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> On 04/14/2016 01:52 PM, Robbin Ehn wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review: >>>>>>> >>>>>>> This moves jvmti object-tagging output to the tag-set >>>>>>> jvmti,objecttagging on debug level. >>>>>>> >>>>>>> The TraceJVMTIObjectTagging argument is deprecated and aliased >>>>>>> with: >>>>>>> "-Xlog:jvmti+objecttagging=debug" >>>>>>> >>>>>>> Did this on top of: >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019007.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> but only part common is the jvmti tag (logTag.hpp). >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~rehn/8154059/ >>>>>> >>>>>> I think 'objecttagging' is a bit too long. Maybe we could just >>>>>> call it >>>>>> 'tagging'? I'm fine with leaving it as is as well, just wanted to >>>>>> suggest the alternative. >>>>> >>>>> If the "second" reviewer concur, I'll change it. >>>>> >>>>>> >>>>>> Looks good in any case! >>>>> >>>>> Thanks! >>>>> >>>>> /Robbin >>>>> >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154059 >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>> >>>> >> > From robbin.ehn at oracle.com Tue Apr 19 19:40:03 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 19 Apr 2016 21:40:03 +0200 Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <571645DC.2030509@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> <571645DC.2030509@oracle.com> Message-ID: <57168993.1060302@oracle.com> Hi Coleen, Unfortunately, this was pushed. Sorry for being a bit trigger happy here. On 04/19/2016 04:51 PM, Coleen Phillimore wrote: > http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiImpl.hpp.udiff.html > > > Usually the print() functions have no arguments and the print_on() > functions have the outputStream arguments. Could you add print_on() > instead? > > print() is usually void print() { print_on(tty); } I'll send out a bug-fix for this! > > > > http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiExport.cpp.udiff.html > > > It would be nice to not have these as macros, and have inline static > functions but if > > JvmtiTrace::event_trace_flags(evt) > > > doesn't evaluate to a constant, I guess you need them. > > http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiEventController.cpp.udiff.html > > > Same here. Ill leave them as they are, ok? > > Otherwise looks good. Thanks! /Robbin > > From this RFR it looks like you were going to add a tag 'ec' and > 'ieost' which are meaningless combinations of letters, but I don't see > this tag addition. > Thanks, > Coleen > > > > On 4/19/16 5:07 AM, Marcus Larsson wrote: >> Hi, >> >> On 04/14/2016 01:36 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Please review: >>> >>> This moves jvmti trace output to the tag jvmti on trace level. >>> >>> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" >>> have a lot of functionality, e.g. can filter on func, in/out, etc, >>> so it if left as is. >>> >>> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for jvmti >>> tag is set. >>> >>> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ >> >> In jvmtiExport.cpp: >> Maybe we should remove the commented trace calls while at it? I'm >> thinking of lines 639-641 and 677-681. Maybe they could be >> un-commented as well, I'm not sure. >> >> Also, there is (pre-existing) trailing whitespace in a bunch of the >> messages which I think we can remove (line 2203 for example). >> >> Other than that, I think this looks good! >> >> Thanks, >> Marcus >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >>> >>> Thanks! >>> >>> /Robbin >> > From david.holmes at oracle.com Tue Apr 19 20:32:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Apr 2016 13:32:19 -0700 (PDT) Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5716642B.8010207@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> <5716642B.8010207@oracle.com> Message-ID: <571695D3.6060908@oracle.com> On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: > Hi David, > > 493 /* Set native thread name. */ > 494 SetNativeThreadName(env, "main"); > 495 > 496 /* Invoke main method. */ > 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); > > Supposing an exception is thrown in 494 (a very remote case), > will we not re-enter the VM in 497 with an exception ? Yes as I said: > 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); > 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, > 1714 nameString, JNI_TRUE); > > As above NULL_CHECK is fine here, but we should check for and clear any pending exception after CallVoidMethod. Thanks, David > Kumar > >> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >>> >>>> On Apr 19, 2016, at 12:04 AM, David Holmes >>>> wrote: >>>> >>>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>> Hi Gerard, >>>>> >>>>> 2016/04/19 3:14 "Gerard Ziemski" >>>> >: >>>>>> >>>>>> hi Yasumasa, >>>>>> >>>>>> Nice work. I have 2 questions: >>>>>> >>>>>> ======== >>>>>> File: java.c >>>>>> >>>>>> #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>>>> after every single JNI call? In this example instead of NULL_CHECK, >>>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>> >>>>> It is not critical if we encounter error at JNI function call because >>>>> we cannot set native thread name only. >>>>> So I think that we do not need to leave from launcher process. >>>> >>>> I agree we do not need to abort if an exception occurs (and in fact >>>> I don't think an exception is even possible from this code), but we >>>> should ensure any pending exception is cleared before any futher JNI >>>> calls might be made. Note that NULL_CHECK is already used >>>> extensively throughout the launcher code - so if this usage is wrong >>>> then it is all wrong! More on this code below ... >>> >>> Isn?t there a risk that: >>> >>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>> + nameString, JNI_TRUE); >>> >>> will raise an exception? >>> >>> In the least, shouldn?t we clear any possible pending exceptions at >>> the beginning of ?SetNativeThreadName?, as you say, but also at the >>> very end? >> >> I was actually saying at the end, after the call (even though I don't >> think any exceptions are possible - except for "async" exceptions of >> course). We shouldn't be able to get to the call with any exception >> pending as in that case the JNI calls will be returning NULL and we >> will exit - again this pattern is used extensively in the launcher. >> >> David >> >>> >>> cheers >>> > From coleen.phillimore at oracle.com Tue Apr 19 20:01:00 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 19 Apr 2016 13:01:00 -0700 (PDT) Subject: RFR: 8154041: JVMTI to Unified Logging In-Reply-To: <57168993.1060302@oracle.com> References: <570F80B1.5020602@oracle.com> <5715F537.2040904@oracle.com> <571645DC.2030509@oracle.com> <57168993.1060302@oracle.com> Message-ID: <57168E7C.4020006@oracle.com> On 4/19/16 3:40 PM, Robbin Ehn wrote: > Hi Coleen, > > Unfortunately, this was pushed. > Sorry for being a bit trigger happy here. That's ok, you're on an earlier timezone than I am. > > On 04/19/2016 04:51 PM, Coleen Phillimore wrote: >> http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiImpl.hpp.udiff.html >> >> >> Usually the print() functions have no arguments and the print_on() >> functions have the outputStream arguments. Could you add print_on() >> instead? >> >> print() is usually void print() { print_on(tty); } > > I'll send out a bug-fix for this! That would be good. There are probably other places where this is like this. It would be nice if it were consistent. > >> >> >> >> http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiExport.cpp.udiff.html >> >> >> It would be nice to not have these as macros, and have inline static >> functions but if >> >> JvmtiTrace::event_trace_flags(evt) >> >> >> doesn't evaluate to a constant, I guess you need them. >> >> http://cr.openjdk.java.net/~rehn/8154041/webrev/src/share/vm/prims/jvmtiEventController.cpp.udiff.html >> >> >> Same here. > > Ill leave them as they are, ok? > Yes, this is fine. Coleen >> >> Otherwise looks good. > > Thanks! > > /Robbin > >> >> From this RFR it looks like you were going to add a tag 'ec' and >> 'ieost' which are meaningless combinations of letters, but I don't >> see this tag addition. >> Thanks, >> Coleen >> >> >> >> On 4/19/16 5:07 AM, Marcus Larsson wrote: >>> Hi, >>> >>> On 04/14/2016 01:36 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Please review: >>>> >>>> This moves jvmti trace output to the tag jvmti on trace level. >>>> >>>> The jvmti trace argument e.g. "-XX:TraceJVMTI=ec+ieost,all+ieost" >>>> have a lot of functionality, e.g. can filter on func, in/out, etc, >>>> so it if left as is. >>>> >>>> TraceJVMTI enables jvmti trace to stdout if no other -Xlog for >>>> jvmti tag is set. >>>> >>>> Webrev: http://cr.openjdk.java.net/~rehn/8154041/ >>> >>> In jvmtiExport.cpp: >>> Maybe we should remove the commented trace calls while at it? I'm >>> thinking of lines 639-641 and 677-681. Maybe they could be >>> un-commented as well, I'm not sure. >>> >>> Also, there is (pre-existing) trailing whitespace in a bunch of the >>> messages which I think we can remove (line 2203 for example). >>> >>> Other than that, I think this looks good! >>> >>> Thanks, >>> Marcus >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154041 >>>> >>>> Thanks! >>>> >>>> /Robbin >>> >> > From kumar.x.srinivasan at oracle.com Tue Apr 19 21:33:39 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 19 Apr 2016 14:33:39 -0700 (PDT) Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571695D3.6060908@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> <5716642B.8010207@oracle.com> <571695D3.6060908@oracle.com> Message-ID: <5716A433.1070909@oracle.com> On 4/19/2016 1:32 PM, David Holmes wrote: > On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: >> Hi David, >> >> 493 /* Set native thread name. */ >> 494 SetNativeThreadName(env, "main"); >> 495 >> 496 /* Invoke main method. */ >> 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, >> mainArgs); >> >> Supposing an exception is thrown in 494 (a very remote case), >> will we not re-enter the VM in 497 with an exception ? > > Yes as I said: > >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >> 1714 nameString, JNI_TRUE); >> >> As above NULL_CHECK is fine here, but we should check for and clear >> any pending exception after CallVoidMethod. > Agreed. Kumar > Thanks, > David > >> Kumar >> >>> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >>>> >>>>> On Apr 19, 2016, at 12:04 AM, David Holmes >>>>> wrote: >>>>> >>>>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>> Hi Gerard, >>>>>> >>>>>> 2016/04/19 3:14 "Gerard Ziemski" >>>>> >: >>>>>>> >>>>>>> hi Yasumasa, >>>>>>> >>>>>>> Nice work. I have 2 questions: >>>>>>> >>>>>>> ======== >>>>>>> File: java.c >>>>>>> >>>>>>> #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>>>>> after every single JNI call? In this example instead of NULL_CHECK, >>>>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>> >>>>>> It is not critical if we encounter error at JNI function call >>>>>> because >>>>>> we cannot set native thread name only. >>>>>> So I think that we do not need to leave from launcher process. >>>>> >>>>> I agree we do not need to abort if an exception occurs (and in fact >>>>> I don't think an exception is even possible from this code), but we >>>>> should ensure any pending exception is cleared before any futher JNI >>>>> calls might be made. Note that NULL_CHECK is already used >>>>> extensively throughout the launcher code - so if this usage is wrong >>>>> then it is all wrong! More on this code below ... >>>> >>>> Isn?t there a risk that: >>>> >>>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>> + nameString, JNI_TRUE); >>>> >>>> will raise an exception? >>>> >>>> In the least, shouldn?t we clear any possible pending exceptions at >>>> the beginning of ?SetNativeThreadName?, as you say, but also at the >>>> very end? >>> >>> I was actually saying at the end, after the call (even though I don't >>> think any exceptions are possible - except for "async" exceptions of >>> course). We shouldn't be able to get to the call with any exception >>> pending as in that case the JNI calls will be returning NULL and we >>> will exit - again this pattern is used extensively in the launcher. >>> >>> David >>> >>>> >>>> cheers >>>> >> From jiangli.zhou at Oracle.COM Wed Apr 20 01:26:50 2016 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 19 Apr 2016 18:26:50 -0700 Subject: RFR(s) 8154457: runtime/SharedArchiveFile/SharedStrings Shared string table stats missing Message-ID: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> Please review the following change for JDK-8154457 . http://cr.openjdk.java.net/~jiangli/8154457/webrev.00/ Added more information when print out message reporting disabling the shared strings at CDS dump time. The shared strings support requires UseG1GC, UseCompressedOops and UseCompressedClassPointers all to be true. There are cases where the UseCompressedOops and UseCompressedClassPointers options are disabled due to other VM settings. For example, the UseCompressedOops and UseCompressedClassPointers are turned off if the VM is running in interpreter only mode, or the if MaxHeapSize is too large. The printed message now includes the value of those three options. Also, handle the cases when shared strings are disabled in SharedStrings.java test. Thanks, Jiangli From david.holmes at oracle.com Wed Apr 20 03:52:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Apr 2016 13:52:30 +1000 Subject: RFR (S): 8153751: Windows Atomic and OrderAccess are not emitting explicit compiler barriers In-Reply-To: <4000D31A-BE4A-430E-8E81-63E094FAA2AE@oracle.com> References: <57077322.3000009@oracle.com> <57158FEA.4090000@oracle.com> <4000D31A-BE4A-430E-8E81-63E094FAA2AE@oracle.com> Message-ID: <5716FCFE.8090406@oracle.com> On 20/04/2016 4:13 AM, Erik Osterlund wrote: > Hi David, > > Thanks for reviewing this! > >> On 19 apr. 2016, at 03:54, David Holmes wrote: >> >> Hi Erik, >> >> Sorry for the delay on this. >> >>> On 8/04/2016 7:00 PM, Erik ?sterlund wrote: >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153751 >>> Webrev: http://cr.openjdk.java.net/~eosterlund/8153751/webrev.00/ >>> >>> It turns out that on Windows, compiler barriers are not used for >>> Atomic:: code and some code in OrderAccess. It is assumed that the >>> non-volatile accesses will not be reordered across __asm statements, as >>> the current memory model should prevent. But I have not found any >>> guarantees that this is the case for __asm. >> >> Agreed - not that I would expect it to be clearly documented even if true. There is no reason to assume that any arbitrary _asm statement automatically acts as a compiler barrier, though some may. > > Agreed. > >>> The closest source I could find is the documentation for the >>> MemoryBarrier macro that uses an __asm statement to produce a hardware >>> membar. The documentation says the following: "Creates a hardware memory >>> barrier (fence) that prevents the CPU from re-ordering read and write >>> operations. It may also prevent the compiler from re-ordering read and >>> write operations." >>> >>> Note the "MAY" prevent compiler reordering. (*facepalm*) This sounds to >>> me like __asm really does not guarantee compiler reordering across __asm >>> at all. >> >> Yeah that sounds like it was written by someone who really didn't understand the issues. :( > > Yeah any "may prevent X" seems like a suboptimal guarantee. > >>> A suspected victim of this reordering is here: >>> https://bugs.openjdk.java.net/browse/JDK-8033545 >> >> I don't really see how that particular bug would be helped by additional compiler-barriers. As I understand the report it was the elision of a non-volatile load that caused the problem, not a reordering. But anyway ... > > The current memory model should prevent reordering, even with non-volatile fields, across cmpxchg/fence. The issue can be seen as the compiler allowing the re-load after the CAS as being allowed to float up, across the CAS, all the way up to the original load, where it is eliminated as redundant. > > Compiler barriers (should) prevent this illegal compiler reordering by invalidating all memory assumptions that causes the non-volatile field to not be reloaded. > > I do agree though that writing lock-free code with non-volatile fields is just asking for trouble, which is why I have a separate webrev where I made all the GC-related fields we CAS on volatile by default. They should be volatile regardless. > >> >>> To make the use of these classes more safe, I propose to simply add >>> explicit compiler barriers in this windows code. It should not make any >>> difference, as I am only enforcing compiler reordering rules that should >>> already hold. >> >> Okay, I agree with the proposed changes - the CompilerBarrierScope should effectively have no impact on generated code, other than prohibiting code motion. > > Agreed, but... > >> >>> This small patch fixes this. The only thing to note is that the __asm >>> statements that put things in %eax and avoid returning anything. >> >> Could you elaborate on that please ?? > > ...there are some methods that should return a value but do not and instead rely on the return value in the asm block being in the %eax register which per the C ABI is where return values are stored. The compiler is explicitly told to not complain that there is no return statement. > > And on debug builds the scope thing generates some code that would break this, unless care is taken. And fortunately it is taken so it's fine. (split those methods out to internal methods where the assumptions still hold) I'm very surprised that any code actually gets generated for CompilerBarrierScope. Is it only in debug? What does it generate? Is it _ReadWriteBarrier() that actually expands to real code? Thanks, David > >> >>> Testing: JPRT >> >> Did you compare the generated object code before and after to see if it actually changed anything? > > It did in debug mode as per note above. > > Thanks a lot for reviewing! :) > > /Erik > >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> /Erik From robbin.ehn at oracle.com Wed Apr 20 07:40:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 09:40:00 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee Message-ID: <57173250.6030304@oracle.com> Hi all, Please review. We are missing a cr on a log stream, which leads to this guarantee. Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 Thanks ! /Robbin diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 -0700 +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 +0200 @@ -428,6 +428,7 @@ LogTarget(Trace, jvmti) log; LogStreamCHeap log_stream(log); java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); + log_stream.cr(); CLEAR_PENDING_EXCEPTION; return; } From mikael.gerdin at oracle.com Wed Apr 20 07:51:16 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 20 Apr 2016 09:51:16 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173250.6030304@oracle.com> References: <57173250.6030304@oracle.com> Message-ID: <571734F4.5070006@oracle.com> Hi Robbin, On 2016-04-20 09:40, Robbin Ehn wrote: > Hi all, > > Please review. > > We are missing a cr on a log stream, which leads to this guarantee. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 > > Thanks ! > > /Robbin > > diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 -0700 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 +0200 > @@ -428,6 +428,7 @@ > LogTarget(Trace, jvmti) log; > LogStreamCHeap log_stream(log); > java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); > + log_stream.cr(); > CLEAR_PENDING_EXCEPTION; > return; > } Looks good. /Mikael From robbin.ehn at oracle.com Wed Apr 20 07:53:57 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 09:53:57 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <571734F4.5070006@oracle.com> References: <57173250.6030304@oracle.com> <571734F4.5070006@oracle.com> Message-ID: <57173595.4030506@oracle.com> Thanks Mikael! /Robbin On 04/20/2016 09:51 AM, Mikael Gerdin wrote: > Hi Robbin, > > On 2016-04-20 09:40, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> We are missing a cr on a log stream, which leads to this guarantee. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 >> >> Thanks ! >> >> /Robbin >> >> diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 >> -0700 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 >> +0200 >> @@ -428,6 +428,7 @@ >> LogTarget(Trace, jvmti) log; >> LogStreamCHeap log_stream(log); >> java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); >> + log_stream.cr(); >> CLEAR_PENDING_EXCEPTION; >> return; >> } > > > Looks good. > > /Mikael From david.holmes at oracle.com Wed Apr 20 07:57:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Apr 2016 17:57:44 +1000 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173250.6030304@oracle.com> References: <57173250.6030304@oracle.com> Message-ID: <57173678.9010000@oracle.com> Looks fine to me. Thanks, David On 20/04/2016 5:40 PM, Robbin Ehn wrote: > Hi all, > > Please review. > > We are missing a cr on a log stream, which leads to this guarantee. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 > > Thanks ! > > /Robbin > > diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 -0700 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 +0200 > @@ -428,6 +428,7 @@ > LogTarget(Trace, jvmti) log; > LogStreamCHeap log_stream(log); > java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); > + log_stream.cr(); > CLEAR_PENDING_EXCEPTION; > return; > } From stefan.karlsson at oracle.com Wed Apr 20 08:00:07 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 20 Apr 2016 10:00:07 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173250.6030304@oracle.com> References: <57173250.6030304@oracle.com> Message-ID: <57173707.7070006@oracle.com> Hi Robbin, This looks good to me. This breaks gc nightly and is a fairly trivial change, so I'll push this right away. Thanks, StefanK On 2016-04-20 09:40, Robbin Ehn wrote: > Hi all, > > Please review. > > We are missing a cr on a log stream, which leads to this guarantee. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 > > Thanks ! > > /Robbin > > diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp > --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 > -0700 > +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 > +0200 > @@ -428,6 +428,7 @@ > LogTarget(Trace, jvmti) log; > LogStreamCHeap log_stream(log); > java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); > + log_stream.cr(); > CLEAR_PENDING_EXCEPTION; > return; > } From robbin.ehn at oracle.com Wed Apr 20 08:00:52 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 10:00:52 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173678.9010000@oracle.com> References: <57173250.6030304@oracle.com> <57173678.9010000@oracle.com> Message-ID: <57173734.9030508@oracle.com> Thanks David! /Robbin On 04/20/2016 09:57 AM, David Holmes wrote: > Looks fine to me. > > Thanks, > David > > On 20/04/2016 5:40 PM, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> We are missing a cr on a log stream, which leads to this guarantee. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 >> >> Thanks ! >> >> /Robbin >> >> diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 >> -0700 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 >> +0200 >> @@ -428,6 +428,7 @@ >> LogTarget(Trace, jvmti) log; >> LogStreamCHeap log_stream(log); >> java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); >> + log_stream.cr(); >> CLEAR_PENDING_EXCEPTION; >> return; >> } From robbin.ehn at oracle.com Wed Apr 20 08:02:00 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 10:02:00 +0200 Subject: RFR: 8154728: JvmtiExport::add_default_read_edges hits a guarantee In-Reply-To: <57173707.7070006@oracle.com> References: <57173250.6030304@oracle.com> <57173707.7070006@oracle.com> Message-ID: <57173778.1020105@oracle.com> Thanks Stefan! And for sponsoring! /Robbin On 04/20/2016 10:00 AM, Stefan Karlsson wrote: > Hi Robbin, > > This looks good to me. This breaks gc nightly and is a fairly trivial > change, so I'll push this right away. > > Thanks, > StefanK > > On 2016-04-20 09:40, Robbin Ehn wrote: >> Hi all, >> >> Please review. >> >> We are missing a cr on a log stream, which leads to this guarantee. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154728 >> >> Thanks ! >> >> /Robbin >> >> diff -r 857efca82258 src/share/vm/prims/jvmtiExport.cpp >> --- a/src/share/vm/prims/jvmtiExport.cpp Sun Apr 17 19:15:52 2016 >> -0700 >> +++ b/src/share/vm/prims/jvmtiExport.cpp Wed Apr 20 09:37:01 2016 >> +0200 >> @@ -428,6 +428,7 @@ >> LogTarget(Trace, jvmti) log; >> LogStreamCHeap log_stream(log); >> java_lang_Throwable::print(PENDING_EXCEPTION, &log_stream); >> + log_stream.cr(); >> CLEAR_PENDING_EXCEPTION; >> return; >> } > From robbin.ehn at oracle.com Wed Apr 20 11:47:04 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 13:47:04 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() Message-ID: <57176C38.3000109@oracle.com> Hi all, please review! print() method was changed in 8154041 to have outputStream argument, this renames print to print_on. Since JvmtiBreakpoint extends GrowableElement print_on already exists as a virtual const method, hence the const changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ Tested with: #define TraceJVMTICalls false in hotspot/src/share/vm/prims/jvmtiEnv.cpp set to true with test-set nsk.jvmti.SetBreakpoint Thanks! /Robbin From lois.foltan at oracle.com Wed Apr 20 11:51:45 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 20 Apr 2016 07:51:45 -0400 Subject: RFR(s) 8154457: runtime/SharedArchiveFile/SharedStrings Shared string table stats missing In-Reply-To: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> References: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> Message-ID: <57176D51.7050103@oracle.com> On 4/19/2016 9:26 PM, Jiangli Zhou wrote: > Please review the following change for JDK-8154457 . > > http://cr.openjdk.java.net/~jiangli/8154457/webrev.00/ > > Added more information when print out message reporting disabling the shared strings at CDS dump time. The shared strings support requires UseG1GC, UseCompressedOops and UseCompressedClassPointers all to be true. There are cases where the UseCompressedOops and UseCompressedClassPointers options are disabled due to other VM settings. For example, the UseCompressedOops and UseCompressedClassPointers are turned off if the VM is running in interpreter only mode, or the if MaxHeapSize is too large. The printed message now includes the value of those three options. > > Also, handle the cases when shared strings are disabled in SharedStrings.java test. Hi Jiangli, I think this looks good. One very minor comment: src/share/vm/classfile/stringTable.cpp "Current setting:" should probably be "Current settings:" I don't need to see another webrev. Thanks, Lois > > Thanks, > Jiangli From marcus.larsson at oracle.com Wed Apr 20 11:54:59 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 20 Apr 2016 13:54:59 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <57176C38.3000109@oracle.com> References: <57176C38.3000109@oracle.com> Message-ID: <90e34dca-b232-39f4-7298-8b2f506ac05b@oracle.com> Hi, On 04/20/2016 01:47 PM, Robbin Ehn wrote: > Hi all, please review! > > print() method was changed in 8154041 to have outputStream argument, > this renames print to print_on. > Since JvmtiBreakpoint extends GrowableElement print_on already exists > as a virtual const method, hence the const changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 > Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ Looks good to me. Thanks, Marcus > > Tested with: > > #define TraceJVMTICalls false > in hotspot/src/share/vm/prims/jvmtiEnv.cpp > set to true with test-set nsk.jvmti.SetBreakpoint > > Thanks! > > /Robbin From robbin.ehn at oracle.com Wed Apr 20 11:55:19 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 20 Apr 2016 13:55:19 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <90e34dca-b232-39f4-7298-8b2f506ac05b@oracle.com> References: <57176C38.3000109@oracle.com> <90e34dca-b232-39f4-7298-8b2f506ac05b@oracle.com> Message-ID: <57176E27.3040607@oracle.com> Thanks Marcus! /Robbin On 04/20/2016 01:54 PM, Marcus Larsson wrote: > Hi, > > On 04/20/2016 01:47 PM, Robbin Ehn wrote: >> Hi all, please review! >> >> print() method was changed in 8154041 to have outputStream argument, >> this renames print to print_on. >> Since JvmtiBreakpoint extends GrowableElement print_on already exists >> as a virtual const method, hence the const changes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 >> Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ > > Looks good to me. > > Thanks, > Marcus > >> >> Tested with: >> >> #define TraceJVMTICalls false >> in hotspot/src/share/vm/prims/jvmtiEnv.cpp >> set to true with test-set nsk.jvmti.SetBreakpoint >> >> Thanks! >> >> /Robbin > From kumar.x.srinivasan at oracle.com Wed Apr 20 12:58:34 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 20 Apr 2016 05:58:34 -0700 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5716A433.1070909@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> <5716642B.8010207@oracle.com> <571695D3.6060908@oracle.com> <5716A433.1070909@oracle.com> Message-ID: <57177CFA.9020100@oracle.com> Hello, One more thing, what about a launcher regression test ? Thanks Kumar > > On 4/19/2016 1:32 PM, David Holmes wrote: >> On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: >>> Hi David, >>> >>> 493 /* Set native thread name. */ >>> 494 SetNativeThreadName(env, "main"); >>> 495 >>> 496 /* Invoke main method. */ >>> 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>> mainArgs); >>> >>> Supposing an exception is thrown in 494 (a very remote case), >>> will we not re-enter the VM in 497 with an exception ? >> >> Yes as I said: >> >>> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>> 1714 nameString, JNI_TRUE); >>> >>> As above NULL_CHECK is fine here, but we should check for and clear >>> any pending exception after CallVoidMethod. >> > Agreed. > > Kumar > >> Thanks, >> David >> >>> Kumar >>> >>>> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >>>>> >>>>>> On Apr 19, 2016, at 12:04 AM, David Holmes >>>>>> wrote: >>>>>> >>>>>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>> Hi Gerard, >>>>>>> >>>>>>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>> >: >>>>>>>> >>>>>>>> hi Yasumasa, >>>>>>>> >>>>>>>> Nice work. I have 2 questions: >>>>>>>> >>>>>>>> ======== >>>>>>>> File: java.c >>>>>>>> >>>>>>>> #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>>>>>> after every single JNI call? In this example instead of NULL_CHECK, >>>>>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>> >>>>>>> It is not critical if we encounter error at JNI function call >>>>>>> because >>>>>>> we cannot set native thread name only. >>>>>>> So I think that we do not need to leave from launcher process. >>>>>> >>>>>> I agree we do not need to abort if an exception occurs (and in fact >>>>>> I don't think an exception is even possible from this code), but we >>>>>> should ensure any pending exception is cleared before any futher JNI >>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>> extensively throughout the launcher code - so if this usage is wrong >>>>>> then it is all wrong! More on this code below ... >>>>> >>>>> Isn?t there a risk that: >>>>> >>>>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>> + nameString, JNI_TRUE); >>>>> >>>>> will raise an exception? >>>>> >>>>> In the least, shouldn?t we clear any possible pending exceptions at >>>>> the beginning of ?SetNativeThreadName?, as you say, but also at the >>>>> very end? >>>> >>>> I was actually saying at the end, after the call (even though I don't >>>> think any exceptions are possible - except for "async" exceptions of >>>> course). We shouldn't be able to get to the call with any exception >>>> pending as in that case the JNI calls will be returning NULL and we >>>> will exit - again this pattern is used extensively in the launcher. >>>> >>>> David >>>> >>>>> >>>>> cheers >>>>> >>> > From david.holmes at oracle.com Wed Apr 20 13:06:45 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Apr 2016 23:06:45 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57177CFA.9020100@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> <5716642B.8010207@oracle.com> <571695D3.6060908@oracle.com> <5716A433.1070909@oracle.com> <57177CFA.9020100@oracle.com> Message-ID: <57177EE5.2080508@oracle.com> On 20/04/2016 10:58 PM, Kumar Srinivasan wrote: > > Hello, > > One more thing, what about a launcher regression test ? What kind of regression test? I've manually visually inspected the desired behaviour but a test for it is very problematic. AFAIK there are no tests for setting the native thread name. David > Thanks > Kumar > >> >> On 4/19/2016 1:32 PM, David Holmes wrote: >>> On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: >>>> Hi David, >>>> >>>> 493 /* Set native thread name. */ >>>> 494 SetNativeThreadName(env, "main"); >>>> 495 >>>> 496 /* Invoke main method. */ >>>> 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>> mainArgs); >>>> >>>> Supposing an exception is thrown in 494 (a very remote case), >>>> will we not re-enter the VM in 497 with an exception ? >>> >>> Yes as I said: >>> >>>> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>> 1714 nameString, JNI_TRUE); >>>> >>>> As above NULL_CHECK is fine here, but we should check for and clear >>>> any pending exception after CallVoidMethod. >>> >> Agreed. >> >> Kumar >> >>> Thanks, >>> David >>> >>>> Kumar >>>> >>>>> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >>>>>> >>>>>>> On Apr 19, 2016, at 12:04 AM, David Holmes >>>>>>> wrote: >>>>>>> >>>>>>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi Gerard, >>>>>>>> >>>>>>>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>> >: >>>>>>>>> >>>>>>>>> hi Yasumasa, >>>>>>>>> >>>>>>>>> Nice work. I have 2 questions: >>>>>>>>> >>>>>>>>> ======== >>>>>>>>> File: java.c >>>>>>>>> >>>>>>>>> #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>>>>>>> after every single JNI call? In this example instead of NULL_CHECK, >>>>>>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>> >>>>>>>> It is not critical if we encounter error at JNI function call >>>>>>>> because >>>>>>>> we cannot set native thread name only. >>>>>>>> So I think that we do not need to leave from launcher process. >>>>>>> >>>>>>> I agree we do not need to abort if an exception occurs (and in fact >>>>>>> I don't think an exception is even possible from this code), but we >>>>>>> should ensure any pending exception is cleared before any futher JNI >>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>> extensively throughout the launcher code - so if this usage is wrong >>>>>>> then it is all wrong! More on this code below ... >>>>>> >>>>>> Isn?t there a risk that: >>>>>> >>>>>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>>> + nameString, JNI_TRUE); >>>>>> >>>>>> will raise an exception? >>>>>> >>>>>> In the least, shouldn?t we clear any possible pending exceptions at >>>>>> the beginning of ?SetNativeThreadName?, as you say, but also at the >>>>>> very end? >>>>> >>>>> I was actually saying at the end, after the call (even though I don't >>>>> think any exceptions are possible - except for "async" exceptions of >>>>> course). We shouldn't be able to get to the call with any exception >>>>> pending as in that case the JNI calls will be returning NULL and we >>>>> will exit - again this pattern is used extensively in the launcher. >>>>> >>>>> David >>>>> >>>>>> >>>>>> cheers >>>>>> >>>> >> > From harold.seigel at oracle.com Wed Apr 20 13:38:10 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 20 Apr 2016 09:38:10 -0400 Subject: RFR(s) 8154457: runtime/SharedArchiveFile/SharedStrings Shared string table stats missing In-Reply-To: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> References: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> Message-ID: <57178642.70403@oracle.com> Hi Jiangli, Instead of constructs such as: 735 UseG1GC ? "true" : "false", UseCompressedOops ? "true" : "false", 736 UseCompressedClassPointers ? "true" : "false"); You could try using the existing BOOL_TO_STR macro. Otherwise, the changes look good. Thanks, Harold On 4/19/2016 9:26 PM, Jiangli Zhou wrote: > Please review the following change for JDK-8154457 . > > http://cr.openjdk.java.net/~jiangli/8154457/webrev.00/ > > Added more information when print out message reporting disabling the shared strings at CDS dump time. The shared strings support requires UseG1GC, UseCompressedOops and UseCompressedClassPointers all to be true. There are cases where the UseCompressedOops and UseCompressedClassPointers options are disabled due to other VM settings. For example, the UseCompressedOops and UseCompressedClassPointers are turned off if the VM is running in interpreter only mode, or the if MaxHeapSize is too large. The printed message now includes the value of those three options. > > Also, handle the cases when shared strings are disabled in SharedStrings.java test. > > Thanks, > Jiangli From mikhailo.seledtsov at oracle.com Wed Apr 20 14:12:07 2016 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Wed, 20 Apr 2016 07:12:07 -0700 Subject: RFR(s) 8154457: runtime/SharedArchiveFile/SharedStrings Shared string table stats missing In-Reply-To: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> References: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> Message-ID: <57178E37.4010202@oracle.com> Hi Jiangli, The test changes look good, except for use of System.exit(). I recommend throwing exception instead. No need to repost review for this change. Thank you, Misha On 4/19/2016 6:26 PM, Jiangli Zhou wrote: > Please review the following change for JDK-8154457 . > > http://cr.openjdk.java.net/~jiangli/8154457/webrev.00/ > > Added more information when print out message reporting disabling the shared strings at CDS dump time. The shared strings support requires UseG1GC, UseCompressedOops and UseCompressedClassPointers all to be true. There are cases where the UseCompressedOops and UseCompressedClassPointers options are disabled due to other VM settings. For example, the UseCompressedOops and UseCompressedClassPointers are turned off if the VM is running in interpreter only mode, or the if MaxHeapSize is too large. The printed message now includes the value of those three options. > > Also, handle the cases when shared strings are disabled in SharedStrings.java test. > > Thanks, > Jiangli From kumar.x.srinivasan at oracle.com Wed Apr 20 14:26:34 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 20 Apr 2016 07:26:34 -0700 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57177EE5.2080508@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> <5716642B.8010207@oracle.com> <571695D3.6060908@oracle.com> <5716A433.1070909@oracle.com> <57177CFA.9020100@oracle.com> <57177EE5.2080508@oracle.com> Message-ID: <5717919A.5090109@oracle.com> On 4/20/2016 6:06 AM, David Holmes wrote: > On 20/04/2016 10:58 PM, Kumar Srinivasan wrote: >> >> Hello, >> >> One more thing, what about a launcher regression test ? > > What kind of regression test? I've manually visually inspected the > desired behaviour but a test for it is very problematic. AFAIK there > are no tests for setting the native thread name. Isn't there a management API or something to enumerate the threads ? I am more worried about some seemingly innocuous launcher change causing a regression. Well if it is hard then the jbs must be labelled so, noreg-hard. Kumar > > David > >> Thanks >> Kumar >> >>> >>> On 4/19/2016 1:32 PM, David Holmes wrote: >>>> On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: >>>>> Hi David, >>>>> >>>>> 493 /* Set native thread name. */ >>>>> 494 SetNativeThreadName(env, "main"); >>>>> 495 >>>>> 496 /* Invoke main method. */ >>>>> 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>> mainArgs); >>>>> >>>>> Supposing an exception is thrown in 494 (a very remote case), >>>>> will we not re-enter the VM in 497 with an exception ? >>>> >>>> Yes as I said: >>>> >>>>> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>> 1714 nameString, JNI_TRUE); >>>>> >>>>> As above NULL_CHECK is fine here, but we should check for and clear >>>>> any pending exception after CallVoidMethod. >>>> >>> Agreed. >>> >>> Kumar >>> >>>> Thanks, >>>> David >>>> >>>>> Kumar >>>>> >>>>>> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >>>>>>> >>>>>>>> On Apr 19, 2016, at 12:04 AM, David Holmes >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi Gerard, >>>>>>>>> >>>>>>>>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>> >: >>>>>>>>>> >>>>>>>>>> hi Yasumasa, >>>>>>>>>> >>>>>>>>>> Nice work. I have 2 questions: >>>>>>>>>> >>>>>>>>>> ======== >>>>>>>>>> File: java.c >>>>>>>>>> >>>>>>>>>> #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>>>>>>>> after every single JNI call? In this example instead of >>>>>>>>> NULL_CHECK, >>>>>>>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>> >>>>>>>>> It is not critical if we encounter error at JNI function call >>>>>>>>> because >>>>>>>>> we cannot set native thread name only. >>>>>>>>> So I think that we do not need to leave from launcher process. >>>>>>>> >>>>>>>> I agree we do not need to abort if an exception occurs (and in >>>>>>>> fact >>>>>>>> I don't think an exception is even possible from this code), >>>>>>>> but we >>>>>>>> should ensure any pending exception is cleared before any >>>>>>>> futher JNI >>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>> extensively throughout the launcher code - so if this usage is >>>>>>>> wrong >>>>>>>> then it is all wrong! More on this code below ... >>>>>>> >>>>>>> Isn?t there a risk that: >>>>>>> >>>>>>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>>>> + nameString, JNI_TRUE); >>>>>>> >>>>>>> will raise an exception? >>>>>>> >>>>>>> In the least, shouldn?t we clear any possible pending exceptions at >>>>>>> the beginning of ?SetNativeThreadName?, as you say, but also at the >>>>>>> very end? >>>>>> >>>>>> I was actually saying at the end, after the call (even though I >>>>>> don't >>>>>> think any exceptions are possible - except for "async" exceptions of >>>>>> course). We shouldn't be able to get to the call with any exception >>>>>> pending as in that case the JNI calls will be returning NULL and we >>>>>> will exit - again this pattern is used extensively in the launcher. >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> cheers >>>>>>> >>>>> >>> >> From george.triantafillou at oracle.com Wed Apr 20 14:48:59 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 20 Apr 2016 10:48:59 -0400 Subject: RFR(s) 8154457: runtime/SharedArchiveFile/SharedStrings Shared string table stats missing In-Reply-To: <57178E37.4010202@oracle.com> References: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> <57178E37.4010202@oracle.com> Message-ID: <571796DB.9070500@oracle.com> +1 -George On 4/20/2016 10:12 AM, Mikhailo Seledtsov wrote: > Hi Jiangli, > > The test changes look good, except for use of System.exit(). I > recommend throwing exception instead. No need to repost review for > this change. > > Thank you, > Misha > > On 4/19/2016 6:26 PM, Jiangli Zhou wrote: >> Please review the following change for JDK-8154457 >> . >> >> http://cr.openjdk.java.net/~jiangli/8154457/webrev.00/ >> >> Added more information when print out message reporting disabling the >> shared strings at CDS dump time. The shared strings support requires >> UseG1GC, UseCompressedOops and UseCompressedClassPointers all to be >> true. There are cases where the UseCompressedOops and >> UseCompressedClassPointers options are disabled due to other VM >> settings. For example, the UseCompressedOops and >> UseCompressedClassPointers are turned off if the VM is running in >> interpreter only mode, or the if MaxHeapSize is too large. The >> printed message now includes the value of those three options. >> >> Also, handle the cases when shared strings are disabled in >> SharedStrings.java test. >> >> Thanks, >> Jiangli > From yasuenag at gmail.com Wed Apr 20 14:59:50 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 20 Apr 2016 23:59:50 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5717919A.5090109@oracle.com> References: <56F3F90D.9010408@gmail.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> <5716642B.8010207@oracle.com> <571695D3.6060908@oracle.com> <5716A433.1070909@oracle.com> <57177CFA.9020100@oracle.com> <57177EE5.2080508@oracle.com> <5717919A.5090109@oracle.com> Message-ID: <57179966.4050504@gmail.com> Hi Kumar, > Isn't there a management API or something to enumerate the threads ? On Linux, user apps can get native thread name through pthread_getname_np(3). However, this function is not called in hotspot and jdk. So I think it is difficult to get native thread name in all platforms. > Well if it is hard then the jbs must be labelled so, noreg-hard. I agree to label noreg-hard. Thanks, Yasumasa On 2016/04/20 23:26, Kumar Srinivasan wrote: > > On 4/20/2016 6:06 AM, David Holmes wrote: >> On 20/04/2016 10:58 PM, Kumar Srinivasan wrote: >>> >>> Hello, >>> >>> One more thing, what about a launcher regression test ? >> >> What kind of regression test? I've manually visually inspected the desired behaviour but a test for it is very problematic. AFAIK there are no tests for setting the native thread name. > > Isn't there a management API or something to enumerate the threads ? > I am more worried about some seemingly innocuous launcher change > causing a regression. > > Well if it is hard then the jbs must be labelled so, noreg-hard. > > Kumar > >> >> David >> >>> Thanks >>> Kumar >>> >>>> >>>> On 4/19/2016 1:32 PM, David Holmes wrote: >>>>> On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: >>>>>> Hi David, >>>>>> >>>>>> 493 /* Set native thread name. */ >>>>>> 494 SetNativeThreadName(env, "main"); >>>>>> 495 >>>>>> 496 /* Invoke main method. */ >>>>>> 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>> mainArgs); >>>>>> >>>>>> Supposing an exception is thrown in 494 (a very remote case), >>>>>> will we not re-enter the VM in 497 with an exception ? >>>>> >>>>> Yes as I said: >>>>> >>>>>> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>>> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>>> 1714 nameString, JNI_TRUE); >>>>>> >>>>>> As above NULL_CHECK is fine here, but we should check for and clear >>>>>> any pending exception after CallVoidMethod. >>>>> >>>> Agreed. >>>> >>>> Kumar >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Kumar >>>>>> >>>>>>> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >>>>>>>> >>>>>>>>> On Apr 19, 2016, at 12:04 AM, David Holmes >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi Gerard, >>>>>>>>>> >>>>>>>>>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>> >: >>>>>>>>>>> >>>>>>>>>>> hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> Nice work. I have 2 questions: >>>>>>>>>>> >>>>>>>>>>> ======== >>>>>>>>>>> File: java.c >>>>>>>>>>> >>>>>>>>>>> #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>>>>>>>>> after every single JNI call? In this example instead of NULL_CHECK, >>>>>>>>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>> >>>>>>>>>> It is not critical if we encounter error at JNI function call >>>>>>>>>> because >>>>>>>>>> we cannot set native thread name only. >>>>>>>>>> So I think that we do not need to leave from launcher process. >>>>>>>>> >>>>>>>>> I agree we do not need to abort if an exception occurs (and in fact >>>>>>>>> I don't think an exception is even possible from this code), but we >>>>>>>>> should ensure any pending exception is cleared before any futher JNI >>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>> extensively throughout the launcher code - so if this usage is wrong >>>>>>>>> then it is all wrong! More on this code below ... >>>>>>>> >>>>>>>> Isn?t there a risk that: >>>>>>>> >>>>>>>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>>>>> + nameString, JNI_TRUE); >>>>>>>> >>>>>>>> will raise an exception? >>>>>>>> >>>>>>>> In the least, shouldn?t we clear any possible pending exceptions at >>>>>>>> the beginning of ?SetNativeThreadName?, as you say, but also at the >>>>>>>> very end? >>>>>>> >>>>>>> I was actually saying at the end, after the call (even though I don't >>>>>>> think any exceptions are possible - except for "async" exceptions of >>>>>>> course). We shouldn't be able to get to the call with any exception >>>>>>> pending as in that case the JNI calls will be returning NULL and we >>>>>>> will exit - again this pattern is used extensively in the launcher. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>> >>>> >>> > From jiangli.zhou at oracle.com Wed Apr 20 18:48:08 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 20 Apr 2016 11:48:08 -0700 Subject: RFR(s) 8154457: runtime/SharedArchiveFile/SharedStrings Shared string table stats missing In-Reply-To: <57176D51.7050103@oracle.com> References: <80B2886D-3B39-4A33-946F-12FFA2FDC752@oracle.com> <57176D51.7050103@oracle.com> Message-ID: <31A4D166-BAF3-4336-8C55-5AB4A7E02EFE@oracle.com> Hi Lois, Harold, Misha and George, Thank you for the reviews! I?ve incorporated all of your suggestions. Thanks! Jiangli > On Apr 20, 2016, at 4:51 AM, Lois Foltan wrote: > > > On 4/19/2016 9:26 PM, Jiangli Zhou wrote: >> Please review the following change for JDK-8154457 . >> >> http://cr.openjdk.java.net/~jiangli/8154457/webrev.00/ >> >> Added more information when print out message reporting disabling the shared strings at CDS dump time. The shared strings support requires UseG1GC, UseCompressedOops and UseCompressedClassPointers all to be true. There are cases where the UseCompressedOops and UseCompressedClassPointers options are disabled due to other VM settings. For example, the UseCompressedOops and UseCompressedClassPointers are turned off if the VM is running in interpreter only mode, or the if MaxHeapSize is too large. The printed message now includes the value of those three options. >> >> Also, handle the cases when shared strings are disabled in SharedStrings.java test. > > Hi Jiangli, > > I think this looks good. One very minor comment: > > src/share/vm/classfile/stringTable.cpp > "Current setting:" should probably be "Current settings:" > > I don't need to see another webrev. > > Thanks, > Lois > >> >> Thanks, >> Jiangli > From david.holmes at oracle.com Thu Apr 21 07:01:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Apr 2016 17:01:39 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57179966.4050504@gmail.com> References: <56F3F90D.9010408@gmail.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> <5716642B.8010207@oracle.com> <571695D3.6060908@oracle.com> <5716A433.1070909@oracle.com> <57177CFA.9020100@oracle.com> <57177EE5.2080508@oracle.com> <5717919A.5090109@oracle.com> <57179966.4050504@gmail.com> Message-ID: <57187AD3.30304@oracle.com> On 21/04/2016 12:59 AM, Yasumasa Suenaga wrote: > Hi Kumar, > >> Isn't there a management API or something to enumerate the threads ? Not that shows native thread names. Existing launcher tests should of course be unaffected by this change. > On Linux, user apps can get native thread name through > pthread_getname_np(3). > However, this function is not called in hotspot and jdk. > > So I think it is difficult to get native thread name in all platforms. > > >> Well if it is hard then the jbs must be labelled so, noreg-hard. > > I agree to label noreg-hard. I concur. Thanks, David > > Thanks, > > Yasumasa > > > On 2016/04/20 23:26, Kumar Srinivasan wrote: >> >> On 4/20/2016 6:06 AM, David Holmes wrote: >>> On 20/04/2016 10:58 PM, Kumar Srinivasan wrote: >>>> >>>> Hello, >>>> >>>> One more thing, what about a launcher regression test ? >>> >>> What kind of regression test? I've manually visually inspected the >>> desired behaviour but a test for it is very problematic. AFAIK there >>> are no tests for setting the native thread name. >> >> Isn't there a management API or something to enumerate the threads ? >> I am more worried about some seemingly innocuous launcher change >> causing a regression. >> >> Well if it is hard then the jbs must be labelled so, noreg-hard. >> >> Kumar >> >>> >>> David >>> >>>> Thanks >>>> Kumar >>>> >>>>> >>>>> On 4/19/2016 1:32 PM, David Holmes wrote: >>>>>> On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> 493 /* Set native thread name. */ >>>>>>> 494 SetNativeThreadName(env, "main"); >>>>>>> 495 >>>>>>> 496 /* Invoke main method. */ >>>>>>> 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>> mainArgs); >>>>>>> >>>>>>> Supposing an exception is thrown in 494 (a very remote case), >>>>>>> will we not re-enter the VM in 497 with an exception ? >>>>>> >>>>>> Yes as I said: >>>>>> >>>>>>> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>>>> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>>>> 1714 nameString, JNI_TRUE); >>>>>>> >>>>>>> As above NULL_CHECK is fine here, but we should check for and clear >>>>>>> any pending exception after CallVoidMethod. >>>>>> >>>>> Agreed. >>>>> >>>>> Kumar >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Kumar >>>>>>> >>>>>>>> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >>>>>>>>> >>>>>>>>>> On Apr 19, 2016, at 12:04 AM, David Holmes >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi Gerard, >>>>>>>>>>> >>>>>>>>>>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>>> >: >>>>>>>>>>>> >>>>>>>>>>>> hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> Nice work. I have 2 questions: >>>>>>>>>>>> >>>>>>>>>>>> ======== >>>>>>>>>>>> File: java.c >>>>>>>>>>>> >>>>>>>>>>>> #1 Shouldn?t we be checking for >>>>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>>> after every single JNI call? In this example instead of >>>>>>>>>>> NULL_CHECK, >>>>>>>>>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>>> >>>>>>>>>>> It is not critical if we encounter error at JNI function call >>>>>>>>>>> because >>>>>>>>>>> we cannot set native thread name only. >>>>>>>>>>> So I think that we do not need to leave from launcher process. >>>>>>>>>> >>>>>>>>>> I agree we do not need to abort if an exception occurs (and in >>>>>>>>>> fact >>>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>>> but we >>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>> futher JNI >>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>> extensively throughout the launcher code - so if this usage is >>>>>>>>>> wrong >>>>>>>>>> then it is all wrong! More on this code below ... >>>>>>>>> >>>>>>>>> Isn?t there a risk that: >>>>>>>>> >>>>>>>>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>>>>>> + nameString, JNI_TRUE); >>>>>>>>> >>>>>>>>> will raise an exception? >>>>>>>>> >>>>>>>>> In the least, shouldn?t we clear any possible pending >>>>>>>>> exceptions at >>>>>>>>> the beginning of ?SetNativeThreadName?, as you say, but also at >>>>>>>>> the >>>>>>>>> very end? >>>>>>>> >>>>>>>> I was actually saying at the end, after the call (even though I >>>>>>>> don't >>>>>>>> think any exceptions are possible - except for "async" >>>>>>>> exceptions of >>>>>>>> course). We shouldn't be able to get to the call with any exception >>>>>>>> pending as in that case the JNI calls will be returning NULL and we >>>>>>>> will exit - again this pattern is used extensively in the launcher. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> cheers >>>>>>>>> >>>>>>> >>>>> >>>> >> From yasuenag at gmail.com Thu Apr 21 09:27:32 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 21 Apr 2016 18:27:32 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <57187AD3.30304@oracle.com> References: <56F3F90D.9010408@gmail.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <6F78E357-8E5E-4296-883D-134DD0114847@oracle.com> <57162BBC.7010400@oracle.com> <5716642B.8010207@oracle.com> <571695D3.6060908@oracle.com> <5716A433.1070909@oracle.com> <57177CFA.9020100@oracle.com> <57177EE5.2080508@oracle.com> <5717919A.5090109@oracle.com> <57179966.4050504@gmail.com> <57187AD3.30304@oracle.com> Message-ID: <57189D04.5070904@gmail.com> >>> Well if it is hard then the jbs must be labelled so, noreg-hard. >> >> I agree to label noreg-hard. > > I concur. I added noreg-hard to JBS. Yasumasa On 2016/04/21 16:01, David Holmes wrote: > On 21/04/2016 12:59 AM, Yasumasa Suenaga wrote: >> Hi Kumar, >> >>> Isn't there a management API or something to enumerate the threads ? > > Not that shows native thread names. > > Existing launcher tests should of course be unaffected by this change. > >> On Linux, user apps can get native thread name through >> pthread_getname_np(3). >> However, this function is not called in hotspot and jdk. >> >> So I think it is difficult to get native thread name in all platforms. >> >> >>> Well if it is hard then the jbs must be labelled so, noreg-hard. >> >> I agree to label noreg-hard. > > I concur. > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/20 23:26, Kumar Srinivasan wrote: >>> >>> On 4/20/2016 6:06 AM, David Holmes wrote: >>>> On 20/04/2016 10:58 PM, Kumar Srinivasan wrote: >>>>> >>>>> Hello, >>>>> >>>>> One more thing, what about a launcher regression test ? >>>> >>>> What kind of regression test? I've manually visually inspected the >>>> desired behaviour but a test for it is very problematic. AFAIK there >>>> are no tests for setting the native thread name. >>> >>> Isn't there a management API or something to enumerate the threads ? >>> I am more worried about some seemingly innocuous launcher change >>> causing a regression. >>> >>> Well if it is hard then the jbs must be labelled so, noreg-hard. >>> >>> Kumar >>> >>>> >>>> David >>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>>> >>>>>> On 4/19/2016 1:32 PM, David Holmes wrote: >>>>>>> On 20/04/2016 3:00 AM, Kumar Srinivasan wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> 493 /* Set native thread name. */ >>>>>>>> 494 SetNativeThreadName(env, "main"); >>>>>>>> 495 >>>>>>>> 496 /* Invoke main method. */ >>>>>>>> 497 (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>>> mainArgs); >>>>>>>> >>>>>>>> Supposing an exception is thrown in 494 (a very remote case), >>>>>>>> will we not re-enter the VM in 497 with an exception ? >>>>>>> >>>>>>> Yes as I said: >>>>>>> >>>>>>>> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>>>>> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>>>>> 1714 nameString, JNI_TRUE); >>>>>>>> >>>>>>>> As above NULL_CHECK is fine here, but we should check for and clear >>>>>>>> any pending exception after CallVoidMethod. >>>>>>> >>>>>> Agreed. >>>>>> >>>>>> Kumar >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Kumar >>>>>>>> >>>>>>>>> On 19/04/2016 10:54 PM, Gerard Ziemski wrote: >>>>>>>>>> >>>>>>>>>>> On Apr 19, 2016, at 12:04 AM, David Holmes >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi Gerard, >>>>>>>>>>>> >>>>>>>>>>>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>>>> >: >>>>>>>>>>>>> >>>>>>>>>>>>> hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> Nice work. I have 2 questions: >>>>>>>>>>>>> >>>>>>>>>>>>> ======== >>>>>>>>>>>>> File: java.c >>>>>>>>>>>>> >>>>>>>>>>>>> #1 Shouldn?t we be checking for >>>>>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>>>> after every single JNI call? In this example instead of >>>>>>>>>>>> NULL_CHECK, >>>>>>>>>>>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>>>> >>>>>>>>>>>> It is not critical if we encounter error at JNI function call >>>>>>>>>>>> because >>>>>>>>>>>> we cannot set native thread name only. >>>>>>>>>>>> So I think that we do not need to leave from launcher process. >>>>>>>>>>> >>>>>>>>>>> I agree we do not need to abort if an exception occurs (and in >>>>>>>>>>> fact >>>>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>>>> but we >>>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>>> futher JNI >>>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>>> extensively throughout the launcher code - so if this usage is >>>>>>>>>>> wrong >>>>>>>>>>> then it is all wrong! More on this code below ... >>>>>>>>>> >>>>>>>>>> Isn?t there a risk that: >>>>>>>>>> >>>>>>>>>> (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>>>>>>> + nameString, JNI_TRUE); >>>>>>>>>> >>>>>>>>>> will raise an exception? >>>>>>>>>> >>>>>>>>>> In the least, shouldn?t we clear any possible pending >>>>>>>>>> exceptions at >>>>>>>>>> the beginning of ?SetNativeThreadName?, as you say, but also at >>>>>>>>>> the >>>>>>>>>> very end? >>>>>>>>> >>>>>>>>> I was actually saying at the end, after the call (even though I >>>>>>>>> don't >>>>>>>>> think any exceptions are possible - except for "async" >>>>>>>>> exceptions of >>>>>>>>> course). We shouldn't be able to get to the call with any exception >>>>>>>>> pending as in that case the JNI calls will be returning NULL and we >>>>>>>>> will exit - again this pattern is used extensively in the launcher. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> cheers >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> From rachel.protacio at oracle.com Thu Apr 21 20:11:27 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Thu, 21 Apr 2016 16:11:27 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass Message-ID: <571933EF.6040304@oracle.com> Hello, Please review this fix for the package() and module() functions, making them pure virtual functions of Klass and implementing them in the relevant child classes. This cleans up some verbose and repetitive code that was casting and checking klass types. Also added test cases to runtime/modules/getModuleJNI/GetModule.java, ensuring that all the module() functions work as expected. Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ Tested with jtreg tests in jdk/test (java/lang, java/io, java/security, java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT hotspot and non-colo tests. Thanks! Rachel From david.holmes at oracle.com Fri Apr 22 02:26:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Apr 2016 12:26:49 +1000 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571933EF.6040304@oracle.com> References: <571933EF.6040304@oracle.com> Message-ID: <57198BE9.5080107@oracle.com> Hi Rachel, On 22/04/2016 6:11 AM, Rachel Protacio wrote: > Hello, > > Please review this fix for the package() and module() functions, making > them pure virtual functions of Klass and implementing them in the > relevant child classes. This cleans up some verbose and repetitive code > that was casting and checking klass types. Also added test cases to > runtime/modules/getModuleJNI/GetModule.java, ensuring that all the > module() functions work as expected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ The refactoring all looks good to me (though C++ annoys me in needing to re-declare the functions in each subclass :) ). Cheers, David > Tested with jtreg tests in jdk/test (java/lang, java/io, java/security, > java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT > hotspot and non-colo tests. > > Thanks! > Rachel From yasuenag at gmail.com Fri Apr 22 03:36:51 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 22 Apr 2016 12:36:51 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571635E6.40601@gmail.com> References: <56F3F90D.9010408@gmail.com> <56FB99AD.30207@oracle.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> Message-ID: Hi all, I have uploaded webrev.04 as below. Could you review again? > - hotspot: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ > > - jdk: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ Thanks, Yasumasa 2016/04/19 22:43 "Yasumasa Suenaga" : > > Hi David, > > Thank you for your comment. > I uploaded new webrev. Could you review again? > > - hotspot: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ > > - jdk: > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ > > >> That aside I'm not sure why you do this so late in the process, I would have done it immediately after here: > > > I think that native thread name ("main") should be set just before > main method call. > However, main thread is already started, so I moved it as you suggested. > > >> One thing I dislike about the current structure is that we have to go from char* to java.lang.String to call setNativeName which then calls JVM_SetNativeThreadName which converts the j.l.String back to a char* ! > > > SoI proposed to export new JVM function to set native thread name with > const char *. > > > Thanks, > > Yasumasa > > > > On 2016/04/19 14:04, David Holmes wrote: >> >> Hi Yasumasa, >> >> Thanks for persevering with this to get it into the current form. Sorry I haven't been able to do a detailed review until now. >> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>> >>> Hi Gerard, >>> >>> 2016/04/19 3:14 "Gerard Ziemski" >> >: >>> > >>> > hi Yasumasa, >>> > >>> > Nice work. I have 2 questions: >>> > >>> > ======== >>> > File: java.c >>> > >>> > #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>> after every single JNI call? In this example instead of NULL_CHECK, >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>> >>> It is not critical if we encounter error at JNI function call because >>> we cannot set native thread name only. >>> So I think that we do not need to leave from launcher process. >> >> >> I agree we do not need to abort if an exception occurs (and in fact I don't think an exception is even possible from this code), but we should ensure any pending exception is cleared before any futher JNI calls might be made. Note that NULL_CHECK is already used extensively throughout the launcher code - so if this usage is wrong then it is all wrong! More on this code below ... >> >> Other comments: >> >> hotspot/src/share/vm/prims/jvm.cpp >> >> Please add a comment to the method now that you removed the internal comment: >> >> // Sets the native thread name for a JavaThread. If specifically >> // requested JNI-attached threads can also have their native name set; >> // otherwise we do not modify JNI-attached threads as it may interfere >> // with the application that created them. >> >> --- >> >> jdk/src/java.base/share/classes/java/lang/Thread.java >> >> Please add the following comments: >> >> + // Don't modify JNI-attached threads >> setNativeName(name, false); >> >> + // May be called directly via JNI or reflection (when permitted) to >> + // allow JNI-attached threads to set their native name >> private native void setNativeName(String name, boolean allowAttachedThread); >> >> --- >> >> jd/src/java.base/share/native/libjli/java.c >> >> 328 #define LEAVE() \ >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >> >> I was going to suggest this be set later, but realized we have to be attached to do this and that happens inside DestroyJavaVM. :) >> >> + /* Set native thread name. */ >> + SetNativeThreadName(env, "main"); >> >> The comment is redundant given the name of the method. That aside I'm not sure why you do this so late in the process, I would have done it immediately after here: >> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >> 388 exit(1); >> 389 } >> + SetNativeThreadName(env, "main"); >> >> >> + /** >> + * Set native thread name as possible. >> + */ >> >> Other than the as->if change I'm unclear where the "possible" bit comes into play - why would it not be possible? >> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >> 1706 NULL_CHECK(currentThreadID = (*env)->GetStaticMethodID(env, cls, >> 1707 "currentThread", "()Ljava/lang/Thread;")); >> 1708 NULL_CHECK(currentThread = (*env)->CallStaticObjectMethod(env, cls, >> 1709 currentThreadID)); >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, cls, >> 1711 "setNativeName", "(Ljava/lang/String;Z)V")); >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >> 1714 nameString, JNI_TRUE); >> >> As above NULL_CHECK is fine here, but we should check for and clear any pending exception after CallVoidMethod. >> >> One thing I dislike about the current structure is that we have to go from char* to java.lang.String to call setNativeName which then calls JVM_SetNativeThreadName which converts the j.l.String back to a char* ! Overall I wonder about the affect on startup cost. But if there is an issue we can revisit this. >> >> Thanks, >> David >> ----- >> >> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set native thread >>> name if possible.? not "Set native thread name as possible.?? >>> >>> Sorry for my bad English :-) >>> >>> Thanks, >>> >>> Yasumasa >>> >>> > cheers >>> > >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >> > wrote: >>> > > >>> > > Hi David, >>> > > >>> > > I uploaded new webrev: >>> > > >>> > > - hotspot: >>> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>> > > >>> > > - jdk: >>> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>> > > >>> > > >>> > >> it won't work unless you change the semantics of setName so I'm >>> not sure what you were thinking here. To take advantage of an arg taking >>> JVM_SetNativThreadName you would need to call it directly as no Java >>> code will call it . ??? >>> > > >>> > > I added a flag for setting native thread name to JNI-attached thread. >>> > > This change can set native thread name if main thread changes to >>> JNI-attached thread. >>> > > >>> > > >>> > > Thanks, >>> > > >>> > > Yasumasa >>> > > >>> > > >>> > > On 2016/04/16 16:11, David Holmes wrote: >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>> > >>> Hi David, >>> > >>> >>> > >>>> That change in behaviour may be a problem, it could be considered a >>> > >>>> regression that setName stops setting the native thread main, even >>> > >>>> though we never really intended it to work in the first place. >>> :( Such >>> > >>>> a change needs to go through CCC. >>> > >>> >>> > >>> I understood. >>> > >>> Can I send CCC request? >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>> > >> >>> > >> Sorry you can't file a CCC request, you would need a sponsor for >>> that. But at this stage I don't think I agree with the proposed change >>> because of the change in behaviour - there's no way to restore the >>> "broken" behaviour. >>> > >> >>> > >>> I want to continue to discuss about it on JDK-8154331 [1]. >>> > >> >>> > >> Okay we can do that. >>> > >> >>> > >>> >>> > >>>> Further, we expect the launcher to use the supported JNI >>> interface (as >>> > >>>> other processes would), not the internal JVM interface that >>> exists for >>> > >>>> the JDK sources to communicate with the JVM. >>> > >>> >>> > >>> I think that we do not use JVM interface if we add new method in >>> > >>> LauncherHelper as below: >>> > >>> ---------------- >>> > >>> diff -r f02139a1ac84 >>> > >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> > >>> --- a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>> > >>> +++ b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>> > >>> @@ -960,4 +960,8 @@ >>> > >>> else >>> > >>> return md.toNameAndVersion() + " (" + loc + ")"; >>> > >>> } >>> > >>> + >>> > >>> + static void setNativeThreadName(String name) { >>> > >>> + Thread.currentThread().setName(name); >>> > >>> + } >>> > >> >>> > >> You could also make that call via JNI directly, so not sure the >>> helper adds much here. But it won't work unless you change the semantics >>> of setName so I'm not sure what you were thinking here. To take >>> advantage of an arg taking JVM_SetNativThreadName you would need to call >>> it directly as no Java code will call it . ??? >>> > >> >>> > >> David >>> > >> ----- >>> > >> >>> > >>> } >>> > >>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 14:19:30 >>> > >>> 2016 +0000 >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 11:25:53 >>> > >>> 2016 +0900 >>> > >>> @@ -125,6 +125,7 @@ >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>> > >>> >>> > >>> static void SetPaths(int argc, char **argv); >>> > >>> >>> > >>> @@ -325,6 +326,7 @@ >>> > >>> * mainThread.isAlive() to work as expected. >>> > >>> */ >>> > >>> #define LEAVE() \ >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>> > >>> do { \ >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>> > >>> @@ -488,6 +490,9 @@ >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>> > >>> >>> > >>> + /* Set native thread name. */ >>> > >>> + SetNativeThreadName(env, "main"); >>> > >>> + >>> > >>> /* Invoke main method. */ >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>> > >>> >>> > >>> @@ -1686,6 +1691,22 @@ >>> > >>> joptString); >>> > >>> } >>> > >>> >>> > >>> +/** >>> > >>> + * Set native thread name as possible. >>> > >>> + */ >>> > >>> +static void >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>> > >>> +{ >>> > >>> + jmethodID setNativeThreadNameID; >>> > >>> + jstring nameString; >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>> > >>> + NULL_CHECK(cls); >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>> (*env)->GetStaticMethodID(env, cls, >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, setNativeThreadNameID, >>> > >>> nameString); >>> > >>> +} >>> > >>> + >>> > >>> /* >>> > >>> * Prints default usage or the Xusage message, see >>> > >>> sun.launcher.LauncherHelper.java >>> > >>> */ >>> > >>> ---------------- >>> > >>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>> > >>> >>> > >>>> However this is still a change to the exported JVM interface and so >>> > >>>> has to be approved. >>> > >>> >>> > >>> Do you mean that this change needs CCC? >>> > >>> >>> > >>> >>> > >>> Thanks, >>> > >>> >>> > >>> Yasumasa >>> > >>> >>> > >>> >>> > >>> [1] >>> > >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>> > >>> >>> > >>> >>> > >>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>> > >>>>> Hi David, >>> > >>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>> > >>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>> thread and >>> > >>>>>> JNI attached threads >>> > >>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>> > >>>>> I will send review request to hotspot-runtime-dev. >>> > >>>>> >>> > >>>>> >>> > >>>>>> Though that will introduce a change in behaviour by itself as >>> setName >>> > >>>>>> will no longer set the native name for the main thread. >>> > >>>>> >>> > >>>>> I know. >>> > >>>> >>> > >>>> That change in behaviour may be a problem, it could be considered a >>> > >>>> regression that setName stops setting the native thread main, even >>> > >>>> though we never really intended it to work in the first place. >>> :( Such >>> > >>>> a change needs to go through CCC. >>> > >>>> >>> > >>>>> I checked changeset history. >>> > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, and it is >>> > >>>>> backported JDK 8. >>> > >>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>> > >>>> >>> > >>>>> However, this function seems to be called from >>> Thread#setNativeName() >>> > >>>>> only. >>> > >>>>> In addition, Thread#setNativeName() is private method. >>> > >>>>> >>> > >>>>> Thus I think that we can add an argument to >>> JVM_SetNativeThreadName() >>> > >>>>> for force setting. >>> > >>>>> (e.g. "bool forced") >>> > >>>>> >>> > >>>>> It makes a change of JVM API. >>> > >>>>> However, this function is NOT public, so I think we can add one >>> more >>> > >>>>> argument. >>> > >>>>> >>> > >>>>> What do you think about this? >>> > >>>>> If it is accepted, we can set native thread name from Java >>> launcher. >>> > >>>> >>> > >>>> The private/public aspect of the Java API is not really at >>> issue. Yes >>> > >>>> we would add another arg to the JVM function to allow it to apply to >>> > >>>> JNI-attached threads as well (I'd prefer the arg reflect that >>> not just >>> > >>>> "force"). However this is still a change to the exported JVM >>> interface >>> > >>>> and so has to be approved. Further, we expect the launcher to >>> use the >>> > >>>> supported JNI interface (as other processes would), not the internal >>> > >>>> JVM interface that exists for the JDK sources to communicate >>> with the >>> > >>>> JVM. >>> > >>>> >>> > >>>> David >>> > >>>> ----- >>> > >>>> >>> > >>>>> >>> > >>>>> Thanks, >>> > >>>>> >>> > >>>>> Yasumasa >>> > >>>>> >>> > >>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>> > >>>>>> Hi Yasumasa, >>> > >>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>> > >>>>>>> Hi David, >>> > >>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as being a >>> JNI-attached >>> > >>>>>>>> thread seems accidental to me >>> > >>>>>>> >>> > >>>>>>> Should I file it to JBS? >>> > >>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>> > >>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>> thread and >>> > >>>>>> JNI attached threads >>> > >>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by itself as >>> setName >>> > >>>>>> will no longer set the native name for the main thread. >>> > >>>>>> >>> > >>>>>>> I think that we can fix as below: >>> > >>>>>>> --------------- >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 >>> 2016 +0200 >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 >>> 2016 +0900 >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>> > >>>>>>> #endif // INCLUDE_JVMCI >>> > >>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>> > >>>>>>> main_thread->initialize_thread_current(); >>> > >>>>>>> // must do this before set_active_handles >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>> > >>>>>>> // Notify JVMTI agents that VM initialization is complete >>> - nop if >>> > >>>>>>> no agents. >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>> > >>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>> > >>>>>>> + >>> > >>>>>> >>> > >>>>>> I think we can do this straight after the JavaThread constructor. >>> > >>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>> > >>>>>>> vm_exit_during_initialization("Failed to start tracing >>> > >>>>>>> backend."); >>> > >>>>>>> } >>> > >>>>>>> --------------- >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>>> If it wants to name its native threads then it is free to do so, >>> > >>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change native >>> thread name >>> > >>>>>>> when the caller thread is JNI-attached thread. >>> > >>>>>>> However, I think that it should be changed if Java developer >>> calls >>> > >>>>>>> Thread#setName() explicitly. >>> > >>>>>>> It is not the same of changing native thread name at >>> > >>>>>>> Threads::create_vm(). >>> > >>>>>>> >>> > >>>>>>> If it is allowed, I want to fix SetNativeThreadName() as below. >>> > >>>>>>> What do you think about this? >>> > >>>>>> >>> > >>>>>> The decision to not change the name of JNI-attached threads was a >>> > >>>>>> deliberate one** - this functionality originated with the OSX >>> port and >>> > >>>>>> it was reported that the initial feedback with this feature was to >>> > >>>>>> ensure it didn't mess with thread names that had been set by >>> the host >>> > >>>>>> process. If we do as you propose then we will just have an >>> > >>>>>> inconsistency for people to complain about: "why does my >>> native thread >>> > >>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>> > >>>>>> >>> > >>>>>> ** If you follow the bugs and related discussions on this, the >>> > >>>>>> semantics and limitations (truncation, current thread only, >>> non-JNI >>> > >>>>>> threads only) of setting the native thread name were supposed >>> to be >>> > >>>>>> documented in the release notes - but as far as I can see that >>> never >>> > >>>>>> happened. :( >>> > >>>>>> >>> > >>>>>> My position on this remains that if it is desirable for the main >>> > >>>>>> thread (and DestroyJavaVM thread) to have native names then the >>> > >>>>>> launcher needs to be setting them using the available platform >>> APIs. >>> > >>>>>> Unfortunately this is complicated - as evidenced by the VM >>> code for >>> > >>>>>> this - due to the need to verify API availability. >>> > >>>>>> >>> > >>>>>> Any change in behaviour in relation to Thread.setName would >>> have to go >>> > >>>>>> through our CCC process I think. But a change in the launcher >>> would >>> > >>>>>> not. >>> > >>>>>> >>> > >>>>>> Sorry. >>> > >>>>>> >>> > >>>>>> David >>> > >>>>>> ----- >>> > >>>>>> >>> > >>>>>>> --------------- >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 >>> 2016 +0200 >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 >>> 2016 +0900 >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>> > >>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>> > >>>>>>> // Thread naming only supported for the current thread, >>> doesn't >>> > >>>>>>> work >>> > >>>>>>> for >>> > >>>>>>> // target threads. >>> > >>>>>>> - if (Thread::current() == thr && >>> !thr->has_attached_via_jni()) { >>> > >>>>>>> + if (Thread::current() == thr) { >>> > >>>>>>> // we don't set the name of an attached thread to avoid >>> stepping >>> > >>>>>>> // on other programs >>> > >>>>>>> const char *thread_name = >>> > >>>>>>> >>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>> > >>>>>>> --------------- >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> Thanks, >>> > >>>>>>> >>> > >>>>>>> Yasumasa >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>> > >>>>>>>>> Roger, >>> > >>>>>>>>> Thanks for your comment! >>> > >>>>>>>>> >>> > >>>>>>>>> David, >>> > >>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>> > >>>>>>>>>>>> exposing >>> > >>>>>>>>>>>> a new JVM function this way. >>> > >>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after initializing VM (before >>> > >>>>>>>>> calling >>> > >>>>>>>>> main method), >>> > >>>>>>>>> I could set native thread name. >>> > >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). So we >>> can't >>> > >>>>>>>>> set >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>> > >>>>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier this morning. >>> Which, >>> > >>>>>>>> unfortunately, takes me back to the basic premise here that >>> we don't >>> > >>>>>>>> set the name of threads not created by the JVM. The fact >>> that the >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached thread seems >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only working by >>> > >>>>>>>> accident for the initial attach, and can't be used for the >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >>> named at >>> > >>>>>>>> the native level. >>> > >>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has to be >>> treated like >>> > >>>>>>>> any other process that might host a JVM. If it wants to name its >>> > >>>>>>>> native threads then it is free to do so, but I would not be >>> exporting >>> > >>>>>>>> a function from the JVM to do that - it would have to use the OS >>> > >>>>>>>> specific API's for that on a platform-by-platform basis. >>> > >>>>>>>> >>> > >>>>>>>> Sorry. >>> > >>>>>>>> >>> > >>>>>>>> David >>> > >>>>>>>> ----- >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>> Thanks, >>> > >>>>>>>>> >>> > >>>>>>>>> Yasumasa >>> > >>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>> > >>>>>>>>>> Hi, >>> > >>>>>>>>>> >>> > >>>>>>>>>> Comments: >>> > >>>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but perform >>> different >>> > >>>>>>>>>> functions: >>> > >>>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>> > >>>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the current thread, the >>> second >>> > >>>>>>>>>> one a >>> > >>>>>>>>>> specific java thread. >>> > >>>>>>>>>> It would seem useful for there to be a comment somewhere >>> about >>> > >>>>>>>>>> what >>> > >>>>>>>>>> the new function does. >>> > >>>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to (void*) >>> > >>>>>>>>>> instead of >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>> > >>>>>>>>>> as is done on unix and mac. >>> > >>>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>> > >>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs >>> used at >>> > >>>>>>>>>> line 730 >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast >>> on the >>> > >>>>>>>>>> same >>> > >>>>>>>>>> line as dlsym... >>> > >>>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>> > >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>> > >>>>>>>>>>>> That is an interesting question which I haven't had time to >>> > >>>>>>>>>>>> check - >>> > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>> thread >>> > >>>>>>>>>>>> then >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>> should >>> > >>>>>>>>>>>> work >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I confirmed >>> native >>> > >>>>>>>>>>> thread name (test) was set. >>> > >>>>>>>>>>> --------- >>> > >>>>>>>>>>> public class Sleep{ >>> > >>>>>>>>>>> public static void main(String[] args) throws Exception{ >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>> > >>>>>>>>>>> Thread.sleep(3600000); >>> > >>>>>>>>>>> } >>> > >>>>>>>>>>> } >>> > >>>>>>>>>>> --------- >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>> > >>>>>>>>>>>> exposing >>> > >>>>>>>>>>>> a new JVM function this way. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>> > >>>>>>>>>>>>> Hi, >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>> > >>>>>>>>>>>>>> Hi, >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>> > >>>>>>>>>>>>>>> Hi David, >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native thread >>> name, and JLI >>> > >>>>>>>>>>>>>>> uses it >>> > >>>>>>>>>>>>>>> in new webrev. >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>> core-libs will >>> > >>>>>>>>>>>>>> need to >>> > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - now cc'd. >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>> Thread.setName >>> > >>>>>>>>>>>>>> rather >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No hotspot changes >>> > >>>>>>>>>>>>>> needed in >>> > >>>>>>>>>>>>>> that case. >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use Thread#setName() in >>> > >>>>>>>>>>>>> Thread#init(), >>> > >>>>>>>>>>>>> but I could not change native thread name. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, which is >>> why the >>> > >>>>>>>>>>>> native >>> > >>>>>>>>>>>> name is not set. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I haven't had time to >>> > >>>>>>>>>>>> check - >>> > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>> thread >>> > >>>>>>>>>>>> then >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>> should >>> > >>>>>>>>>>>> work >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our treatment of >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I don't like >>> > >>>>>>>>>>>> exposing >>> > >>>>>>>>>>>> a new JVM function this way. >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>> > >>>>>>>>>>>> David >>> > >>>>>>>>>>>> ----- >>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a function to set >>> native >>> > >>>>>>>>>>>>> thread name. >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>> > >>>>>>>>>>>>> >>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>> > >>>>>>>>>>>>>> David >>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>> > >>>>>>>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have been on >>> > >>>>>>>>>>>>>>>> vacation). >>> > >>>>>>>>>>>>>>>> This >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct as we >>> do not >>> > >>>>>>>>>>>>>>>> set the >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which includes the >>> > >>>>>>>>>>>>>>>> "main" >>> > >>>>>>>>>>>>>>>> thread. >>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>> > >>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>> > >>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >> >: >>> > >>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>> > >>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>> > >>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>> > >>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>> > >>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>> > >>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>> > >>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>> > >>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga wrote: >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>: >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa Suenaga wrote: >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>: >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- a/src/share/vm/runtime/thread.cpp Thu >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ b/src/share/vm/runtime/thread.cpp Thu >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>> JavaThread(); >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> main_thread->set_thread_state(_thread_in_vm); >>> > >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->initialize_thread_current(); >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>> main_thread->set_native_thread_name("main"); >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>> set_active_handles >>> > >>>>>>>>>>>>>>>>>>>>>> >> > main_thread->record_stack_base_and_size(); >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread >>> name in >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or setName(). >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, native >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>> > >>>>>>>>>>>>>>>>>>>>>> name >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already >>> starte >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting thrrad name >>> > >>>>>>>>>>>>>>>>>>>>>> should >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then something like >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp Tue >>> Mar 29 >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp Wed >>> Mar 30 >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* initial_thread_name = >>> "main"; >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>> > >>>>>>>>>>>>>>>>>>>>>> >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>> > >>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>> > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >>> thread); >>> > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_priority(thread_oop(), >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>> > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>> > >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>> > >>>>>>>>>>>>>>>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>> > >>>>>>>>>>>>>>>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, thread_oop, >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself 'java' and >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>> > >>>>>>>>>>>>>>>>>>>>>> this >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>> > >>>>>>>>>>>>>>>>>>>>>> just >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process (and >>> thus >>> > >>>>>>>>>>>>>>>>>>>>>> the >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process is not >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>> JavaThread. So I >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>> > >>>>>>>>>>>>>>>>>>>>>> not >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since >>> we want >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>> > >>>>>>>>>>>>>>>>>>>>>> native >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name might >>> have >>> > >>>>>>>>>>>>>>>>>>>>>> some >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like 'Java Main >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java >>> launcher - e.g. >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread name, >>> I think >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa >>> Suenaga wrote: >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread >>> name via >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not have it. >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, and main >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread should have >>> > >>>>>>>>>>>>>>>>>>>>>> native >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you review it? >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>> > >>> From david.holmes at oracle.com Fri Apr 22 06:33:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Apr 2016 16:33:44 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> Message-ID: <5719C5C8.3020705@oracle.com> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: > Hi all, > > I have uploaded webrev.04 as below. > Could you review again? > > > - hotspot: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ Looks fine. > > > > - jdk: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ As per private email (but repeated here on the record) in java.c: 715 if ((*env)->ExceptionOccurred(env)) { 1716 JLI_ReportExceptionDescription(env); 1717 } I don't think we need to report the exception, but can just ignore it. Either way we have to clear the exception before continuing. Thanks, David > Thanks, > > Yasumasa > > 2016/04/19 22:43 "Yasumasa Suenaga" >: > > > > Hi David, > > > > Thank you for your comment. > > I uploaded new webrev. Could you review again? > > > > - hotspot: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ > > > > - jdk: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ > > > > > >> That aside I'm not sure why you do this so late in the process, I > would have done it immediately after here: > > > > > > I think that native thread name ("main") should be set just before > > main method call. > > However, main thread is already started, so I moved it as you suggested. > > > > > >> One thing I dislike about the current structure is that we have to > go from char* to java.lang.String to call setNativeName which then calls > JVM_SetNativeThreadName which converts the j.l.String back to a char* ! > > > > > > SoI proposed to export new JVM function to set native thread name with > > const char *. > > > > > > Thanks, > > > > Yasumasa > > > > > > > > On 2016/04/19 14:04, David Holmes wrote: > >> > >> Hi Yasumasa, > >> > >> Thanks for persevering with this to get it into the current form. > Sorry I haven't been able to do a detailed review until now. > >> > >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: > >>> > >>> Hi Gerard, > >>> > >>> 2016/04/19 3:14 "Gerard Ziemski" > >>> >>: > >>> > > >>> > hi Yasumasa, > >>> > > >>> > Nice work. I have 2 questions: > >>> > > >>> > ======== > >>> > File: java.c > >>> > > >>> > #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? > >>> after every single JNI call? In this example instead of NULL_CHECK, > >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? > >>> > >>> It is not critical if we encounter error at JNI function call because > >>> we cannot set native thread name only. > >>> So I think that we do not need to leave from launcher process. > >> > >> > >> I agree we do not need to abort if an exception occurs (and in fact > I don't think an exception is even possible from this code), but we > should ensure any pending exception is cleared before any futher JNI > calls might be made. Note that NULL_CHECK is already used extensively > throughout the launcher code - so if this usage is wrong then it is all > wrong! More on this code below ... > >> > >> Other comments: > >> > >> hotspot/src/share/vm/prims/jvm.cpp > >> > >> Please add a comment to the method now that you removed the internal > comment: > >> > >> // Sets the native thread name for a JavaThread. If specifically > >> // requested JNI-attached threads can also have their native name set; > >> // otherwise we do not modify JNI-attached threads as it may interfere > >> // with the application that created them. > >> > >> --- > >> > >> jdk/src/java.base/share/classes/java/lang/Thread.java > >> > >> Please add the following comments: > >> > >> + // Don't modify JNI-attached threads > >> setNativeName(name, false); > >> > >> + // May be called directly via JNI or reflection (when permitted) to > >> + // allow JNI-attached threads to set their native name > >> private native void setNativeName(String name, boolean > allowAttachedThread); > >> > >> --- > >> > >> jd/src/java.base/share/native/libjli/java.c > >> > >> 328 #define LEAVE() \ > >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ > >> > >> I was going to suggest this be set later, but realized we have to be > attached to do this and that happens inside DestroyJavaVM. :) > >> > >> + /* Set native thread name. */ > >> + SetNativeThreadName(env, "main"); > >> > >> The comment is redundant given the name of the method. That aside > I'm not sure why you do this so late in the process, I would have done > it immediately after here: > >> > >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { > >> 387 JLI_ReportErrorMessage(JVM_ERROR1); > >> 388 exit(1); > >> 389 } > >> + SetNativeThreadName(env, "main"); > >> > >> > >> + /** > >> + * Set native thread name as possible. > >> + */ > >> > >> Other than the as->if change I'm unclear where the "possible" bit > comes into play - why would it not be possible? > >> > >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); > >> 1706 NULL_CHECK(currentThreadID = (*env)->GetStaticMethodID(env, > cls, > >> 1707 "currentThread", > "()Ljava/lang/Thread;")); > >> 1708 NULL_CHECK(currentThread = > (*env)->CallStaticObjectMethod(env, cls, > >> 1709 currentThreadID)); > >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, cls, > >> 1711 "setNativeName", > "(Ljava/lang/String;Z)V")); > >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); > >> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, > >> 1714 nameString, JNI_TRUE); > >> > >> As above NULL_CHECK is fine here, but we should check for and clear > any pending exception after CallVoidMethod. > >> > >> One thing I dislike about the current structure is that we have to > go from char* to java.lang.String to call setNativeName which then calls > JVM_SetNativeThreadName which converts the j.l.String back to a char* ! > Overall I wonder about the affect on startup cost. But if there is an > issue we can revisit this. > >> > >> Thanks, > >> David > >> ----- > >> > >> > >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set native > thread > >>> name if possible.? not "Set native thread name as possible.?? > >>> > >>> Sorry for my bad English :-) > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > cheers > >>> > > >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga > > >>> >> wrote: > >>> > > > >>> > > Hi David, > >>> > > > >>> > > I uploaded new webrev: > >>> > > > >>> > > - hotspot: > >>> > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ > >>> > > > >>> > > - jdk: > >>> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ > >>> > > > >>> > > > >>> > >> it won't work unless you change the semantics of setName so I'm > >>> not sure what you were thinking here. To take advantage of an arg > taking > >>> JVM_SetNativThreadName you would need to call it directly as no Java > >>> code will call it . ??? > >>> > > > >>> > > I added a flag for setting native thread name to JNI-attached > thread. > >>> > > This change can set native thread name if main thread changes to > >>> JNI-attached thread. > >>> > > > >>> > > > >>> > > Thanks, > >>> > > > >>> > > Yasumasa > >>> > > > >>> > > > >>> > > On 2016/04/16 16:11, David Holmes wrote: > >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: > >>> > >>> Hi David, > >>> > >>> > >>> > >>>> That change in behaviour may be a problem, it could be > considered a > >>> > >>>> regression that setName stops setting the native thread > main, even > >>> > >>>> though we never really intended it to work in the first place. > >>> :( Such > >>> > >>>> a change needs to go through CCC. > >>> > >>> > >>> > >>> I understood. > >>> > >>> Can I send CCC request? > >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) > >>> > >> > >>> > >> Sorry you can't file a CCC request, you would need a sponsor for > >>> that. But at this stage I don't think I agree with the proposed change > >>> because of the change in behaviour - there's no way to restore the > >>> "broken" behaviour. > >>> > >> > >>> > >>> I want to continue to discuss about it on JDK-8154331 [1]. > >>> > >> > >>> > >> Okay we can do that. > >>> > >> > >>> > >>> > >>> > >>>> Further, we expect the launcher to use the supported JNI > >>> interface (as > >>> > >>>> other processes would), not the internal JVM interface that > >>> exists for > >>> > >>>> the JDK sources to communicate with the JVM. > >>> > >>> > >>> > >>> I think that we do not use JVM interface if we add new method in > >>> > >>> LauncherHelper as below: > >>> > >>> ---------------- > >>> > >>> diff -r f02139a1ac84 > >>> > >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java > >>> > >>> --- > a/src/java.base/share/classes/sun/launcher/LauncherHelper.java > >>> > >>> Wed Apr 13 14:19:30 2016 +0000 > >>> > >>> +++ > b/src/java.base/share/classes/sun/launcher/LauncherHelper.java > >>> > >>> Sat Apr 16 11:25:53 2016 +0900 > >>> > >>> @@ -960,4 +960,8 @@ > >>> > >>> else > >>> > >>> return md.toNameAndVersion() + " (" + loc + ")"; > >>> > >>> } > >>> > >>> + > >>> > >>> + static void setNativeThreadName(String name) { > >>> > >>> + Thread.currentThread().setName(name); > >>> > >>> + } > >>> > >> > >>> > >> You could also make that call via JNI directly, so not sure the > >>> helper adds much here. But it won't work unless you change the > semantics > >>> of setName so I'm not sure what you were thinking here. To take > >>> advantage of an arg taking JVM_SetNativThreadName you would need to > call > >>> it directly as no Java code will call it . ??? > >>> > >> > >>> > >> David > >>> > >> ----- > >>> > >> > >>> > >>> } > >>> > >>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c > >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 > 14:19:30 > >>> > >>> 2016 +0000 > >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 > 11:25:53 > >>> > >>> 2016 +0900 > >>> > >>> @@ -125,6 +125,7 @@ > >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); > >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); > >>> > >>> static void ListModules(JNIEnv* env, char *optString); > >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); > >>> > >>> > >>> > >>> static void SetPaths(int argc, char **argv); > >>> > >>> > >>> > >>> @@ -325,6 +326,7 @@ > >>> > >>> * mainThread.isAlive() to work as expected. > >>> > >>> */ > >>> > >>> #define LEAVE() \ > >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ > >>> > >>> do { \ > >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ > >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ > >>> > >>> @@ -488,6 +490,9 @@ > >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); > >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); > >>> > >>> > >>> > >>> + /* Set native thread name. */ > >>> > >>> + SetNativeThreadName(env, "main"); > >>> > >>> + > >>> > >>> /* Invoke main method. */ > >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, > mainArgs); > >>> > >>> > >>> > >>> @@ -1686,6 +1691,22 @@ > >>> > >>> joptString); > >>> > >>> } > >>> > >>> > >>> > >>> +/** > >>> > >>> + * Set native thread name as possible. > >>> > >>> + */ > >>> > >>> +static void > >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) > >>> > >>> +{ > >>> > >>> + jmethodID setNativeThreadNameID; > >>> > >>> + jstring nameString; > >>> > >>> + jclass cls = GetLauncherHelperClass(env); > >>> > >>> + NULL_CHECK(cls); > >>> > >>> + NULL_CHECK(setNativeThreadNameID = > >>> (*env)->GetStaticMethodID(env, cls, > >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); > >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); > >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, > setNativeThreadNameID, > >>> > >>> nameString); > >>> > >>> +} > >>> > >>> + > >>> > >>> /* > >>> > >>> * Prints default usage or the Xusage message, see > >>> > >>> sun.launcher.LauncherHelper.java > >>> > >>> */ > >>> > >>> ---------------- > >>> > >>> > >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). > >>> > >>> > >>> > >>>> However this is still a change to the exported JVM > interface and so > >>> > >>>> has to be approved. > >>> > >>> > >>> > >>> Do you mean that this change needs CCC? > >>> > >>> > >>> > >>> > >>> > >>> Thanks, > >>> > >>> > >>> > >>> Yasumasa > >>> > >>> > >>> > >>> > >>> > >>> [1] > >>> > >>> > >>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On 2016/04/16 7:26, David Holmes wrote: > >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: > >>> > >>>>> Hi David, > >>> > >>>>> > >>> > >>>>>> I think it is a bug based on the comment here: > >>> > >>>>>> > >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main > >>> thread and > >>> > >>>>>> JNI attached threads > >>> > >>>>> > >>> > >>>>> I filed it to JBS as JDK-8154331. > >>> > >>>>> I will send review request to hotspot-runtime-dev. > >>> > >>>>> > >>> > >>>>> > >>> > >>>>>> Though that will introduce a change in behaviour by itself as > >>> setName > >>> > >>>>>> will no longer set the native name for the main thread. > >>> > >>>>> > >>> > >>>>> I know. > >>> > >>>> > >>> > >>>> That change in behaviour may be a problem, it could be > considered a > >>> > >>>> regression that setName stops setting the native thread > main, even > >>> > >>>> though we never really intended it to work in the first place. > >>> :( Such > >>> > >>>> a change needs to go through CCC. > >>> > >>>> > >>> > >>>>> I checked changeset history. > >>> > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, > and it is > >>> > >>>>> backported JDK 8. > >>> > >>>> > >>> > >>>> Yes this all came in as part of the OSX port in 7u2. > >>> > >>>> > >>> > >>>>> However, this function seems to be called from > >>> Thread#setNativeName() > >>> > >>>>> only. > >>> > >>>>> In addition, Thread#setNativeName() is private method. > >>> > >>>>> > >>> > >>>>> Thus I think that we can add an argument to > >>> JVM_SetNativeThreadName() > >>> > >>>>> for force setting. > >>> > >>>>> (e.g. "bool forced") > >>> > >>>>> > >>> > >>>>> It makes a change of JVM API. > >>> > >>>>> However, this function is NOT public, so I think we can > add one > >>> more > >>> > >>>>> argument. > >>> > >>>>> > >>> > >>>>> What do you think about this? > >>> > >>>>> If it is accepted, we can set native thread name from Java > >>> launcher. > >>> > >>>> > >>> > >>>> The private/public aspect of the Java API is not really at > >>> issue. Yes > >>> > >>>> we would add another arg to the JVM function to allow it to > apply to > >>> > >>>> JNI-attached threads as well (I'd prefer the arg reflect that > >>> not just > >>> > >>>> "force"). However this is still a change to the exported JVM > >>> interface > >>> > >>>> and so has to be approved. Further, we expect the launcher to > >>> use the > >>> > >>>> supported JNI interface (as other processes would), not the > internal > >>> > >>>> JVM interface that exists for the JDK sources to communicate > >>> with the > >>> > >>>> JVM. > >>> > >>>> > >>> > >>>> David > >>> > >>>> ----- > >>> > >>>> > >>> > >>>>> > >>> > >>>>> Thanks, > >>> > >>>>> > >>> > >>>>> Yasumasa > >>> > >>>>> > >>> > >>>>> > >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: > >>> > >>>>>> Hi Yasumasa, > >>> > >>>>>> > >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: > >>> > >>>>>>> Hi David, > >>> > >>>>>>> > >>> > >>>>>>>> The fact that the "main" thread is not tagged as being a > >>> JNI-attached > >>> > >>>>>>>> thread seems accidental to me > >>> > >>>>>>> > >>> > >>>>>>> Should I file it to JBS? > >>> > >>>>>> > >>> > >>>>>> I think it is a bug based on the comment here: > >>> > >>>>>> > >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main > >>> thread and > >>> > >>>>>> JNI attached threads > >>> > >>>>>> > >>> > >>>>>> Though that will introduce a change in behaviour by itself as > >>> setName > >>> > >>>>>> will no longer set the native name for the main thread. > >>> > >>>>>> > >>> > >>>>>>> I think that we can fix as below: > >>> > >>>>>>> --------------- > >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp > >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 > >>> 2016 +0200 > >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 > >>> 2016 +0900 > >>> > >>>>>>> @@ -3592,7 +3592,7 @@ > >>> > >>>>>>> #endif // INCLUDE_JVMCI > >>> > >>>>>>> > >>> > >>>>>>> // Attach the main thread to this os thread > >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); > >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); > >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); > >>> > >>>>>>> main_thread->initialize_thread_current(); > >>> > >>>>>>> // must do this before set_active_handles > >>> > >>>>>>> @@ -3776,6 +3776,9 @@ > >>> > >>>>>>> // Notify JVMTI agents that VM initialization is complete > >>> - nop if > >>> > >>>>>>> no agents. > >>> > >>>>>>> JvmtiExport::post_vm_initialized(); > >>> > >>>>>>> > >>> > >>>>>>> + // Change attach status to "attached" > >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); > >>> > >>>>>>> + > >>> > >>>>>> > >>> > >>>>>> I think we can do this straight after the JavaThread > constructor. > >>> > >>>>>> > >>> > >>>>>>> if (TRACE_START() != JNI_OK) { > >>> > >>>>>>> vm_exit_during_initialization("Failed to start tracing > >>> > >>>>>>> backend."); > >>> > >>>>>>> } > >>> > >>>>>>> --------------- > >>> > >>>>>>> > >>> > >>>>>>> > >>> > >>>>>>>> If it wants to name its native threads then it is free > to do so, > >>> > >>>>>>> > >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change native > >>> thread name > >>> > >>>>>>> when the caller thread is JNI-attached thread. > >>> > >>>>>>> However, I think that it should be changed if Java developer > >>> calls > >>> > >>>>>>> Thread#setName() explicitly. > >>> > >>>>>>> It is not the same of changing native thread name at > >>> > >>>>>>> Threads::create_vm(). > >>> > >>>>>>> > >>> > >>>>>>> If it is allowed, I want to fix SetNativeThreadName() as > below. > >>> > >>>>>>> What do you think about this? > >>> > >>>>>> > >>> > >>>>>> The decision to not change the name of JNI-attached > threads was a > >>> > >>>>>> deliberate one** - this functionality originated with the OSX > >>> port and > >>> > >>>>>> it was reported that the initial feedback with this > feature was to > >>> > >>>>>> ensure it didn't mess with thread names that had been set by > >>> the host > >>> > >>>>>> process. If we do as you propose then we will just have an > >>> > >>>>>> inconsistency for people to complain about: "why does my > >>> native thread > >>> > >>>>>> only have a name if I call cur.setName(cur.getName()) ?" > >>> > >>>>>> > >>> > >>>>>> ** If you follow the bugs and related discussions on > this, the > >>> > >>>>>> semantics and limitations (truncation, current thread only, > >>> non-JNI > >>> > >>>>>> threads only) of setting the native thread name were supposed > >>> to be > >>> > >>>>>> documented in the release notes - but as far as I can see > that > >>> never > >>> > >>>>>> happened. :( > >>> > >>>>>> > >>> > >>>>>> My position on this remains that if it is desirable for > the main > >>> > >>>>>> thread (and DestroyJavaVM thread) to have native names > then the > >>> > >>>>>> launcher needs to be setting them using the available > platform > >>> APIs. > >>> > >>>>>> Unfortunately this is complicated - as evidenced by the VM > >>> code for > >>> > >>>>>> this - due to the need to verify API availability. > >>> > >>>>>> > >>> > >>>>>> Any change in behaviour in relation to Thread.setName would > >>> have to go > >>> > >>>>>> through our CCC process I think. But a change in the launcher > >>> would > >>> > >>>>>> not. > >>> > >>>>>> > >>> > >>>>>> Sorry. > >>> > >>>>>> > >>> > >>>>>> David > >>> > >>>>>> ----- > >>> > >>>>>> > >>> > >>>>>>> --------------- > >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 > >>> 2016 +0200 > >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 > >>> 2016 +0900 > >>> > >>>>>>> @@ -3187,7 +3187,7 @@ > >>> > >>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); > >>> > >>>>>>> // Thread naming only supported for the current thread, > >>> doesn't > >>> > >>>>>>> work > >>> > >>>>>>> for > >>> > >>>>>>> // target threads. > >>> > >>>>>>> - if (Thread::current() == thr && > >>> !thr->has_attached_via_jni()) { > >>> > >>>>>>> + if (Thread::current() == thr) { > >>> > >>>>>>> // we don't set the name of an attached thread to avoid > >>> stepping > >>> > >>>>>>> // on other programs > >>> > >>>>>>> const char *thread_name = > >>> > >>>>>>> > >>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); > >>> > >>>>>>> --------------- > >>> > >>>>>>> > >>> > >>>>>>> > >>> > >>>>>>> Thanks, > >>> > >>>>>>> > >>> > >>>>>>> Yasumasa > >>> > >>>>>>> > >>> > >>>>>>> > >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: > >>> > >>>>>>>> > >>> > >>>>>>>> > >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: > >>> > >>>>>>>>> Roger, > >>> > >>>>>>>>> Thanks for your comment! > >>> > >>>>>>>>> > >>> > >>>>>>>>> David, > >>> > >>>>>>>>> > >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I > don't like > >>> > >>>>>>>>>>>> exposing > >>> > >>>>>>>>>>>> a new JVM function this way. > >>> > >>>>>>>>> > >>> > >>>>>>>>> I tried to call Thread#setName() after initializing VM > (before > >>> > >>>>>>>>> calling > >>> > >>>>>>>>> main method), > >>> > >>>>>>>>> I could set native thread name. > >>> > >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). > So we > >>> can't > >>> > >>>>>>>>> set > >>> > >>>>>>>>> native thread name for DestroyJavaVM. > >>> > >>>>>>>> > >>> > >>>>>>>> Right - I came to the same realization earlier this > morning. > >>> Which, > >>> > >>>>>>>> unfortunately, takes me back to the basic premise here that > >>> we don't > >>> > >>>>>>>> set the name of threads not created by the JVM. The fact > >>> that the > >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached > thread seems > >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only > working by > >>> > >>>>>>>> accident for the initial attach, and can't be used for the > >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently > >>> named at > >>> > >>>>>>>> the native level. > >>> > >>>>>>>> > >>> > >>>>>>>> I'm afraid my view here is that the launcher has to be > >>> treated like > >>> > >>>>>>>> any other process that might host a JVM. If it wants to > name its > >>> > >>>>>>>> native threads then it is free to do so, but I would not be > >>> exporting > >>> > >>>>>>>> a function from the JVM to do that - it would have to > use the OS > >>> > >>>>>>>> specific API's for that on a platform-by-platform basis. > >>> > >>>>>>>> > >>> > >>>>>>>> Sorry. > >>> > >>>>>>>> > >>> > >>>>>>>> David > >>> > >>>>>>>> ----- > >>> > >>>>>>>> > >>> > >>>>>>>> > >>> > >>>>>>>>> > >>> > >>>>>>>>> > >>> > >>>>>>>>> Thanks, > >>> > >>>>>>>>> > >>> > >>>>>>>>> Yasumasa > >>> > >>>>>>>>> > >>> > >>>>>>>>> > >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: > >>> > >>>>>>>>>> Hi, > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> Comments: > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> jvm.h: The function names are too similar but perform > >>> different > >>> > >>>>>>>>>> functions: > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> - The first function applies to the current thread, the > >>> second > >>> > >>>>>>>>>> one a > >>> > >>>>>>>>>> specific java thread. > >>> > >>>>>>>>>> It would seem useful for there to be a comment somewhere > >>> about > >>> > >>>>>>>>>> what > >>> > >>>>>>>>>> the new function does. > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to > (void*) > >>> > >>>>>>>>>> instead of > >>> > >>>>>>>>>> (SetNativeThreadName0_t) > >>> > >>>>>>>>>> as is done on unix and mac. > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: > >>> > >>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs > >>> used at > >>> > >>>>>>>>>> line 730 > >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast > >>> on the > >>> > >>>>>>>>>> same > >>> > >>>>>>>>>> line as dlsym... > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> $.02, Roger > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> > >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: > >>> > >>>>>>>>>>>> That is an interesting question which I haven't had > time to > >>> > >>>>>>>>>>>> check - > >>> > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached > >>> thread > >>> > >>>>>>>>>>>> then > >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion > >>> should > >>> > >>>>>>>>>>>> work > >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our > treatment of > >>> > >>>>>>>>>>>> JNI-attached threads :( ) > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I > confirmed > >>> native > >>> > >>>>>>>>>>> thread name (test) was set. > >>> > >>>>>>>>>>> --------- > >>> > >>>>>>>>>>> public class Sleep{ > >>> > >>>>>>>>>>> public static void main(String[] args) throws > Exception{ > >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); > >>> > >>>>>>>>>>> Thread.sleep(3600000); > >>> > >>>>>>>>>>> } > >>> > >>>>>>>>>>> } > >>> > >>>>>>>>>>> --------- > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I > don't like > >>> > >>>>>>>>>>>> exposing > >>> > >>>>>>>>>>>> a new JVM function this way. > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's comment. > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>> Thanks, > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>> Yasumasa > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>> > >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: > >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: > >>> > >>>>>>>>>>>>> Hi, > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: > >>> > >>>>>>>>>>>>>> Hi, > >>> > >>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: > >>> > >>>>>>>>>>>>>>> Hi David, > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> Thanks for your comment. > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native thread > >>> name, and JLI > >>> > >>>>>>>>>>>>>>> uses it > >>> > >>>>>>>>>>>>>>> in new webrev. > >>> > >>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so > >>> core-libs will > >>> > >>>>>>>>>>>>>> need to > >>> > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - > now cc'd. > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> Thanks! > >>> > >>>>>>>>>>>>> I'm waiting to review :-) > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to > >>> Thread.setName > >>> > >>>>>>>>>>>>>> rather > >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No > hotspot changes > >>> > >>>>>>>>>>>>>> needed in > >>> > >>>>>>>>>>>>>> that case. > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use > Thread#setName() in > >>> > >>>>>>>>>>>>> Thread#init(), > >>> > >>>>>>>>>>>>> but I could not change native thread name. > >>> > >>>>>>>>>>>> > >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, which is > >>> why the > >>> > >>>>>>>>>>>> native > >>> > >>>>>>>>>>>> name is not set. > >>> > >>>>>>>>>>>> > >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. > >>> > >>>>>>>>>>>> > >>> > >>>>>>>>>>>> That is an interesting question which I haven't had > time to > >>> > >>>>>>>>>>>> check - > >>> > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached > >>> thread > >>> > >>>>>>>>>>>> then > >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion > >>> should > >>> > >>>>>>>>>>>> work > >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our > treatment of > >>> > >>>>>>>>>>>> JNI-attached threads :( ) > >>> > >>>>>>>>>>>> > >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I > don't like > >>> > >>>>>>>>>>>> exposing > >>> > >>>>>>>>>>>> a new JVM function this way. > >>> > >>>>>>>>>>>> > >>> > >>>>>>>>>>>> Thanks, > >>> > >>>>>>>>>>>> David > >>> > >>>>>>>>>>>> ----- > >>> > >>>>>>>>>>>> > >>> > >>>>>>>>>>>>> Thus I think that we have to provide a function to set > >>> native > >>> > >>>>>>>>>>>>> thread name. > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> Thanks, > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> Yasumasa > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> [1] > >>> > >>>>>>>>>>>>> > >>> > https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>> Thanks, > >>> > >>>>>>>>>>>>>> David > >>> > >>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> Could you review again? > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> - hotspot: > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> - jdk: > >>> > >>>>>>>>>>>>>>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> Thanks, > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> Yasumasa > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: > >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as well ... > >>> > >>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, > >>> > >>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have > been on > >>> > >>>>>>>>>>>>>>>> vacation). > >>> > >>>>>>>>>>>>>>>> This > >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct > as we > >>> do not > >>> > >>>>>>>>>>>>>>>> set the > >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which > includes the > >>> > >>>>>>>>>>>>>>>> "main" > >>> > >>>>>>>>>>>>>>>> thread. > >>> > >>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>> David > >>> > >>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: > >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, > >>> > >>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) > >>> > >>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>> Yasumasa > >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" > > >>> >>: > >>> > >>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. > >>> > >>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>> /Robbin > >>> > >>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: > >>> > >>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. > >>> > >>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>> /Robbin > >>> > >>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: > >>> > >>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> Hi, > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. > >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> Thanks, > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: > >>> > >>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> Hi, > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga > wrote: > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" > >>> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>>: > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa > Suenaga wrote: > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, > >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>>>: > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 > >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- > a/src/share/vm/runtime/thread.cpp Thu > >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 > >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 > >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ > b/src/share/vm/runtime/thread.cpp Thu > >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 > >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 > >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new > >>> JavaThread(); > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> main_thread->set_thread_state(_thread_in_vm); > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > main_thread->initialize_thread_current(); > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + > >>> main_thread->set_native_thread_name("main"); > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before > >>> set_active_handles > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > main_thread->record_stack_base_and_size(); > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread > >>> name in > >>> > >>>>>>>>>>>>>>>>>>>>>> Thread > >>> > >>>>>>>>>>>>>>>>>>>>>> class. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or > setName(). > >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, > native > >>> > >>>>>>>>>>>>>>>>>>>>>> thread > >>> > >>>>>>>>>>>>>>>>>>>>>> name > >>> > >>>>>>>>>>>>>>>>>>>>>> will be > >>> > >>>>>>>>>>>>>>>>>>>>>> set at > >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already > >>> starte > >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in > >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). > >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting > thrrad name > >>> > >>>>>>>>>>>>>>>>>>>>>> should > >>> > >>>>>>>>>>>>>>>>>>>>>> be the > >>> > >>>>>>>>>>>>>>>>>>>>>> same. > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then > something like > >>> > >>>>>>>>>>>>>>>>>>>>>> this is > >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp > Tue > >>> Mar 29 > >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 > >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 > >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 > >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp > Wed > >>> Mar 30 > >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 > >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 > >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 > >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ > >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread > >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle > >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, > >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* > >>> > >>>>>>>>>>>>>>>>>>>>>> thread, > >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { > >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* > initial_thread_name = > >>> "main"; > >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> true, > >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); > >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = > >>> > >>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); > >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ > >>> > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), > >>> thread); > >>> > >>>>>>>>>>>>>>>>>>>>>> > > java_lang_Thread::set_priority(thread_oop(), > >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); > >>> > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); > >>> > >>>>>>>>>>>>>>>>>>>>>> > - > >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = > >>> > >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", > >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > >>> > >>>>>>>>>>>>>>>>>>>>>> > + > >>> > >>>>>>>>>>>>>>>>>>>>>> > + > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> thread->set_native_thread_name(initial_thread_name); > >>> > >>>>>>>>>>>>>>>>>>>>>> > + > >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> java_lang_String::create_from_str(initial_thread_name, > >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); > >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, > thread_oop, > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself > 'java' and > >>> > >>>>>>>>>>>>>>>>>>>>>> naming > >>> > >>>>>>>>>>>>>>>>>>>>>> this > >>> > >>>>>>>>>>>>>>>>>>>>>> thread > >>> > >>>>>>>>>>>>>>>>>>>>>> just > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process > (and > >>> thus > >>> > >>>>>>>>>>>>>>>>>>>>>> the > >>> > >>>>>>>>>>>>>>>>>>>>>> process) is > >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process > is not > >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. > >>> > >>>>>>>>>>>>>>>>>>>>>> It is > >>> > >>>>>>>>>>>>>>>>>>>>>> waiting > >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with > >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). > >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for > >>> JavaThread. So I > >>> > >>>>>>>>>>>>>>>>>>>>>> think that > >>> > >>>>>>>>>>>>>>>>>>>>>> we do > >>> > >>>>>>>>>>>>>>>>>>>>>> not > >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since > >>> we want > >>> > >>>>>>>>>>>>>>>>>>>>>> java and > >>> > >>>>>>>>>>>>>>>>>>>>>> native > >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name > might > >>> have > >>> > >>>>>>>>>>>>>>>>>>>>>> some > >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 > >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND > >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java > >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main > >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like > 'Java Main > >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. > >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java > >>> launcher - e.g. > >>> > >>>>>>>>>>>>>>>>>>>>>> Apache > >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread > name, > >>> I think > >>> > >>>>>>>>>>>>>>>>>>>>>> that we > >>> > >>>>>>>>>>>>>>>>>>>>>> have to > >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. > >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> No > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa > >>> Suenaga wrote: > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread > >>> name via > >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not > have it. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, > and main > >>> > >>>>>>>>>>>>>>>>>>>>>> thread is > >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread > should have > >>> > >>>>>>>>>>>>>>>>>>>>>> native > >>> > >>>>>>>>>>>>>>>>>>>>>> thread > >>> > >>>>>>>>>>>>>>>>>>>>>> name. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you > review it? > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > > >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> > >>>>>>>>>> > >>> > > >>> > From calvin.cheung at oracle.com Fri Apr 22 06:57:51 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 21 Apr 2016 23:57:51 -0700 Subject: RFR(xs): 8152356: Change to -Xshare:auto for 32-bit platforms Message-ID: <5719CB6F.1080801@oracle.com> Please review this small fix for enabling -Xshare:auto as the default for 32-bit platforms. JBS: https://bugs.openjdk.java.net/browse/JDK-8152356 webrev: http://cr.openjdk.java.net/~ccheung/8152356/webrev.00/ Testing: JPRT jtreg tests under hotspot/test/runtime thanks, Calvin From david.holmes at oracle.com Fri Apr 22 07:45:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Apr 2016 17:45:39 +1000 Subject: RFR(xs): 8152356: Change to -Xshare:auto for 32-bit platforms In-Reply-To: <5719CB6F.1080801@oracle.com> References: <5719CB6F.1080801@oracle.com> Message-ID: <5719D6A3.8070502@oracle.com> Hi Calvin, On 22/04/2016 4:57 PM, Calvin Cheung wrote: > > Please review this small fix for enabling -Xshare:auto as the default > for 32-bit platforms. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8152356 > > webrev: http://cr.openjdk.java.net/~ccheung/8152356/webrev.00/ I find the selection logic for this to be almost unfathomable - and made worse by the conditional compilation! But looking at your changes: -#if defined(COMPILER2) || INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS +#if INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS Ok - 64-bit implies compiler2 as we don't do 64-bit client, so this reduction is fine. -#if defined(COMPILER2) || INCLUDE_JVMCI +#if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI Ok - we're relaxing the constraint so that we skip this code block for 32-bit compiler2. // Shared spaces work fine with other GCs but causes bytecode rewriting // to be disabled, which hurts interpreter performance and decreases - // server performance. When -server is specified, keep the default off - // unless it is asked for. Future work: either add bytecode rewriting - // at link time, or rewrite bytecodes in non-shared methods. + // server performance. After JDK-8074345, bytecode rewriting is enabled for + // non-shared classes. So share spaces should no longer affect the performance of + // benchmarks executed by C2. Enabling the default (-Xshare:auto) on 32-bit platforms when + // -server is specified. When -server is specified on a 64-bit platform, keep the default + // off unless it is asked for. I'm not a fan of history lessons in comments - they tend to only make sense at the time of writing. If the code works fine now then it works fine now, we don't need to document that it didn't used to work fine but bug XXX fixed it. I'd simplify the comment to just state what exactly you are checking for, because to be honest I find this: if (!DumpSharedSpaces && !RequireSharedSpaces && (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { very hard to unwravel. The first part is fine - not dumping. The second part indicates we are either in -Xshare:off or -Xshare:auto. But the third part is quite puzzling - and even when I think I have it figured out I can't reconcile with what I see when I use -XX:+PrintFlagsFinal. So the "what are we doing" is much more important to comment than the history. --- Query: In the tests, should they be @driver rather than @run ? Thanks, David > Testing: > JPRT > jtreg tests under hotspot/test/runtime > > thanks, > Calvin From martin.doerr at sap.com Fri Apr 22 08:55:53 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 22 Apr 2016 08:55:53 +0000 Subject: 8154867: PPC64: Better byte behavior Message-ID: Hi, the PPC64 part of "Better byte behavior" (8148487) was done in jdk8u but is also needed in 9. Here's the port for 9/dev: http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/ Please review. Best regards, Martin From yasuenag at gmail.com Fri Apr 22 12:11:25 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 22 Apr 2016 21:11:25 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <5719C5C8.3020705@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FBA618.2020809@oracle.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> Message-ID: <571A14ED.10901@gmail.com> Hi David, > I don't think we need to report the exception, but can just ignore it. Either way we have to clear the exception before continuing. I've fixed it in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ Thanks, Yasumasa On 2016/04/22 15:33, David Holmes wrote: > On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> I have uploaded webrev.04 as below. >> Could you review again? >> >> > - hotspot: >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ > > Looks fine. > >> > >> > - jdk: >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ > > As per private email (but repeated here on the record) in java.c: > > 715 if ((*env)->ExceptionOccurred(env)) { > 1716 JLI_ReportExceptionDescription(env); > 1717 } > > I don't think we need to report the exception, but can just ignore it. Either way we have to clear the exception before continuing. > > Thanks, > David > >> Thanks, >> >> Yasumasa >> >> 2016/04/19 22:43 "Yasumasa Suenaga" > >: >> > >> > Hi David, >> > >> > Thank you for your comment. >> > I uploaded new webrev. Could you review again? >> > >> > - hotspot: >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >> > >> > - jdk: >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >> > >> > >> >> That aside I'm not sure why you do this so late in the process, I >> would have done it immediately after here: >> > >> > >> > I think that native thread name ("main") should be set just before >> > main method call. >> > However, main thread is already started, so I moved it as you suggested. >> > >> > >> >> One thing I dislike about the current structure is that we have to >> go from char* to java.lang.String to call setNativeName which then calls >> JVM_SetNativeThreadName which converts the j.l.String back to a char* ! >> > >> > >> > SoI proposed to export new JVM function to set native thread name with >> > const char *. >> > >> > >> > Thanks, >> > >> > Yasumasa >> > >> > >> > >> > On 2016/04/19 14:04, David Holmes wrote: >> >> >> >> Hi Yasumasa, >> >> >> >> Thanks for persevering with this to get it into the current form. >> Sorry I haven't been able to do a detailed review until now. >> >> >> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >> >>> >> >>> Hi Gerard, >> >>> >> >>> 2016/04/19 3:14 "Gerard Ziemski" > >> >>> >>: >> >>> > >> >>> > hi Yasumasa, >> >>> > >> >>> > Nice work. I have 2 questions: >> >>> > >> >>> > ======== >> >>> > File: java.c >> >>> > >> >>> > #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >> >>> after every single JNI call? In this example instead of NULL_CHECK, >> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >> >>> >> >>> It is not critical if we encounter error at JNI function call because >> >>> we cannot set native thread name only. >> >>> So I think that we do not need to leave from launcher process. >> >> >> >> >> >> I agree we do not need to abort if an exception occurs (and in fact >> I don't think an exception is even possible from this code), but we >> should ensure any pending exception is cleared before any futher JNI >> calls might be made. Note that NULL_CHECK is already used extensively >> throughout the launcher code - so if this usage is wrong then it is all >> wrong! More on this code below ... >> >> >> >> Other comments: >> >> >> >> hotspot/src/share/vm/prims/jvm.cpp >> >> >> >> Please add a comment to the method now that you removed the internal >> comment: >> >> >> >> // Sets the native thread name for a JavaThread. If specifically >> >> // requested JNI-attached threads can also have their native name set; >> >> // otherwise we do not modify JNI-attached threads as it may interfere >> >> // with the application that created them. >> >> >> >> --- >> >> >> >> jdk/src/java.base/share/classes/java/lang/Thread.java >> >> >> >> Please add the following comments: >> >> >> >> + // Don't modify JNI-attached threads >> >> setNativeName(name, false); >> >> >> >> + // May be called directly via JNI or reflection (when permitted) to >> >> + // allow JNI-attached threads to set their native name >> >> private native void setNativeName(String name, boolean >> allowAttachedThread); >> >> >> >> --- >> >> >> >> jd/src/java.base/share/native/libjli/java.c >> >> >> >> 328 #define LEAVE() \ >> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >> >> >> >> I was going to suggest this be set later, but realized we have to be >> attached to do this and that happens inside DestroyJavaVM. :) >> >> >> >> + /* Set native thread name. */ >> >> + SetNativeThreadName(env, "main"); >> >> >> >> The comment is redundant given the name of the method. That aside >> I'm not sure why you do this so late in the process, I would have done >> it immediately after here: >> >> >> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >> >> 388 exit(1); >> >> 389 } >> >> + SetNativeThreadName(env, "main"); >> >> >> >> >> >> + /** >> >> + * Set native thread name as possible. >> >> + */ >> >> >> >> Other than the as->if change I'm unclear where the "possible" bit >> comes into play - why would it not be possible? >> >> >> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >> >> 1706 NULL_CHECK(currentThreadID = (*env)->GetStaticMethodID(env, >> cls, >> >> 1707 "currentThread", >> "()Ljava/lang/Thread;")); >> >> 1708 NULL_CHECK(currentThread = >> (*env)->CallStaticObjectMethod(env, cls, >> >> 1709 currentThreadID)); >> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, cls, >> >> 1711 "setNativeName", >> "(Ljava/lang/String;Z)V")); >> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >> >> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >> >> 1714 nameString, JNI_TRUE); >> >> >> >> As above NULL_CHECK is fine here, but we should check for and clear >> any pending exception after CallVoidMethod. >> >> >> >> One thing I dislike about the current structure is that we have to >> go from char* to java.lang.String to call setNativeName which then calls >> JVM_SetNativeThreadName which converts the j.l.String back to a char* ! >> Overall I wonder about the affect on startup cost. But if there is an >> issue we can revisit this. >> >> >> >> Thanks, >> >> David >> >> ----- >> >> >> >> >> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set native >> thread >> >>> name if possible.? not "Set native thread name as possible.?? >> >>> >> >>> Sorry for my bad English :-) >> >>> >> >>> Thanks, >> >>> >> >>> Yasumasa >> >>> >> >>> > cheers >> >>> > >> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >> >> >>> >> wrote: >> >>> > > >> >>> > > Hi David, >> >>> > > >> >>> > > I uploaded new webrev: >> >>> > > >> >>> > > - hotspot: >> >>> > > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >> >>> > > >> >>> > > - jdk: >> >>> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >> >>> > > >> >>> > > >> >>> > >> it won't work unless you change the semantics of setName so I'm >> >>> not sure what you were thinking here. To take advantage of an arg >> taking >> >>> JVM_SetNativThreadName you would need to call it directly as no Java >> >>> code will call it . ??? >> >>> > > >> >>> > > I added a flag for setting native thread name to JNI-attached >> thread. >> >>> > > This change can set native thread name if main thread changes to >> >>> JNI-attached thread. >> >>> > > >> >>> > > >> >>> > > Thanks, >> >>> > > >> >>> > > Yasumasa >> >>> > > >> >>> > > >> >>> > > On 2016/04/16 16:11, David Holmes wrote: >> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >> >>> > >>> Hi David, >> >>> > >>> >> >>> > >>>> That change in behaviour may be a problem, it could be >> considered a >> >>> > >>>> regression that setName stops setting the native thread >> main, even >> >>> > >>>> though we never really intended it to work in the first place. >> >>> :( Such >> >>> > >>>> a change needs to go through CCC. >> >>> > >>> >> >>> > >>> I understood. >> >>> > >>> Can I send CCC request? >> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >> >>> > >> >> >>> > >> Sorry you can't file a CCC request, you would need a sponsor for >> >>> that. But at this stage I don't think I agree with the proposed change >> >>> because of the change in behaviour - there's no way to restore the >> >>> "broken" behaviour. >> >>> > >> >> >>> > >>> I want to continue to discuss about it on JDK-8154331 [1]. >> >>> > >> >> >>> > >> Okay we can do that. >> >>> > >> >> >>> > >>> >> >>> > >>>> Further, we expect the launcher to use the supported JNI >> >>> interface (as >> >>> > >>>> other processes would), not the internal JVM interface that >> >>> exists for >> >>> > >>>> the JDK sources to communicate with the JVM. >> >>> > >>> >> >>> > >>> I think that we do not use JVM interface if we add new method in >> >>> > >>> LauncherHelper as below: >> >>> > >>> ---------------- >> >>> > >>> diff -r f02139a1ac84 >> >>> > >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >> >>> > >>> --- >> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >> >>> > >>> +++ >> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >> >>> > >>> @@ -960,4 +960,8 @@ >> >>> > >>> else >> >>> > >>> return md.toNameAndVersion() + " (" + loc + ")"; >> >>> > >>> } >> >>> > >>> + >> >>> > >>> + static void setNativeThreadName(String name) { >> >>> > >>> + Thread.currentThread().setName(name); >> >>> > >>> + } >> >>> > >> >> >>> > >> You could also make that call via JNI directly, so not sure the >> >>> helper adds much here. But it won't work unless you change the >> semantics >> >>> of setName so I'm not sure what you were thinking here. To take >> >>> advantage of an arg taking JVM_SetNativThreadName you would need to >> call >> >>> it directly as no Java code will call it . ??? >> >>> > >> >> >>> > >> David >> >>> > >> ----- >> >>> > >> >> >>> > >>> } >> >>> > >>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 >> 14:19:30 >> >>> > >>> 2016 +0000 >> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 >> 11:25:53 >> >>> > >>> 2016 +0900 >> >>> > >>> @@ -125,6 +125,7 @@ >> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); >> >>> > >>> >> >>> > >>> static void SetPaths(int argc, char **argv); >> >>> > >>> >> >>> > >>> @@ -325,6 +326,7 @@ >> >>> > >>> * mainThread.isAlive() to work as expected. >> >>> > >>> */ >> >>> > >>> #define LEAVE() \ >> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >> >>> > >>> do { \ >> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >> >>> > >>> @@ -488,6 +490,9 @@ >> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >> >>> > >>> >> >>> > >>> + /* Set native thread name. */ >> >>> > >>> + SetNativeThreadName(env, "main"); >> >>> > >>> + >> >>> > >>> /* Invoke main method. */ >> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >> mainArgs); >> >>> > >>> >> >>> > >>> @@ -1686,6 +1691,22 @@ >> >>> > >>> joptString); >> >>> > >>> } >> >>> > >>> >> >>> > >>> +/** >> >>> > >>> + * Set native thread name as possible. >> >>> > >>> + */ >> >>> > >>> +static void >> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >> >>> > >>> +{ >> >>> > >>> + jmethodID setNativeThreadNameID; >> >>> > >>> + jstring nameString; >> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >> >>> > >>> + NULL_CHECK(cls); >> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >> >>> (*env)->GetStaticMethodID(env, cls, >> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >> setNativeThreadNameID, >> >>> > >>> nameString); >> >>> > >>> +} >> >>> > >>> + >> >>> > >>> /* >> >>> > >>> * Prints default usage or the Xusage message, see >> >>> > >>> sun.launcher.LauncherHelper.java >> >>> > >>> */ >> >>> > >>> ---------------- >> >>> > >>> >> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >> >>> > >>> >> >>> > >>>> However this is still a change to the exported JVM >> interface and so >> >>> > >>>> has to be approved. >> >>> > >>> >> >>> > >>> Do you mean that this change needs CCC? >> >>> > >>> >> >>> > >>> >> >>> > >>> Thanks, >> >>> > >>> >> >>> > >>> Yasumasa >> >>> > >>> >> >>> > >>> >> >>> > >>> [1] >> >>> > >>> >> >>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >> >>> > >>>>> Hi David, >> >>> > >>>>> >> >>> > >>>>>> I think it is a bug based on the comment here: >> >>> > >>>>>> >> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >> >>> thread and >> >>> > >>>>>> JNI attached threads >> >>> > >>>>> >> >>> > >>>>> I filed it to JBS as JDK-8154331. >> >>> > >>>>> I will send review request to hotspot-runtime-dev. >> >>> > >>>>> >> >>> > >>>>> >> >>> > >>>>>> Though that will introduce a change in behaviour by itself as >> >>> setName >> >>> > >>>>>> will no longer set the native name for the main thread. >> >>> > >>>>> >> >>> > >>>>> I know. >> >>> > >>>> >> >>> > >>>> That change in behaviour may be a problem, it could be >> considered a >> >>> > >>>> regression that setName stops setting the native thread >> main, even >> >>> > >>>> though we never really intended it to work in the first place. >> >>> :( Such >> >>> > >>>> a change needs to go through CCC. >> >>> > >>>> >> >>> > >>>>> I checked changeset history. >> >>> > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, >> and it is >> >>> > >>>>> backported JDK 8. >> >>> > >>>> >> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >> >>> > >>>> >> >>> > >>>>> However, this function seems to be called from >> >>> Thread#setNativeName() >> >>> > >>>>> only. >> >>> > >>>>> In addition, Thread#setNativeName() is private method. >> >>> > >>>>> >> >>> > >>>>> Thus I think that we can add an argument to >> >>> JVM_SetNativeThreadName() >> >>> > >>>>> for force setting. >> >>> > >>>>> (e.g. "bool forced") >> >>> > >>>>> >> >>> > >>>>> It makes a change of JVM API. >> >>> > >>>>> However, this function is NOT public, so I think we can >> add one >> >>> more >> >>> > >>>>> argument. >> >>> > >>>>> >> >>> > >>>>> What do you think about this? >> >>> > >>>>> If it is accepted, we can set native thread name from Java >> >>> launcher. >> >>> > >>>> >> >>> > >>>> The private/public aspect of the Java API is not really at >> >>> issue. Yes >> >>> > >>>> we would add another arg to the JVM function to allow it to >> apply to >> >>> > >>>> JNI-attached threads as well (I'd prefer the arg reflect that >> >>> not just >> >>> > >>>> "force"). However this is still a change to the exported JVM >> >>> interface >> >>> > >>>> and so has to be approved. Further, we expect the launcher to >> >>> use the >> >>> > >>>> supported JNI interface (as other processes would), not the >> internal >> >>> > >>>> JVM interface that exists for the JDK sources to communicate >> >>> with the >> >>> > >>>> JVM. >> >>> > >>>> >> >>> > >>>> David >> >>> > >>>> ----- >> >>> > >>>> >> >>> > >>>>> >> >>> > >>>>> Thanks, >> >>> > >>>>> >> >>> > >>>>> Yasumasa >> >>> > >>>>> >> >>> > >>>>> >> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >> >>> > >>>>>> Hi Yasumasa, >> >>> > >>>>>> >> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >> >>> > >>>>>>> Hi David, >> >>> > >>>>>>> >> >>> > >>>>>>>> The fact that the "main" thread is not tagged as being a >> >>> JNI-attached >> >>> > >>>>>>>> thread seems accidental to me >> >>> > >>>>>>> >> >>> > >>>>>>> Should I file it to JBS? >> >>> > >>>>>> >> >>> > >>>>>> I think it is a bug based on the comment here: >> >>> > >>>>>> >> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >> >>> thread and >> >>> > >>>>>> JNI attached threads >> >>> > >>>>>> >> >>> > >>>>>> Though that will introduce a change in behaviour by itself as >> >>> setName >> >>> > >>>>>> will no longer set the native name for the main thread. >> >>> > >>>>>> >> >>> > >>>>>>> I think that we can fix as below: >> >>> > >>>>>>> --------------- >> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 >> >>> 2016 +0200 >> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 >> >>> 2016 +0900 >> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >> >>> > >>>>>>> #endif // INCLUDE_JVMCI >> >>> > >>>>>>> >> >>> > >>>>>>> // Attach the main thread to this os thread >> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >> >>> > >>>>>>> main_thread->initialize_thread_current(); >> >>> > >>>>>>> // must do this before set_active_handles >> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >> >>> > >>>>>>> // Notify JVMTI agents that VM initialization is complete >> >>> - nop if >> >>> > >>>>>>> no agents. >> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >> >>> > >>>>>>> >> >>> > >>>>>>> + // Change attach status to "attached" >> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >> >>> > >>>>>>> + >> >>> > >>>>>> >> >>> > >>>>>> I think we can do this straight after the JavaThread >> constructor. >> >>> > >>>>>> >> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >> >>> > >>>>>>> vm_exit_during_initialization("Failed to start tracing >> >>> > >>>>>>> backend."); >> >>> > >>>>>>> } >> >>> > >>>>>>> --------------- >> >>> > >>>>>>> >> >>> > >>>>>>> >> >>> > >>>>>>>> If it wants to name its native threads then it is free >> to do so, >> >>> > >>>>>>> >> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change native >> >>> thread name >> >>> > >>>>>>> when the caller thread is JNI-attached thread. >> >>> > >>>>>>> However, I think that it should be changed if Java developer >> >>> calls >> >>> > >>>>>>> Thread#setName() explicitly. >> >>> > >>>>>>> It is not the same of changing native thread name at >> >>> > >>>>>>> Threads::create_vm(). >> >>> > >>>>>>> >> >>> > >>>>>>> If it is allowed, I want to fix SetNativeThreadName() as >> below. >> >>> > >>>>>>> What do you think about this? >> >>> > >>>>>> >> >>> > >>>>>> The decision to not change the name of JNI-attached >> threads was a >> >>> > >>>>>> deliberate one** - this functionality originated with the OSX >> >>> port and >> >>> > >>>>>> it was reported that the initial feedback with this >> feature was to >> >>> > >>>>>> ensure it didn't mess with thread names that had been set by >> >>> the host >> >>> > >>>>>> process. If we do as you propose then we will just have an >> >>> > >>>>>> inconsistency for people to complain about: "why does my >> >>> native thread >> >>> > >>>>>> only have a name if I call cur.setName(cur.getName()) ?" >> >>> > >>>>>> >> >>> > >>>>>> ** If you follow the bugs and related discussions on >> this, the >> >>> > >>>>>> semantics and limitations (truncation, current thread only, >> >>> non-JNI >> >>> > >>>>>> threads only) of setting the native thread name were supposed >> >>> to be >> >>> > >>>>>> documented in the release notes - but as far as I can see >> that >> >>> never >> >>> > >>>>>> happened. :( >> >>> > >>>>>> >> >>> > >>>>>> My position on this remains that if it is desirable for >> the main >> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native names >> then the >> >>> > >>>>>> launcher needs to be setting them using the available >> platform >> >>> APIs. >> >>> > >>>>>> Unfortunately this is complicated - as evidenced by the VM >> >>> code for >> >>> > >>>>>> this - due to the need to verify API availability. >> >>> > >>>>>> >> >>> > >>>>>> Any change in behaviour in relation to Thread.setName would >> >>> have to go >> >>> > >>>>>> through our CCC process I think. But a change in the launcher >> >>> would >> >>> > >>>>>> not. >> >>> > >>>>>> >> >>> > >>>>>> Sorry. >> >>> > >>>>>> >> >>> > >>>>>> David >> >>> > >>>>>> ----- >> >>> > >>>>>> >> >>> > >>>>>>> --------------- >> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 >> >>> 2016 +0200 >> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 >> >>> 2016 +0900 >> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >> >>> > >>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >> >>> > >>>>>>> // Thread naming only supported for the current thread, >> >>> doesn't >> >>> > >>>>>>> work >> >>> > >>>>>>> for >> >>> > >>>>>>> // target threads. >> >>> > >>>>>>> - if (Thread::current() == thr && >> >>> !thr->has_attached_via_jni()) { >> >>> > >>>>>>> + if (Thread::current() == thr) { >> >>> > >>>>>>> // we don't set the name of an attached thread to avoid >> >>> stepping >> >>> > >>>>>>> // on other programs >> >>> > >>>>>>> const char *thread_name = >> >>> > >>>>>>> >> >>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >> >>> > >>>>>>> --------------- >> >>> > >>>>>>> >> >>> > >>>>>>> >> >>> > >>>>>>> Thanks, >> >>> > >>>>>>> >> >>> > >>>>>>> Yasumasa >> >>> > >>>>>>> >> >>> > >>>>>>> >> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >> >>> > >>>>>>>> >> >>> > >>>>>>>> >> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >> >>> > >>>>>>>>> Roger, >> >>> > >>>>>>>>> Thanks for your comment! >> >>> > >>>>>>>>> >> >>> > >>>>>>>>> David, >> >>> > >>>>>>>>> >> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >> don't like >> >>> > >>>>>>>>>>>> exposing >> >>> > >>>>>>>>>>>> a new JVM function this way. >> >>> > >>>>>>>>> >> >>> > >>>>>>>>> I tried to call Thread#setName() after initializing VM >> (before >> >>> > >>>>>>>>> calling >> >>> > >>>>>>>>> main method), >> >>> > >>>>>>>>> I could set native thread name. >> >>> > >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). >> So we >> >>> can't >> >>> > >>>>>>>>> set >> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >> >>> > >>>>>>>> >> >>> > >>>>>>>> Right - I came to the same realization earlier this >> morning. >> >>> Which, >> >>> > >>>>>>>> unfortunately, takes me back to the basic premise here that >> >>> we don't >> >>> > >>>>>>>> set the name of threads not created by the JVM. The fact >> >>> that the >> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >> thread seems >> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only >> working by >> >>> > >>>>>>>> accident for the initial attach, and can't be used for the >> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >> >>> named at >> >>> > >>>>>>>> the native level. >> >>> > >>>>>>>> >> >>> > >>>>>>>> I'm afraid my view here is that the launcher has to be >> >>> treated like >> >>> > >>>>>>>> any other process that might host a JVM. If it wants to >> name its >> >>> > >>>>>>>> native threads then it is free to do so, but I would not be >> >>> exporting >> >>> > >>>>>>>> a function from the JVM to do that - it would have to >> use the OS >> >>> > >>>>>>>> specific API's for that on a platform-by-platform basis. >> >>> > >>>>>>>> >> >>> > >>>>>>>> Sorry. >> >>> > >>>>>>>> >> >>> > >>>>>>>> David >> >>> > >>>>>>>> ----- >> >>> > >>>>>>>> >> >>> > >>>>>>>> >> >>> > >>>>>>>>> >> >>> > >>>>>>>>> >> >>> > >>>>>>>>> Thanks, >> >>> > >>>>>>>>> >> >>> > >>>>>>>>> Yasumasa >> >>> > >>>>>>>>> >> >>> > >>>>>>>>> >> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >> >>> > >>>>>>>>>> Hi, >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> Comments: >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> jvm.h: The function names are too similar but perform >> >>> different >> >>> > >>>>>>>>>> functions: >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> - The first function applies to the current thread, the >> >>> second >> >>> > >>>>>>>>>> one a >> >>> > >>>>>>>>>> specific java thread. >> >>> > >>>>>>>>>> It would seem useful for there to be a comment somewhere >> >>> about >> >>> > >>>>>>>>>> what >> >>> > >>>>>>>>>> the new function does. >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to >> (void*) >> >>> > >>>>>>>>>> instead of >> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >> >>> > >>>>>>>>>> as is done on unix and mac. >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >> >>> > >>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs >> >>> used at >> >>> > >>>>>>>>>> line 730 >> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast >> >>> on the >> >>> > >>>>>>>>>> same >> >>> > >>>>>>>>>> line as dlsym... >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> $.02, Roger >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> >> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >> >>> > >>>>>>>>>>>> That is an interesting question which I haven't had >> time to >> >>> > >>>>>>>>>>>> check - >> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >> >>> thread >> >>> > >>>>>>>>>>>> then >> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >> >>> should >> >>> > >>>>>>>>>>>> work >> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >> treatment of >> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >> confirmed >> >>> native >> >>> > >>>>>>>>>>> thread name (test) was set. >> >>> > >>>>>>>>>>> --------- >> >>> > >>>>>>>>>>> public class Sleep{ >> >>> > >>>>>>>>>>> public static void main(String[] args) throws >> Exception{ >> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >> >>> > >>>>>>>>>>> Thread.sleep(3600000); >> >>> > >>>>>>>>>>> } >> >>> > >>>>>>>>>>> } >> >>> > >>>>>>>>>>> --------- >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >> don't like >> >>> > >>>>>>>>>>>> exposing >> >>> > >>>>>>>>>>>> a new JVM function this way. >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's comment. >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>> Thanks, >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>> Yasumasa >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>> >> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >> >>> > >>>>>>>>>>>>> Hi, >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >> >>> > >>>>>>>>>>>>>> Hi, >> >>> > >>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >> >>> > >>>>>>>>>>>>>>> Hi David, >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native thread >> >>> name, and JLI >> >>> > >>>>>>>>>>>>>>> uses it >> >>> > >>>>>>>>>>>>>>> in new webrev. >> >>> > >>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >> >>> core-libs will >> >>> > >>>>>>>>>>>>>> need to >> >>> > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - >> now cc'd. >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> Thanks! >> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >> >>> Thread.setName >> >>> > >>>>>>>>>>>>>> rather >> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >> hotspot changes >> >>> > >>>>>>>>>>>>>> needed in >> >>> > >>>>>>>>>>>>>> that case. >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >> Thread#setName() in >> >>> > >>>>>>>>>>>>> Thread#init(), >> >>> > >>>>>>>>>>>>> but I could not change native thread name. >> >>> > >>>>>>>>>>>> >> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, which is >> >>> why the >> >>> > >>>>>>>>>>>> native >> >>> > >>>>>>>>>>>> name is not set. >> >>> > >>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >> >>> > >>>>>>>>>>>> >> >>> > >>>>>>>>>>>> That is an interesting question which I haven't had >> time to >> >>> > >>>>>>>>>>>> check - >> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >> >>> thread >> >>> > >>>>>>>>>>>> then >> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >> >>> should >> >>> > >>>>>>>>>>>> work >> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >> treatment of >> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >> >>> > >>>>>>>>>>>> >> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >> don't like >> >>> > >>>>>>>>>>>> exposing >> >>> > >>>>>>>>>>>> a new JVM function this way. >> >>> > >>>>>>>>>>>> >> >>> > >>>>>>>>>>>> Thanks, >> >>> > >>>>>>>>>>>> David >> >>> > >>>>>>>>>>>> ----- >> >>> > >>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a function to set >> >>> native >> >>> > >>>>>>>>>>>>> thread name. >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> Thanks, >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> Yasumasa >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> [1] >> >>> > >>>>>>>>>>>>> >> >>> >> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>> Thanks, >> >>> > >>>>>>>>>>>>>> David >> >>> > >>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> Could you review again? >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> - hotspot: >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> - jdk: >> >>> > >>>>>>>>>>>>>>> >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> Thanks, >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> Yasumasa >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >> >>> > >>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >> >>> > >>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have >> been on >> >>> > >>>>>>>>>>>>>>>> vacation). >> >>> > >>>>>>>>>>>>>>>> This >> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct >> as we >> >>> do not >> >>> > >>>>>>>>>>>>>>>> set the >> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >> includes the >> >>> > >>>>>>>>>>>>>>>> "main" >> >>> > >>>>>>>>>>>>>>>> thread. >> >>> > >>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>> David >> >>> > >>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >> >>> > >>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >> >>> > >>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>> Yasumasa >> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >> >> >>> >>: >> >>> > >>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >> >>> > >>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>> /Robbin >> >>> > >>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >> >>> > >>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >> >>> > >>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >> >>> > >>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >> >>> > >>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >> >>> > >>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga >> wrote: >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >> >>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> >>>: >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >> Suenaga wrote: >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> >>>>: >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >> a/src/share/vm/runtime/thread.cpp Thu >> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >> b/src/share/vm/runtime/thread.cpp Thu >> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >> >>> JavaThread(); >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> main_thread->set_thread_state(_thread_in_vm); >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> main_thread->initialize_thread_current(); >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >> >>> main_thread->set_native_thread_name("main"); >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >> >>> set_active_handles >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> main_thread->record_stack_base_and_size(); >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread >> >>> name in >> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >> setName(). >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, >> native >> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >> >>> > >>>>>>>>>>>>>>>>>>>>>> name >> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already >> >>> starte >> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >> thrrad name >> >>> > >>>>>>>>>>>>>>>>>>>>>> should >> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >> something like >> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp >> Tue >> >>> Mar 29 >> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp >> Wed >> >>> Mar 30 >> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >> initial_thread_name = >> >>> "main"; >> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >> >>> > >>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >> >>> > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >> >>> thread); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> java_lang_Thread::set_priority(thread_oop(), >> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >> >>> > >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> thread->set_native_thread_name(initial_thread_name); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> java_lang_String::create_from_str(initial_thread_name, >> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >> thread_oop, >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself >> 'java' and >> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >> >>> > >>>>>>>>>>>>>>>>>>>>>> this >> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >> >>> > >>>>>>>>>>>>>>>>>>>>>> just >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process >> (and >> >>> thus >> >>> > >>>>>>>>>>>>>>>>>>>>>> the >> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process >> is not >> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >> >>> JavaThread. So I >> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >> >>> > >>>>>>>>>>>>>>>>>>>>>> not >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since >> >>> we want >> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >> >>> > >>>>>>>>>>>>>>>>>>>>>> native >> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name >> might >> >>> have >> >>> > >>>>>>>>>>>>>>>>>>>>>> some >> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like >> 'Java Main >> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java >> >>> launcher - e.g. >> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread >> name, >> >>> I think >> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> No >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa >> >>> Suenaga wrote: >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread >> >>> name via >> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >> have it. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, >> and main >> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >> should have >> >>> > >>>>>>>>>>>>>>>>>>>>>> native >> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you >> review it? >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> > >>>>>>>>>> >> >>> > >> >>> >> From HORII at jp.ibm.com Fri Apr 22 12:28:13 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Fri, 22 Apr 2016 21:28:13 +0900 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 Message-ID: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> Dear all: Can I please request reviews for the following change? Code change: http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ (I initially created and Martin enhanced so much) This change follows the discussion started from this mail. http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/018960.html Description: This change provides relaxed compare-and-exchange by introducing similar semantics of C++ atomic memory operators, enum memory_order. As described in atomic_linux_ppc.inline.hpp, the current implementation of cmpxchg is fence_cmpxchg_acquire. This implementation is useful for general purposes because twice calls of sync before and after cmpxchg will provide strict consistency. However, they sometimes cause overheads because sync instructions are very expensive in the current POWER chip design. In addition, for the other platforms, such as aarch64, this strict semantics may cause some overheads (according to the Andrew's mail). http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019073.html With this change, callers can explicitly specify constraints of memory ordering for cmpxchg with an additional parameter, memory_order order. typedef enum memory_order { memory_order_relaxed, memory_order_consume, memory_order_acquire, memory_order_release, memory_order_acq_rel, memory_order_seq_cst } memory_order; Because the default value of the parameter is memory_order_seq_cst, existing codes can use the same semantics of cmpxchg without any modification. The relaxed cmpxchg is implemented only on ppc in this changeset. Therefore, the behavior on the other platforms will not be changed with this changeset. In addition, with the new parameter of cmpxchg, this change improves performance of copy_to_survivor in the parallel GC. copy_to_survivor changes forward pointers by using cmpxchg. This operation doesn't require any sync instructions. A pointer is changed at most once in a GC and when cmpxchg fails, the latest pointer is available for the caller. cas_set_mark and cas_forward_to are extended with an additional memory_order parameter as cmpxchg and copy_to_survivor uses memory_order_relaxed to modify the forward pointers. Summary of source code changes: * src/share/vm/runtime/atomic.hpp - Defines enum memory_order and adds a parameter to cmpxchg. * src/share/vm/runtime/atomic.cpp * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp - Added a parameter for each cmpxchg function to follow the change of atomic.hpp. Their implementations are not changed. * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp - Added a parameter for each cmpxchg function to follow the change of atomic.hpp. In addition, implementations are changed corresponding to the specified memory_order. * src/share/vm/oops/oop.hpp * src/share/vm/oops/oop.inline.hpp - Add a memory_order parameter to use relaxed cmpxchg in cas_set_mark and cas_forward_to. * src/share/vm/gc/parallel/psPromotionManager.cpp * src/share/vm/gc/parallel/psPromotionManager.inline.hpp Martin tested this changeset on linuxx86_64, linuxppc64le and darwinintel64. Though more time is needed to test on the other platform, we would like to ask reviews and start discussion on this changeset. I also tested this changeset with SPECjbb2013 and confirmed that gc pause time is reduced. Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo From lois.foltan at oracle.com Fri Apr 22 12:45:09 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 22 Apr 2016 08:45:09 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571933EF.6040304@oracle.com> References: <571933EF.6040304@oracle.com> Message-ID: <571A1CD5.7040602@oracle.com> On 4/21/2016 4:11 PM, Rachel Protacio wrote: > Hello, > > Please review this fix for the package() and module() functions, > making them pure virtual functions of Klass and implementing them in > the relevant child classes. This cleans up some verbose and repetitive > code that was casting and checking klass types. Also added test cases > to runtime/modules/getModuleJNI/GetModule.java, ensuring that all the > module() functions work as expected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 > Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ Hi Rachel, This looks really good! A couple of comments: - src/share/vm/oops/arrayKlass.hpp line #140 & 141 - instead of inserting the declarations of the module and package methods at the end of the ArrayKlass data structure can you move them up to line #71 or right after the declaration of java_super() at line #73. This is picky, but for readability seems to fit more with other like methods. - src/share/vm/oops/klass.hpp It seems like the precedence is to have forward declarations for classes that the Klass data structures uses. Can you change that for PackageEntry and ModuleEntry instead of including the headers? - src/share/vm/oops/objArrayKlass.cpp line #420 - Remove //Packages comment - really adds no value line #421 - Remove blank line #line #423 - A comment that would be helpful and please include, "The array is defined in the module of its bottom class" // The array is defined in the module of its bottom class - src/share/vm/oops/typeArrayKlass.cpp line #348 - A comment is needed, something like, "A TypeArrayKlass is an array of a primitive type, its defining module is java.base" - src/share/vm/runtime/reflection.cpp line #511 & #512 - I think we need to change that comment because I am not sure if it is accurate to state that java.base exports its packages to all modules. Please change to something like, "A TypeArray's defining module is java.base, access to the TypeArray is allowed" - test/runtime/modules/getModuleJNI/GetModule.java Thank you for improving this test! I don't need to see another webrev for this, Thanks, Lois > > Tested with jtreg tests in jdk/test (java/lang, java/io, > java/security, java/util, tools/jimage, tools/jlink, and tools/jmod), > JPRT, and RBT hotspot and non-colo tests. > > Thanks! > Rachel From david.holmes at oracle.com Fri Apr 22 12:57:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Apr 2016 22:57:07 +1000 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> Message-ID: <571A1FA3.9030006@oracle.com> Hi Hiroshi, Two initial questions: 1. Are the current cmpxchg semantics exactly the same as memory_order_seq_cst? 2. Has there been a discussion already, establishing that the modified GC code can indeed use memory_order_relaxed? Otherwise who is postulating that and based on what evidence? Missing memory barriers have caused very difficult to track down bugs in the past - very rare race conditions. So any relaxation here has to be done with extreme confidence. Thanks, David On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: > Dear all: > > Can I please request reviews for the following change? > > Code change: > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ > (I initially created and Martin enhanced so much) > > This change follows the discussion started from this mail. > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/018960.html > > Description: > This change provides relaxed compare-and-exchange by introducing > similar semantics of C++ atomic memory operators, enum memory_order. > As described in atomic_linux_ppc.inline.hpp, the current implementation of > cmpxchg is fence_cmpxchg_acquire. This implementation is useful for > general purposes because twice calls of sync before and after cmpxchg will > provide strict consistency. However, they sometimes cause overheads > because > sync instructions are very expensive in the current POWER chip design. > In addition, for the other platforms, such as aarch64, this strict > semantics > may cause some overheads (according to the Andrew's mail). > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019073.html > > With this change, callers can explicitly specify constraints of memory > ordering > for cmpxchg with an additional parameter, memory_order order. > > typedef enum memory_order { > memory_order_relaxed, > memory_order_consume, > memory_order_acquire, > memory_order_release, > memory_order_acq_rel, > memory_order_seq_cst > } memory_order; > > Because the default value of the parameter is memory_order_seq_cst, > existing codes can use the same semantics of cmpxchg without any > modification. The relaxed cmpxchg is implemented only on ppc > in this changeset. Therefore, the behavior on the other platforms will > not be changed with this changeset. > > In addition, with the new parameter of cmpxchg, this change improves > performance of copy_to_survivor in the parallel GC. > copy_to_survivor changes forward pointers by using cmpxchg. This > operation doesn't require any sync instructions. A pointer is changed > at most once in a GC and when cmpxchg fails, the latest pointer is > available for the caller. cas_set_mark and cas_forward_to are extended > with an additional memory_order parameter as cmpxchg and copy_to_survivor > uses memory_order_relaxed to modify the forward pointers. > > Summary of source code changes: > > * src/share/vm/runtime/atomic.hpp > - Defines enum memory_order and adds a parameter to cmpxchg. > > * src/share/vm/runtime/atomic.cpp > * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > - Added a parameter for each cmpxchg function to follow > the change of atomic.hpp. Their implementations are not changed. > > * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > - Added a parameter for each cmpxchg function to follow > the change of atomic.hpp. In addition, implementations > are changed corresponding to the specified memory_order. > > * src/share/vm/oops/oop.hpp > * src/share/vm/oops/oop.inline.hpp > - Add a memory_order parameter to use relaxed cmpxchg in > cas_set_mark and cas_forward_to. > > * src/share/vm/gc/parallel/psPromotionManager.cpp > * src/share/vm/gc/parallel/psPromotionManager.inline.hpp > > Martin tested this changeset on linuxx86_64, linuxppc64le and > darwinintel64. > Though more time is needed to test on the other platform, we would like to > ask > reviews and start discussion on this changeset. > I also tested this changeset with SPECjbb2013 and confirmed that gc pause > time > is reduced. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > From goetz.lindenmaier at sap.com Fri Apr 22 13:08:13 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Apr 2016 13:08:13 +0000 Subject: 8154867: PPC64: Better byte behavior In-Reply-To: References: Message-ID: Hi Martin, thanks for doing this port. Looks good. I also checked it on aix. As it is ppc only, you can push it to jdk9/dev/hotspot. Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Freitag, 22. April 2016 10:56 > To: hotspot-runtime-dev at openjdk.java.net > Subject: 8154867: PPC64: Better byte behavior > > Hi, > > the PPC64 part of "Better byte behavior" (8148487) was done in jdk8u but is > also needed in 9. > > Here's the port for 9/dev: > http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior > /webrev.00/ > > Please review. > > Best regards, > Martin From coleen.phillimore at oracle.com Fri Apr 22 13:11:53 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Apr 2016 09:11:53 -0400 Subject: 8154867: PPC64: Better byte behavior In-Reply-To: References: Message-ID: <571A2319.5040602@oracle.com> Hi Martin, http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/src/cpu/ppc/vm/templateTable_ppc_64.cpp.udiff.html This change looks good except the code in ireturn looks strange because state is never btos/ztos/stos/ctos. OR if it was btos,stos and ctos and you're trying to return a boolean, there would have to be additional narrowing for those cases too. It think it would be more accurate to have the small int tos states above itos in your switch statement. The only reason we added ztos was to make the backports easier for these bugs. I think these unused tos optimization cases should be removed. Do you agree? https://bugs.openjdk.java.net/browse/JDK-8139788 Also, I guess it doesn't matter for ppc, but the April cpu code is in http://hg.openjdk.java.net/jdk9/hs and I was going to push the zero change from Severin there. Should you make these changes for that repository instead? thanks, Coleen On 4/22/16 4:55 AM, Doerr, Martin wrote: > Hi, > > the PPC64 part of "Better byte behavior" (8148487) was done in jdk8u but is also needed in 9. > > Here's the port for 9/dev: > http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/ > > Please review. > > Best regards, > Martin > From james.laskey at oracle.com Fri Apr 22 13:12:24 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 22 Apr 2016 10:12:24 -0300 Subject: RFR: JDK-8147634 - Need a JImage API that given a JImageLocationRef returns class name Message-ID: <03EC625A-A5B8-4934-B1E9-591D694631F9@oracle.com> Implemented as requested by the runtime team. http://cr.openjdk.java.net/~jlaskey/8147634/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8147634 From james.laskey at oracle.com Fri Apr 22 13:12:26 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 22 Apr 2016 10:12:26 -0300 Subject: RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND Message-ID: <1A36919B-354F-43DA-9130-4156AADD001A@oracle.com> JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the jdk jimage.hpp header. Brought the headers in line. http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8147426 From martin.doerr at sap.com Fri Apr 22 13:15:57 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 22 Apr 2016 13:15:57 +0000 Subject: 8154867: PPC64: Better byte behavior In-Reply-To: References: Message-ID: <0b5693a7c5e647c3840ee965412d7b51@DEWDFE13DE14.global.corp.sap> Hi G?tz, thanks for the review and for checking it on AIX. I have pushed it. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 22. April 2016 15:08 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Subject: RE: 8154867: PPC64: Better byte behavior Hi Martin, thanks for doing this port. Looks good. I also checked it on aix. As it is ppc only, you can push it to jdk9/dev/hotspot. Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Freitag, 22. April 2016 10:56 > To: hotspot-runtime-dev at openjdk.java.net > Subject: 8154867: PPC64: Better byte behavior > > Hi, > > the PPC64 part of "Better byte behavior" (8148487) was done in jdk8u but is > also needed in 9. > > Here's the port for 9/dev: > http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior > /webrev.00/ > > Please review. > > Best regards, > Martin From goetz.lindenmaier at sap.com Fri Apr 22 13:17:35 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Apr 2016 13:17:35 +0000 Subject: RFR(S): 8154921: Fix aix after "8146879: Add option for handling existing log files in UL" Message-ID: <2e0e2e288163415fb4e1ddcb764c1434@DEWDFE13DE09.global.corp.sap> Hi 8146879 breaks the build on AIX, as stdio.h defines a macro fileno. I renamed os::fileno() to os::get_fileno(). Please review this small fix. I please need a sponsor. http://cr.openjdk.java.net/~goetz/wr16/8154921-aix_fileno/webrev.01/ Best regards, Goetz. From harold.seigel at oracle.com Fri Apr 22 13:21:05 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 22 Apr 2016 09:21:05 -0400 Subject: RFR: JDK-8147634 - Need a JImage API that given a JImageLocationRef returns class name In-Reply-To: <03EC625A-A5B8-4934-B1E9-591D694631F9@oracle.com> References: <03EC625A-A5B8-4934-B1E9-591D694631F9@oracle.com> Message-ID: <571A2541.50909@oracle.com> Hi Jim, Can you change JIMAGE_ResourcePath() to return a bad status if it is called with bogus input, such as a bad value for the JImageLocationRef? Thanks, Harold On 4/22/2016 9:12 AM, Jim Laskey (Oracle) wrote: > Implemented as requested by the runtime team. > > http://cr.openjdk.java.net/~jlaskey/8147634/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8147634 > From coleen.phillimore at oracle.com Fri Apr 22 13:24:15 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Apr 2016 09:24:15 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <57198BE9.5080107@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> Message-ID: <571A25FF.1080700@oracle.com> Hi, http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html I don't think you need module or package declared in arrayKlass.hpp since it should be abstract also, ie. there should be no instances of ArrayKlass. Otherwise, looks great. I love seeing those InstanceKlass::casts go away. Coleen On 4/21/16 10:26 PM, David Holmes wrote: > Hi Rachel, > > On 22/04/2016 6:11 AM, Rachel Protacio wrote: >> Hello, >> >> Please review this fix for the package() and module() functions, making >> them pure virtual functions of Klass and implementing them in the >> relevant child classes. This cleans up some verbose and repetitive code >> that was casting and checking klass types. Also added test cases to >> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >> module() functions work as expected. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ > > The refactoring all looks good to me (though C++ annoys me in needing > to re-declare the functions in each subclass :) ). > > Cheers, > David > >> Tested with jtreg tests in jdk/test (java/lang, java/io, java/security, >> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >> hotspot and non-colo tests. >> >> Thanks! >> Rachel From coleen.phillimore at oracle.com Fri Apr 22 13:25:44 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Apr 2016 09:25:44 -0400 Subject: RFR(S): 8154921: Fix aix after "8146879: Add option for handling existing log files in UL" In-Reply-To: <2e0e2e288163415fb4e1ddcb764c1434@DEWDFE13DE09.global.corp.sap> References: <2e0e2e288163415fb4e1ddcb764c1434@DEWDFE13DE09.global.corp.sap> Message-ID: <571A2658.3030202@oracle.com> Looks good. I'll sponsor. I think it only needs one code review under the "trivial" rule. Coleen On 4/22/16 9:17 AM, Lindenmaier, Goetz wrote: > Hi > > 8146879 breaks the build on AIX, as stdio.h defines a macro fileno. > I renamed os::fileno() to os::get_fileno(). > > Please review this small fix. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr16/8154921-aix_fileno/webrev.01/ > > Best regards, > Goetz. From james.laskey at oracle.com Fri Apr 22 13:38:12 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 22 Apr 2016 10:38:12 -0300 Subject: RFR: JDK-8147634 - Need a JImage API that given a JImageLocationRef returns class name In-Reply-To: <571A2541.50909@oracle.com> References: <03EC625A-A5B8-4934-B1E9-591D694631F9@oracle.com> <571A2541.50909@oracle.com> Message-ID: <01E34F2B-CAAD-4CDC-893B-2C3CA70B1D97@oracle.com> Not reliably. I can do a range check but I can?t test that the offset is correct (preceeding zero byte isn?t sufficient.) The alternative is to switch to using indices instead of offsets for JImageLocationRef (as I mentioned should have ben done.) Take a bit of fiddling at this point, but doable. One would assume that you would guarantee on the result (shut down the vm), since that would mean a fail of the verification data (same as if jimage were invalid.) ? Jim > On Apr 22, 2016, at 10:21 AM, harold seigel wrote: > > Hi Jim, > > Can you change JIMAGE_ResourcePath() to return a bad status if it is called with bogus input, such as a bad value for the JImageLocationRef? > > Thanks, Harold > > On 4/22/2016 9:12 AM, Jim Laskey (Oracle) wrote: >> Implemented as requested by the runtime team. >> >> http://cr.openjdk.java.net/~jlaskey/8147634/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8147634 >> > From harold.seigel at oracle.com Fri Apr 22 13:54:16 2016 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 22 Apr 2016 09:54:16 -0400 Subject: RFR: JDK-8147634 - Need a JImage API that given a JImageLocationRef returns class name In-Reply-To: <01E34F2B-CAAD-4CDC-893B-2C3CA70B1D97@oracle.com> References: <03EC625A-A5B8-4934-B1E9-591D694631F9@oracle.com> <571A2541.50909@oracle.com> <01E34F2B-CAAD-4CDC-893B-2C3CA70B1D97@oracle.com> Message-ID: <571A2D08.9020100@oracle.com> Having a range check would be good at least until the switch to using indices. Thanks, Harold On 4/22/2016 9:38 AM, Jim Laskey (Oracle) wrote: > Not reliably. I can do a range check but I can?t test that the offset is correct (preceeding zero byte isn?t sufficient.) The alternative is to switch to using indices instead of offsets for JImageLocationRef (as I mentioned should have ben done.) Take a bit of fiddling at this point, but doable. One would assume that you would guarantee on the result (shut down the vm), since that would mean a fail of the verification data (same as if jimage were invalid.) > > ? Jim > > >> On Apr 22, 2016, at 10:21 AM, harold seigel wrote: >> >> Hi Jim, >> >> Can you change JIMAGE_ResourcePath() to return a bad status if it is called with bogus input, such as a bad value for the JImageLocationRef? >> >> Thanks, Harold >> >> On 4/22/2016 9:12 AM, Jim Laskey (Oracle) wrote: >>> Implemented as requested by the runtime team. >>> >>> http://cr.openjdk.java.net/~jlaskey/8147634/webrev/index.html >>> https://bugs.openjdk.java.net/browse/JDK-8147634 >>> From rachel.protacio at oracle.com Fri Apr 22 14:17:33 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 22 Apr 2016 10:17:33 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <57198BE9.5080107@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> Message-ID: <571A327D.1060809@oracle.com> Thanks for the review, David! Rachel On 4/21/2016 10:26 PM, David Holmes wrote: > Hi Rachel, > > On 22/04/2016 6:11 AM, Rachel Protacio wrote: >> Hello, >> >> Please review this fix for the package() and module() functions, making >> them pure virtual functions of Klass and implementing them in the >> relevant child classes. This cleans up some verbose and repetitive code >> that was casting and checking klass types. Also added test cases to >> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >> module() functions work as expected. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ > > The refactoring all looks good to me (though C++ annoys me in needing > to re-declare the functions in each subclass :) ). > > Cheers, > David > >> Tested with jtreg tests in jdk/test (java/lang, java/io, java/security, >> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >> hotspot and non-colo tests. >> >> Thanks! >> Rachel From goetz.lindenmaier at sap.com Fri Apr 22 14:33:25 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Apr 2016 14:33:25 +0000 Subject: RFR(S): 8154921: Fix aix after "8146879: Add option for handling existing log files in UL" In-Reply-To: <571A2658.3030202@oracle.com> References: <2e0e2e288163415fb4e1ddcb764c1434@DEWDFE13DE09.global.corp.sap> <571A2658.3030202@oracle.com> Message-ID: Hi Coleen, thanks for looking at this and sponsoring! Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Freitag, 22. April 2016 15:26 > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8154921: Fix aix after "8146879: Add option for handling > existing log files in UL" > > Looks good. I'll sponsor. I think it only needs one code review under > the "trivial" rule. > Coleen > > > On 4/22/16 9:17 AM, Lindenmaier, Goetz wrote: > > Hi > > > > 8146879 breaks the build on AIX, as stdio.h defines a macro fileno. > > I renamed os::fileno() to os::get_fileno(). > > > > Please review this small fix. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/wr16/8154921-aix_fileno/webrev.01/ > > > > Best regards, > > Goetz. From kumar.x.srinivasan at oracle.com Fri Apr 22 14:41:34 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 22 Apr 2016 07:41:34 -0700 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571A14ED.10901@gmail.com> References: <56F3F90D.9010408@gmail.com> <56FBD8F7.3020909@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> Message-ID: <571A381E.9050605@oracle.com> Hi, This is in the wrong place: 1715 if ((*env)->ExceptionOccurred(env)) { 1716 /* 1717 * We can clear pending exception because exception at this point 1718 * is not critical. 1719 */ 1720 (*env)->ExceptionClear(env); 1721 } This above needs to be after 391 SetNativeThreadName(env, "main"); 392 Here is why, supposing 1704 through 1711, returns a NULL, but have also encountered an exception. In which case the method SetNativeThreadName will return to the caller, as if nothing has happened, because NULL_CHECK simply checks for NULL and returns to the caller. This will cause the caller to enter the VM with exceptions. Kumar On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: > Hi David, > >> I don't think we need to report the exception, but can just ignore >> it. Either way we have to clear the exception before continuing. > > I've fixed it in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ > > > Thanks, > > Yasumasa > > > On 2016/04/22 15:33, David Holmes wrote: >> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I have uploaded webrev.04 as below. >>> Could you review again? >>> >>> > - hotspot: >>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >> >> Looks fine. >> >>> > >>> > - jdk: >>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >> >> As per private email (but repeated here on the record) in java.c: >> >> 715 if ((*env)->ExceptionOccurred(env)) { >> 1716 JLI_ReportExceptionDescription(env); >> 1717 } >> >> I don't think we need to report the exception, but can just ignore >> it. Either way we have to clear the exception before continuing. >> >> Thanks, >> David >> >>> Thanks, >>> >>> Yasumasa >>> >>> 2016/04/19 22:43 "Yasumasa Suenaga" >> >: >>> > >>> > Hi David, >>> > >>> > Thank you for your comment. >>> > I uploaded new webrev. Could you review again? >>> > >>> > - hotspot: >>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>> > >>> > - jdk: >>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>> > >>> > >>> >> That aside I'm not sure why you do this so late in the process, I >>> would have done it immediately after here: >>> > >>> > >>> > I think that native thread name ("main") should be set just before >>> > main method call. >>> > However, main thread is already started, so I moved it as you >>> suggested. >>> > >>> > >>> >> One thing I dislike about the current structure is that we have to >>> go from char* to java.lang.String to call setNativeName which then >>> calls >>> JVM_SetNativeThreadName which converts the j.l.String back to a char* ! >>> > >>> > >>> > SoI proposed to export new JVM function to set native thread name >>> with >>> > const char *. >>> > >>> > >>> > Thanks, >>> > >>> > Yasumasa >>> > >>> > >>> > >>> > On 2016/04/19 14:04, David Holmes wrote: >>> >> >>> >> Hi Yasumasa, >>> >> >>> >> Thanks for persevering with this to get it into the current form. >>> Sorry I haven't been able to do a detailed review until now. >>> >> >>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>> >>> >>> >>> Hi Gerard, >>> >>> >>> >>> 2016/04/19 3:14 "Gerard Ziemski" >> >>> >>> >> >>: >>> >>> > >>> >>> > hi Yasumasa, >>> >>> > >>> >>> > Nice work. I have 2 questions: >>> >>> > >>> >>> > ======== >>> >>> > File: java.c >>> >>> > >>> >>> > #1 Shouldn?t we be checking for >>> ?(*env)->ExceptionOccurred(env)? >>> >>> after every single JNI call? In this example instead of >>> NULL_CHECK, >>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>> >>> >>> >>> It is not critical if we encounter error at JNI function call >>> because >>> >>> we cannot set native thread name only. >>> >>> So I think that we do not need to leave from launcher process. >>> >> >>> >> >>> >> I agree we do not need to abort if an exception occurs (and in fact >>> I don't think an exception is even possible from this code), but we >>> should ensure any pending exception is cleared before any futher JNI >>> calls might be made. Note that NULL_CHECK is already used extensively >>> throughout the launcher code - so if this usage is wrong then it is all >>> wrong! More on this code below ... >>> >> >>> >> Other comments: >>> >> >>> >> hotspot/src/share/vm/prims/jvm.cpp >>> >> >>> >> Please add a comment to the method now that you removed the >>> internal >>> comment: >>> >> >>> >> // Sets the native thread name for a JavaThread. If specifically >>> >> // requested JNI-attached threads can also have their native >>> name set; >>> >> // otherwise we do not modify JNI-attached threads as it may >>> interfere >>> >> // with the application that created them. >>> >> >>> >> --- >>> >> >>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>> >> >>> >> Please add the following comments: >>> >> >>> >> + // Don't modify JNI-attached threads >>> >> setNativeName(name, false); >>> >> >>> >> + // May be called directly via JNI or reflection (when >>> permitted) to >>> >> + // allow JNI-attached threads to set their native name >>> >> private native void setNativeName(String name, boolean >>> allowAttachedThread); >>> >> >>> >> --- >>> >> >>> >> jd/src/java.base/share/native/libjli/java.c >>> >> >>> >> 328 #define LEAVE() \ >>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>> >> >>> >> I was going to suggest this be set later, but realized we have >>> to be >>> attached to do this and that happens inside DestroyJavaVM. :) >>> >> >>> >> + /* Set native thread name. */ >>> >> + SetNativeThreadName(env, "main"); >>> >> >>> >> The comment is redundant given the name of the method. That aside >>> I'm not sure why you do this so late in the process, I would have done >>> it immediately after here: >>> >> >>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>> >> 388 exit(1); >>> >> 389 } >>> >> + SetNativeThreadName(env, "main"); >>> >> >>> >> >>> >> + /** >>> >> + * Set native thread name as possible. >>> >> + */ >>> >> >>> >> Other than the as->if change I'm unclear where the "possible" bit >>> comes into play - why would it not be possible? >>> >> >>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>> "java/lang/Thread")); >>> >> 1706 NULL_CHECK(currentThreadID = >>> (*env)->GetStaticMethodID(env, >>> cls, >>> >> 1707 "currentThread", >>> "()Ljava/lang/Thread;")); >>> >> 1708 NULL_CHECK(currentThread = >>> (*env)->CallStaticObjectMethod(env, cls, >>> >> 1709 currentThreadID)); >>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, cls, >>> >> 1711 "setNativeName", >>> "(Ljava/lang/String;Z)V")); >>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>> setNativeNameID, >>> >> 1714 nameString, JNI_TRUE); >>> >> >>> >> As above NULL_CHECK is fine here, but we should check for and clear >>> any pending exception after CallVoidMethod. >>> >> >>> >> One thing I dislike about the current structure is that we have to >>> go from char* to java.lang.String to call setNativeName which then >>> calls >>> JVM_SetNativeThreadName which converts the j.l.String back to a char* ! >>> Overall I wonder about the affect on startup cost. But if there is an >>> issue we can revisit this. >>> >> >>> >> Thanks, >>> >> David >>> >> ----- >>> >> >>> >> >>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set native >>> thread >>> >>> name if possible.? not "Set native thread name as possible.?? >>> >>> >>> >>> Sorry for my bad English :-) >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Yasumasa >>> >>> >>> >>> > cheers >>> >>> > >>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>> >>> >>> >> wrote: >>> >>> > > >>> >>> > > Hi David, >>> >>> > > >>> >>> > > I uploaded new webrev: >>> >>> > > >>> >>> > > - hotspot: >>> >>> > > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>> >>> > > >>> >>> > > - jdk: >>> >>> > > >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>> >>> > > >>> >>> > > >>> >>> > >> it won't work unless you change the semantics of setName >>> so I'm >>> >>> not sure what you were thinking here. To take advantage of an arg >>> taking >>> >>> JVM_SetNativThreadName you would need to call it directly as no >>> Java >>> >>> code will call it . ??? >>> >>> > > >>> >>> > > I added a flag for setting native thread name to JNI-attached >>> thread. >>> >>> > > This change can set native thread name if main thread >>> changes to >>> >>> JNI-attached thread. >>> >>> > > >>> >>> > > >>> >>> > > Thanks, >>> >>> > > >>> >>> > > Yasumasa >>> >>> > > >>> >>> > > >>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>> >>> > >>> Hi David, >>> >>> > >>> >>> >>> > >>>> That change in behaviour may be a problem, it could be >>> considered a >>> >>> > >>>> regression that setName stops setting the native thread >>> main, even >>> >>> > >>>> though we never really intended it to work in the first >>> place. >>> >>> :( Such >>> >>> > >>>> a change needs to go through CCC. >>> >>> > >>> >>> >>> > >>> I understood. >>> >>> > >>> Can I send CCC request? >>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>> >>> > >> >>> >>> > >> Sorry you can't file a CCC request, you would need a >>> sponsor for >>> >>> that. But at this stage I don't think I agree with the proposed >>> change >>> >>> because of the change in behaviour - there's no way to restore the >>> >>> "broken" behaviour. >>> >>> > >> >>> >>> > >>> I want to continue to discuss about it on JDK-8154331 [1]. >>> >>> > >> >>> >>> > >> Okay we can do that. >>> >>> > >> >>> >>> > >>> >>> >>> > >>>> Further, we expect the launcher to use the supported JNI >>> >>> interface (as >>> >>> > >>>> other processes would), not the internal JVM interface >>> that >>> >>> exists for >>> >>> > >>>> the JDK sources to communicate with the JVM. >>> >>> > >>> >>> >>> > >>> I think that we do not use JVM interface if we add new >>> method in >>> >>> > >>> LauncherHelper as below: >>> >>> > >>> ---------------- >>> >>> > >>> diff -r f02139a1ac84 >>> >>> > >>> >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> >>> > >>> --- >>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>> >>> > >>> +++ >>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>> >>> > >>> @@ -960,4 +960,8 @@ >>> >>> > >>> else >>> >>> > >>> return md.toNameAndVersion() + " (" + loc + >>> ")"; >>> >>> > >>> } >>> >>> > >>> + >>> >>> > >>> + static void setNativeThreadName(String name) { >>> >>> > >>> + Thread.currentThread().setName(name); >>> >>> > >>> + } >>> >>> > >> >>> >>> > >> You could also make that call via JNI directly, so not >>> sure the >>> >>> helper adds much here. But it won't work unless you change the >>> semantics >>> >>> of setName so I'm not sure what you were thinking here. To take >>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>> need to >>> call >>> >>> it directly as no Java code will call it . ??? >>> >>> > >> >>> >>> > >> David >>> >>> > >> ----- >>> >>> > >> >>> >>> > >>> } >>> >>> > >>> diff -r f02139a1ac84 >>> src/java.base/share/native/libjli/java.c >>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>> Apr 13 >>> 14:19:30 >>> >>> > >>> 2016 +0000 >>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>> Apr 16 >>> 11:25:53 >>> >>> > >>> 2016 +0900 >>> >>> > >>> @@ -125,6 +125,7 @@ >>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>> >>> > >>> >>> >>> > >>> static void SetPaths(int argc, char **argv); >>> >>> > >>> >>> >>> > >>> @@ -325,6 +326,7 @@ >>> >>> > >>> * mainThread.isAlive() to work as expected. >>> >>> > >>> */ >>> >>> > >>> #define LEAVE() \ >>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>> >>> > >>> do { \ >>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>> >>> > >>> @@ -488,6 +490,9 @@ >>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>> >>> > >>> >>> >>> > >>> + /* Set native thread name. */ >>> >>> > >>> + SetNativeThreadName(env, "main"); >>> >>> > >>> + >>> >>> > >>> /* Invoke main method. */ >>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>> mainArgs); >>> >>> > >>> >>> >>> > >>> @@ -1686,6 +1691,22 @@ >>> >>> > >>> joptString); >>> >>> > >>> } >>> >>> > >>> >>> >>> > >>> +/** >>> >>> > >>> + * Set native thread name as possible. >>> >>> > >>> + */ >>> >>> > >>> +static void >>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>> >>> > >>> +{ >>> >>> > >>> + jmethodID setNativeThreadNameID; >>> >>> > >>> + jstring nameString; >>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>> >>> > >>> + NULL_CHECK(cls); >>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>> >>> (*env)->GetStaticMethodID(env, cls, >>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>> name)); >>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>> setNativeThreadNameID, >>> >>> > >>> nameString); >>> >>> > >>> +} >>> >>> > >>> + >>> >>> > >>> /* >>> >>> > >>> * Prints default usage or the Xusage message, see >>> >>> > >>> sun.launcher.LauncherHelper.java >>> >>> > >>> */ >>> >>> > >>> ---------------- >>> >>> > >>> >>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>> >>> > >>> >>> >>> > >>>> However this is still a change to the exported JVM >>> interface and so >>> >>> > >>>> has to be approved. >>> >>> > >>> >>> >>> > >>> Do you mean that this change needs CCC? >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> Thanks, >>> >>> > >>> >>> >>> > >>> Yasumasa >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> [1] >>> >>> > >>> >>> >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>> >>> > >>>>> Hi David, >>> >>> > >>>>> >>> >>> > >>>>>> I think it is a bug based on the comment here: >>> >>> > >>>>>> >>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for >>> main >>> >>> thread and >>> >>> > >>>>>> JNI attached threads >>> >>> > >>>>> >>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>> >>> > >>>>> >>> >>> > >>>>> >>> >>> > >>>>>> Though that will introduce a change in behaviour by >>> itself as >>> >>> setName >>> >>> > >>>>>> will no longer set the native name for the main thread. >>> >>> > >>>>> >>> >>> > >>>>> I know. >>> >>> > >>>> >>> >>> > >>>> That change in behaviour may be a problem, it could be >>> considered a >>> >>> > >>>> regression that setName stops setting the native thread >>> main, even >>> >>> > >>>> though we never really intended it to work in the first >>> place. >>> >>> :( Such >>> >>> > >>>> a change needs to go through CCC. >>> >>> > >>>> >>> >>> > >>>>> I checked changeset history. >>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, >>> and it is >>> >>> > >>>>> backported JDK 8. >>> >>> > >>>> >>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>> >>> > >>>> >>> >>> > >>>>> However, this function seems to be called from >>> >>> Thread#setNativeName() >>> >>> > >>>>> only. >>> >>> > >>>>> In addition, Thread#setNativeName() is private method. >>> >>> > >>>>> >>> >>> > >>>>> Thus I think that we can add an argument to >>> >>> JVM_SetNativeThreadName() >>> >>> > >>>>> for force setting. >>> >>> > >>>>> (e.g. "bool forced") >>> >>> > >>>>> >>> >>> > >>>>> It makes a change of JVM API. >>> >>> > >>>>> However, this function is NOT public, so I think we can >>> add one >>> >>> more >>> >>> > >>>>> argument. >>> >>> > >>>>> >>> >>> > >>>>> What do you think about this? >>> >>> > >>>>> If it is accepted, we can set native thread name from >>> Java >>> >>> launcher. >>> >>> > >>>> >>> >>> > >>>> The private/public aspect of the Java API is not really at >>> >>> issue. Yes >>> >>> > >>>> we would add another arg to the JVM function to allow >>> it to >>> apply to >>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>> reflect that >>> >>> not just >>> >>> > >>>> "force"). However this is still a change to the >>> exported JVM >>> >>> interface >>> >>> > >>>> and so has to be approved. Further, we expect the >>> launcher to >>> >>> use the >>> >>> > >>>> supported JNI interface (as other processes would), not >>> the >>> internal >>> >>> > >>>> JVM interface that exists for the JDK sources to >>> communicate >>> >>> with the >>> >>> > >>>> JVM. >>> >>> > >>>> >>> >>> > >>>> David >>> >>> > >>>> ----- >>> >>> > >>>> >>> >>> > >>>>> >>> >>> > >>>>> Thanks, >>> >>> > >>>>> >>> >>> > >>>>> Yasumasa >>> >>> > >>>>> >>> >>> > >>>>> >>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>> >>> > >>>>>> Hi Yasumasa, >>> >>> > >>>>>> >>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>> >>> > >>>>>>> Hi David, >>> >>> > >>>>>>> >>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>> being a >>> >>> JNI-attached >>> >>> > >>>>>>>> thread seems accidental to me >>> >>> > >>>>>>> >>> >>> > >>>>>>> Should I file it to JBS? >>> >>> > >>>>>> >>> >>> > >>>>>> I think it is a bug based on the comment here: >>> >>> > >>>>>> >>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for >>> main >>> >>> thread and >>> >>> > >>>>>> JNI attached threads >>> >>> > >>>>>> >>> >>> > >>>>>> Though that will introduce a change in behaviour by >>> itself as >>> >>> setName >>> >>> > >>>>>> will no longer set the native name for the main thread. >>> >>> > >>>>>> >>> >>> > >>>>>>> I think that we can fix as below: >>> >>> > >>>>>>> --------------- >>> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 >>> 13:31:11 >>> >>> 2016 +0200 >>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 >>> 17:50:10 >>> >>> 2016 +0900 >>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>> >>> > >>>>>>> >>> >>> > >>>>>>> // Attach the main thread to this os thread >>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>> >>> > >>>>>>> // must do this before set_active_handles >>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization is >>> complete >>> >>> - nop if >>> >>> > >>>>>>> no agents. >>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>> >>> > >>>>>>> >>> >>> > >>>>>>> + // Change attach status to "attached" >>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>> >>> > >>>>>>> + >>> >>> > >>>>>> >>> >>> > >>>>>> I think we can do this straight after the JavaThread >>> constructor. >>> >>> > >>>>>> >>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start tracing >>> >>> > >>>>>>> backend."); >>> >>> > >>>>>>> } >>> >>> > >>>>>>> --------------- >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>>> If it wants to name its native threads then it is free >>> to do so, >>> >>> > >>>>>>> >>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change >>> native >>> >>> thread name >>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>> >>> > >>>>>>> However, I think that it should be changed if Java >>> developer >>> >>> calls >>> >>> > >>>>>>> Thread#setName() explicitly. >>> >>> > >>>>>>> It is not the same of changing native thread name at >>> >>> > >>>>>>> Threads::create_vm(). >>> >>> > >>>>>>> >>> >>> > >>>>>>> If it is allowed, I want to fix >>> SetNativeThreadName() as >>> below. >>> >>> > >>>>>>> What do you think about this? >>> >>> > >>>>>> >>> >>> > >>>>>> The decision to not change the name of JNI-attached >>> threads was a >>> >>> > >>>>>> deliberate one** - this functionality originated with >>> the OSX >>> >>> port and >>> >>> > >>>>>> it was reported that the initial feedback with this >>> feature was to >>> >>> > >>>>>> ensure it didn't mess with thread names that had been >>> set by >>> >>> the host >>> >>> > >>>>>> process. If we do as you propose then we will just >>> have an >>> >>> > >>>>>> inconsistency for people to complain about: "why does my >>> >>> native thread >>> >>> > >>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>> >>> > >>>>>> >>> >>> > >>>>>> ** If you follow the bugs and related discussions on >>> this, the >>> >>> > >>>>>> semantics and limitations (truncation, current thread >>> only, >>> >>> non-JNI >>> >>> > >>>>>> threads only) of setting the native thread name were >>> supposed >>> >>> to be >>> >>> > >>>>>> documented in the release notes - but as far as I can >>> see >>> that >>> >>> never >>> >>> > >>>>>> happened. :( >>> >>> > >>>>>> >>> >>> > >>>>>> My position on this remains that if it is desirable for >>> the main >>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native names >>> then the >>> >>> > >>>>>> launcher needs to be setting them using the available >>> platform >>> >>> APIs. >>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by >>> the VM >>> >>> code for >>> >>> > >>>>>> this - due to the need to verify API availability. >>> >>> > >>>>>> >>> >>> > >>>>>> Any change in behaviour in relation to Thread.setName >>> would >>> >>> have to go >>> >>> > >>>>>> through our CCC process I think. But a change in the >>> launcher >>> >>> would >>> >>> > >>>>>> not. >>> >>> > >>>>>> >>> >>> > >>>>>> Sorry. >>> >>> > >>>>>> >>> >>> > >>>>>> David >>> >>> > >>>>>> ----- >>> >>> > >>>>>> >>> >>> > >>>>>>> --------------- >>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 >>> 13:31:11 >>> >>> 2016 +0200 >>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 >>> 17:50:10 >>> >>> 2016 +0900 >>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>> >>> > >>>>>>> JavaThread* thr = >>> java_lang_Thread::thread(java_thread); >>> >>> > >>>>>>> // Thread naming only supported for the current >>> thread, >>> >>> doesn't >>> >>> > >>>>>>> work >>> >>> > >>>>>>> for >>> >>> > >>>>>>> // target threads. >>> >>> > >>>>>>> - if (Thread::current() == thr && >>> >>> !thr->has_attached_via_jni()) { >>> >>> > >>>>>>> + if (Thread::current() == thr) { >>> >>> > >>>>>>> // we don't set the name of an attached thread >>> to avoid >>> >>> stepping >>> >>> > >>>>>>> // on other programs >>> >>> > >>>>>>> const char *thread_name = >>> >>> > >>>>>>> >>> >>> >>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>> >>> > >>>>>>> --------------- >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> Thanks, >>> >>> > >>>>>>> >>> >>> > >>>>>>> Yasumasa >>> >>> > >>>>>>> >>> >>> > >>>>>>> >>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>> >>> > >>>>>>>>> Roger, >>> >>> > >>>>>>>>> Thanks for your comment! >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> David, >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>> don't like >>> >>> > >>>>>>>>>>>> exposing >>> >>> > >>>>>>>>>>>> a new JVM function this way. >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>> initializing VM >>> (before >>> >>> > >>>>>>>>> calling >>> >>> > >>>>>>>>> main method), >>> >>> > >>>>>>>>> I could set native thread name. >>> >>> > >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). >>> So we >>> >>> can't >>> >>> > >>>>>>>>> set >>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> Right - I came to the same realization earlier this >>> morning. >>> >>> Which, >>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise >>> here that >>> >>> we don't >>> >>> > >>>>>>>> set the name of threads not created by the JVM. The >>> fact >>> >>> that the >>> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >>> thread seems >>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only >>> working by >>> >>> > >>>>>>>> accident for the initial attach, and can't be used >>> for the >>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>> inconsistently >>> >>> named at >>> >>> > >>>>>>>> the native level. >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has to be >>> >>> treated like >>> >>> > >>>>>>>> any other process that might host a JVM. If it >>> wants to >>> name its >>> >>> > >>>>>>>> native threads then it is free to do so, but I >>> would not be >>> >>> exporting >>> >>> > >>>>>>>> a function from the JVM to do that - it would have to >>> use the OS >>> >>> > >>>>>>>> specific API's for that on a platform-by-platform >>> basis. >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> Sorry. >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> David >>> >>> > >>>>>>>> ----- >>> >>> > >>>>>>>> >>> >>> > >>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> Thanks, >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> Yasumasa >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> >>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>> >>> > >>>>>>>>>> Hi, >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> Comments: >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>> perform >>> >>> different >>> >>> > >>>>>>>>>> functions: >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> - The first function applies to the current >>> thread, the >>> >>> second >>> >>> > >>>>>>>>>> one a >>> >>> > >>>>>>>>>> specific java thread. >>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>> somewhere >>> >>> about >>> >>> > >>>>>>>>>> what >>> >>> > >>>>>>>>>> the new function does. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to >>> (void*) >>> >>> > >>>>>>>>>> instead of >>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>> >>> > >>>>>>>>>> as is done on unix and mac. >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>> >>> > >>>>>>>>>> - 737: looks wrong to >>> overwriteifn->GetCreatedJavaVMs >>> >>> used at >>> >>> > >>>>>>>>>> line 730 >>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>> the cast >>> >>> on the >>> >>> > >>>>>>>>>> same >>> >>> > >>>>>>>>>> line as dlsym... >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> $.02, Roger >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> >>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>> >>> > >>>>>>>>>>>> That is an interesting question which I haven't >>> had >>> time to >>> >>> > >>>>>>>>>>>> check - >>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>> JNI-attached >>> >>> thread >>> >>> > >>>>>>>>>>>> then >>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>> suggestion >>> >>> should >>> >>> > >>>>>>>>>>>> work >>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>> treatment of >>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >>> confirmed >>> >>> native >>> >>> > >>>>>>>>>>> thread name (test) was set. >>> >>> > >>>>>>>>>>> --------- >>> >>> > >>>>>>>>>>> public class Sleep{ >>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>> Exception{ >>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>> >>> > >>>>>>>>>>> } >>> >>> > >>>>>>>>>>> } >>> >>> > >>>>>>>>>>> --------- >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>> don't like >>> >>> > >>>>>>>>>>>> exposing >>> >>> > >>>>>>>>>>>> a new JVM function this way. >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>> Thanks, >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>> Yasumasa >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>> >>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>> >>> > >>>>>>>>>>>>> Hi, >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>> >>> > >>>>>>>>>>>>>> Hi, >>> >>> > >>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>> >>> > >>>>>>>>>>>>>>> Hi David, >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>> thread >>> >>> name, and JLI >>> >>> > >>>>>>>>>>>>>>> uses it >>> >>> > >>>>>>>>>>>>>>> in new webrev. >>> >>> > >>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>> >>> core-libs will >>> >>> > >>>>>>>>>>>>>> need to >>> >>> > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - >>> now cc'd. >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> Thanks! >>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>> >>> Thread.setName >>> >>> > >>>>>>>>>>>>>> rather >>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>> hotspot changes >>> >>> > >>>>>>>>>>>>>> needed in >>> >>> > >>>>>>>>>>>>>> that case. >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>> Thread#setName() in >>> >>> > >>>>>>>>>>>>> Thread#init(), >>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>> >>> > >>>>>>>>>>>> >>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>> which is >>> >>> why the >>> >>> > >>>>>>>>>>>> native >>> >>> > >>>>>>>>>>>> name is not set. >>> >>> > >>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI attached >>> thread. >>> >>> > >>>>>>>>>>>> >>> >>> > >>>>>>>>>>>> That is an interesting question which I haven't >>> had >>> time to >>> >>> > >>>>>>>>>>>> check - >>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>> JNI-attached >>> >>> thread >>> >>> > >>>>>>>>>>>> then >>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>> suggestion >>> >>> should >>> >>> > >>>>>>>>>>>> work >>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>> treatment of >>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>> >>> > >>>>>>>>>>>> >>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>> don't like >>> >>> > >>>>>>>>>>>> exposing >>> >>> > >>>>>>>>>>>> a new JVM function this way. >>> >>> > >>>>>>>>>>>> >>> >>> > >>>>>>>>>>>> Thanks, >>> >>> > >>>>>>>>>>>> David >>> >>> > >>>>>>>>>>>> ----- >>> >>> > >>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>> function to set >>> >>> native >>> >>> > >>>>>>>>>>>>> thread name. >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> Thanks, >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> Yasumasa >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> [1] >>> >>> > >>>>>>>>>>>>> >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>> Thanks, >>> >>> > >>>>>>>>>>>>>> David >>> >>> > >>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> Could you review again? >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> - hotspot: >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> >>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> - jdk: >>> >>> > >>>>>>>>>>>>>>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> Thanks, >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> Yasumasa >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as well >>> ... >>> >>> > >>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>> >>> > >>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have >>> been on >>> >>> > >>>>>>>>>>>>>>>> vacation). >>> >>> > >>>>>>>>>>>>>>>> This >>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct >>> as we >>> >>> do not >>> >>> > >>>>>>>>>>>>>>>> set the >>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >>> includes the >>> >>> > >>>>>>>>>>>>>>>> "main" >>> >>> > >>>>>>>>>>>>>>>> thread. >>> >>> > >>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>> David >>> >>> > >>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>> >>> > >>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>> >>> > >>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>> >>> >>> >>: >>> >>> > >>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>> >>> > >>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>> >>> > >>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>> >>> > >>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>> >>> > >>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>> >>> > >>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga >>> wrote: >>> >>> > >>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>> >>> > >>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga >>> wrote: >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>> >>> >>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> >>>: >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>> Suenaga wrote: >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >> >>> >>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> >>>>: >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>> a/src/share/vm/runtime/thread.cpp Thu >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>> b/src/share/vm/runtime/thread.cpp Thu >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>> >>> JavaThread(); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> main_thread->set_thread_state(_thread_in_vm); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> main_thread->initialize_thread_current(); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>> >>> main_thread->set_native_thread_name("main"); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>> >>> set_active_handles >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> main_thread->record_stack_base_and_size(); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>> something? >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to >>> thread >>> >>> name in >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>> setName(). >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, >>> native >>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is >>> already >>> >>> starte >>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >>> thrrad name >>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>> something like >>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp >>> Tue >>> >>> Mar 29 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp >>> Wed >>> >>> Mar 30 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>> create_initial_thread(Handle >>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>> initial_thread_name = >>> >>> "main"; >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>> (THREAD, k); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> klass->allocate_instance_handle(CHECK_NULL); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> java_lang_Thread::set_thread(thread_oop(), >>> >>> thread); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> java_lang_Thread::set_priority(thread_oop(), >>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> java_lang_String::create_from_str("main", >>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> thread->set_native_thread_name(initial_thread_name); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> java_lang_String::create_from_str(initial_thread_name, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>> thread_oop, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself >>> 'java' and >>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process >>> (and >>> >>> thus >>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process >>> is not >>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>> >>> JavaThread. So I >>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>> thread. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>> anyhow, since >>> >>> we want >>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name >>> might >>> >>> have >>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | >>> head -4 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like >>> 'Java Main >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java >>> >>> launcher - e.g. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread >>> name, >>> >>> I think >>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa >>> >>> Suenaga wrote: >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>> thread >>> >>> name via >>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >>> have it. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, >>> and main >>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >>> should have >>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you >>> review it? >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>> > >>>>>>>>>> >>> >>> > >>> >>> >>> From martin.doerr at sap.com Fri Apr 22 14:48:40 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 22 Apr 2016 14:48:40 +0000 Subject: 8154867: PPC64: Better byte behavior In-Reply-To: <571A2319.5040602@oracle.com> References: <571A2319.5040602@oracle.com> Message-ID: <0c6d09724aee497499194ad0d5d3e3f2@DEWDFE13DE14.global.corp.sap> Hi Coleen, thanks for taking a look. Unfortunately, I've seen your email a little too late. I agree with that btos/ztos/stos/ctos are unused for the return entry and should better get removed. So we could do a cleanup change. I think the removal of those entry points makes sense which is what you have proposed: https://bugs.openjdk.java.net/browse/JDK-8139788 Maybe we will be able to do some more PPC cleanup. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Freitag, 22. April 2016 15:12 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: 8154867: PPC64: Better byte behavior Hi Martin, http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/src/cpu/ppc/vm/templateTable_ppc_64.cpp.udiff.html This change looks good except the code in ireturn looks strange because state is never btos/ztos/stos/ctos. OR if it was btos,stos and ctos and you're trying to return a boolean, there would have to be additional narrowing for those cases too. It think it would be more accurate to have the small int tos states above itos in your switch statement. The only reason we added ztos was to make the backports easier for these bugs. I think these unused tos optimization cases should be removed. Do you agree? https://bugs.openjdk.java.net/browse/JDK-8139788 Also, I guess it doesn't matter for ppc, but the April cpu code is in http://hg.openjdk.java.net/jdk9/hs and I was going to push the zero change from Severin there. Should you make these changes for that repository instead? thanks, Coleen On 4/22/16 4:55 AM, Doerr, Martin wrote: > Hi, > > the PPC64 part of "Better byte behavior" (8148487) was done in jdk8u but is also needed in 9. > > Here's the port for 9/dev: > http://cr.openjdk.java.net/~mdoerr/8154867_PPC64_Better_byte_behavior/webrev.00/ > > Please review. > > Best regards, > Martin > From rachel.protacio at oracle.com Fri Apr 22 15:12:34 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 22 Apr 2016 11:12:34 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571A1CD5.7040602@oracle.com> References: <571933EF.6040304@oracle.com> <571A1CD5.7040602@oracle.com> Message-ID: <571A3F62.2060803@oracle.com> Thanks for the review, Lois. Will make those changes. Rachel On 4/22/2016 8:45 AM, Lois Foltan wrote: > > On 4/21/2016 4:11 PM, Rachel Protacio wrote: >> Hello, >> >> Please review this fix for the package() and module() functions, >> making them pure virtual functions of Klass and implementing them in >> the relevant child classes. This cleans up some verbose and >> repetitive code that was casting and checking klass types. Also added >> test cases to runtime/modules/getModuleJNI/GetModule.java, ensuring >> that all the module() functions work as expected. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ > > Hi Rachel, > > This looks really good! A couple of comments: > > - src/share/vm/oops/arrayKlass.hpp > line #140 & 141 - instead of inserting the declarations of the module > and package methods at the end of the ArrayKlass data structure can > you move them up to line #71 or right after the declaration of > java_super() at line #73. This is picky, but for readability seems to > fit more with other like methods. > > - src/share/vm/oops/klass.hpp > It seems like the precedence is to have forward declarations for > classes that the Klass data structures uses. Can you change that for > PackageEntry and ModuleEntry instead of including the headers? > > - src/share/vm/oops/objArrayKlass.cpp > line #420 - Remove //Packages comment - really adds no value > line #421 - Remove blank line > #line #423 - A comment that would be helpful and please include, "The > array is defined in the module of its bottom class" > // The array is defined in the module of its bottom class > - src/share/vm/oops/typeArrayKlass.cpp > line #348 - A comment is needed, something like, "A TypeArrayKlass is > an array of a primitive type, its defining module is java.base" > > - src/share/vm/runtime/reflection.cpp > line #511 & #512 - I think we need to change that comment because I am > not sure if it is accurate to state that java.base exports its > packages to all modules. Please change to something like, "A > TypeArray's defining module is java.base, access to the TypeArray is > allowed" > > - test/runtime/modules/getModuleJNI/GetModule.java > Thank you for improving this test! > > I don't need to see another webrev for this, > Thanks, > Lois > >> >> Tested with jtreg tests in jdk/test (java/lang, java/io, >> java/security, java/util, tools/jimage, tools/jlink, and tools/jmod), >> JPRT, and RBT hotspot and non-colo tests. >> >> Thanks! >> Rachel > From rachel.protacio at oracle.com Fri Apr 22 15:22:57 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Fri, 22 Apr 2016 11:22:57 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571A25FF.1080700@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> Message-ID: <571A41D1.30707@oracle.com> Hi, Coleen, Thanks for the review! I'll remove the arrayKlass entries and, seeing no other objections, will commit. Rachel On 4/22/2016 9:24 AM, Coleen Phillimore wrote: > > Hi, > > http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html > > > I don't think you need module or package declared in arrayKlass.hpp > since it should be abstract also, ie. there should be no instances of > ArrayKlass. > > Otherwise, looks great. I love seeing those InstanceKlass::casts go > away. > > Coleen > > > On 4/21/16 10:26 PM, David Holmes wrote: >> Hi Rachel, >> >> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>> Hello, >>> >>> Please review this fix for the package() and module() functions, making >>> them pure virtual functions of Klass and implementing them in the >>> relevant child classes. This cleans up some verbose and repetitive code >>> that was casting and checking klass types. Also added test cases to >>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>> module() functions work as expected. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >> >> The refactoring all looks good to me (though C++ annoys me in needing >> to re-declare the functions in each subclass :) ). >> >> Cheers, >> David >> >>> Tested with jtreg tests in jdk/test (java/lang, java/io, java/security, >>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >>> hotspot and non-colo tests. >>> >>> Thanks! >>> Rachel > From kumar.x.srinivasan at oracle.com Fri Apr 22 16:14:32 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Fri, 22 Apr 2016 09:14:32 -0700 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571A381E.9050605@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> Message-ID: <571A4DE8.8060508@oracle.com> Also a couple of minor suggestions: - * Set native thread name as possible. + * Set native thread name if possible. + /* - * We can clear pending exception because exception at this point - * is not critical. + */ + /* + * Clear non critical pending exceptions at this point. + */ Thanks Kumar > Hi, > > This is in the wrong place: > > 1715 if ((*env)->ExceptionOccurred(env)) { > 1716 /* > 1717 * We can clear pending exception because exception at this > point > 1718 * is not critical. > 1719 */ > 1720 (*env)->ExceptionClear(env); > 1721 } > > This above needs to be after > 391 SetNativeThreadName(env, "main"); > 392 > > Here is why, supposing 1704 through 1711, returns a NULL, > but have also encountered an exception. In which case > the method SetNativeThreadName will return to the caller, as > if nothing has happened, because NULL_CHECK simply checks for NULL > and returns to the caller. This will cause the caller to enter > the VM with exceptions. > > Kumar > > > On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >> Hi David, >> >>> I don't think we need to report the exception, but can just ignore >>> it. Either way we have to clear the exception before continuing. >> >> I've fixed it in new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/22 15:33, David Holmes wrote: >>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I have uploaded webrev.04 as below. >>>> Could you review again? >>>> >>>> > - hotspot: >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>> >>> Looks fine. >>> >>>> > >>>> > - jdk: >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>> >>> As per private email (but repeated here on the record) in java.c: >>> >>> 715 if ((*env)->ExceptionOccurred(env)) { >>> 1716 JLI_ReportExceptionDescription(env); >>> 1717 } >>> >>> I don't think we need to report the exception, but can just ignore >>> it. Either way we have to clear the exception before continuing. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>> >: >>>> > >>>> > Hi David, >>>> > >>>> > Thank you for your comment. >>>> > I uploaded new webrev. Could you review again? >>>> > >>>> > - hotspot: >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>> > >>>> > - jdk: >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>> > >>>> > >>>> >> That aside I'm not sure why you do this so late in the process, I >>>> would have done it immediately after here: >>>> > >>>> > >>>> > I think that native thread name ("main") should be set just before >>>> > main method call. >>>> > However, main thread is already started, so I moved it as you >>>> suggested. >>>> > >>>> > >>>> >> One thing I dislike about the current structure is that we have to >>>> go from char* to java.lang.String to call setNativeName which then >>>> calls >>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>> char* ! >>>> > >>>> > >>>> > SoI proposed to export new JVM function to set native thread >>>> name with >>>> > const char *. >>>> > >>>> > >>>> > Thanks, >>>> > >>>> > Yasumasa >>>> > >>>> > >>>> > >>>> > On 2016/04/19 14:04, David Holmes wrote: >>>> >> >>>> >> Hi Yasumasa, >>>> >> >>>> >> Thanks for persevering with this to get it into the current form. >>>> Sorry I haven't been able to do a detailed review until now. >>>> >> >>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>> >>> >>>> >>> Hi Gerard, >>>> >>> >>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>> >>>> >>> >>> >>: >>>> >>> > >>>> >>> > hi Yasumasa, >>>> >>> > >>>> >>> > Nice work. I have 2 questions: >>>> >>> > >>>> >>> > ======== >>>> >>> > File: java.c >>>> >>> > >>>> >>> > #1 Shouldn?t we be checking for >>>> ?(*env)->ExceptionOccurred(env)? >>>> >>> after every single JNI call? In this example instead of >>>> NULL_CHECK, >>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>> >>> >>>> >>> It is not critical if we encounter error at JNI function call >>>> because >>>> >>> we cannot set native thread name only. >>>> >>> So I think that we do not need to leave from launcher process. >>>> >> >>>> >> >>>> >> I agree we do not need to abort if an exception occurs (and in >>>> fact >>>> I don't think an exception is even possible from this code), but we >>>> should ensure any pending exception is cleared before any futher JNI >>>> calls might be made. Note that NULL_CHECK is already used extensively >>>> throughout the launcher code - so if this usage is wrong then it is >>>> all >>>> wrong! More on this code below ... >>>> >> >>>> >> Other comments: >>>> >> >>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>> >> >>>> >> Please add a comment to the method now that you removed the >>>> internal >>>> comment: >>>> >> >>>> >> // Sets the native thread name for a JavaThread. If specifically >>>> >> // requested JNI-attached threads can also have their native >>>> name set; >>>> >> // otherwise we do not modify JNI-attached threads as it may >>>> interfere >>>> >> // with the application that created them. >>>> >> >>>> >> --- >>>> >> >>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>> >> >>>> >> Please add the following comments: >>>> >> >>>> >> + // Don't modify JNI-attached threads >>>> >> setNativeName(name, false); >>>> >> >>>> >> + // May be called directly via JNI or reflection (when >>>> permitted) to >>>> >> + // allow JNI-attached threads to set their native name >>>> >> private native void setNativeName(String name, boolean >>>> allowAttachedThread); >>>> >> >>>> >> --- >>>> >> >>>> >> jd/src/java.base/share/native/libjli/java.c >>>> >> >>>> >> 328 #define LEAVE() \ >>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>> >> >>>> >> I was going to suggest this be set later, but realized we have >>>> to be >>>> attached to do this and that happens inside DestroyJavaVM. :) >>>> >> >>>> >> + /* Set native thread name. */ >>>> >> + SetNativeThreadName(env, "main"); >>>> >> >>>> >> The comment is redundant given the name of the method. That aside >>>> I'm not sure why you do this so late in the process, I would have done >>>> it immediately after here: >>>> >> >>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>> >> 388 exit(1); >>>> >> 389 } >>>> >> + SetNativeThreadName(env, "main"); >>>> >> >>>> >> >>>> >> + /** >>>> >> + * Set native thread name as possible. >>>> >> + */ >>>> >> >>>> >> Other than the as->if change I'm unclear where the "possible" bit >>>> comes into play - why would it not be possible? >>>> >> >>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>> "java/lang/Thread")); >>>> >> 1706 NULL_CHECK(currentThreadID = >>>> (*env)->GetStaticMethodID(env, >>>> cls, >>>> >> 1707 "currentThread", >>>> "()Ljava/lang/Thread;")); >>>> >> 1708 NULL_CHECK(currentThread = >>>> (*env)->CallStaticObjectMethod(env, cls, >>>> >> 1709 currentThreadID)); >>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, >>>> cls, >>>> >> 1711 "setNativeName", >>>> "(Ljava/lang/String;Z)V")); >>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>> setNativeNameID, >>>> >> 1714 nameString, JNI_TRUE); >>>> >> >>>> >> As above NULL_CHECK is fine here, but we should check for and >>>> clear >>>> any pending exception after CallVoidMethod. >>>> >> >>>> >> One thing I dislike about the current structure is that we have to >>>> go from char* to java.lang.String to call setNativeName which then >>>> calls >>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>> char* ! >>>> Overall I wonder about the affect on startup cost. But if there is an >>>> issue we can revisit this. >>>> >> >>>> >> Thanks, >>>> >> David >>>> >> ----- >>>> >> >>>> >> >>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set native >>>> thread >>>> >>> name if possible.? not "Set native thread name as possible.?? >>>> >>> >>>> >>> Sorry for my bad English :-) >>>> >>> >>>> >>> Thanks, >>>> >>> >>>> >>> Yasumasa >>>> >>> >>>> >>> > cheers >>>> >>> > >>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>> >>>> >>> >> wrote: >>>> >>> > > >>>> >>> > > Hi David, >>>> >>> > > >>>> >>> > > I uploaded new webrev: >>>> >>> > > >>>> >>> > > - hotspot: >>>> >>> > > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>> >>> > > >>>> >>> > > - jdk: >>>> >>> > > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>> >>> > > >>>> >>> > > >>>> >>> > >> it won't work unless you change the semantics of setName >>>> so I'm >>>> >>> not sure what you were thinking here. To take advantage of an arg >>>> taking >>>> >>> JVM_SetNativThreadName you would need to call it directly as >>>> no Java >>>> >>> code will call it . ??? >>>> >>> > > >>>> >>> > > I added a flag for setting native thread name to >>>> JNI-attached >>>> thread. >>>> >>> > > This change can set native thread name if main thread >>>> changes to >>>> >>> JNI-attached thread. >>>> >>> > > >>>> >>> > > >>>> >>> > > Thanks, >>>> >>> > > >>>> >>> > > Yasumasa >>>> >>> > > >>>> >>> > > >>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>> >>> > >>> Hi David, >>>> >>> > >>> >>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>> considered a >>>> >>> > >>>> regression that setName stops setting the native thread >>>> main, even >>>> >>> > >>>> though we never really intended it to work in the >>>> first place. >>>> >>> :( Such >>>> >>> > >>>> a change needs to go through CCC. >>>> >>> > >>> >>>> >>> > >>> I understood. >>>> >>> > >>> Can I send CCC request? >>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>> >>> > >> >>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>> sponsor for >>>> >>> that. But at this stage I don't think I agree with the >>>> proposed change >>>> >>> because of the change in behaviour - there's no way to restore >>>> the >>>> >>> "broken" behaviour. >>>> >>> > >> >>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 [1]. >>>> >>> > >> >>>> >>> > >> Okay we can do that. >>>> >>> > >> >>>> >>> > >>> >>>> >>> > >>>> Further, we expect the launcher to use the supported JNI >>>> >>> interface (as >>>> >>> > >>>> other processes would), not the internal JVM interface >>>> that >>>> >>> exists for >>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>> >>> > >>> >>>> >>> > >>> I think that we do not use JVM interface if we add new >>>> method in >>>> >>> > >>> LauncherHelper as below: >>>> >>> > >>> ---------------- >>>> >>> > >>> diff -r f02139a1ac84 >>>> >>> > >>> >>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> >>> > >>> --- >>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>> >>> > >>> +++ >>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>> >>> > >>> @@ -960,4 +960,8 @@ >>>> >>> > >>> else >>>> >>> > >>> return md.toNameAndVersion() + " (" + loc >>>> + ")"; >>>> >>> > >>> } >>>> >>> > >>> + >>>> >>> > >>> + static void setNativeThreadName(String name) { >>>> >>> > >>> + Thread.currentThread().setName(name); >>>> >>> > >>> + } >>>> >>> > >> >>>> >>> > >> You could also make that call via JNI directly, so not >>>> sure the >>>> >>> helper adds much here. But it won't work unless you change the >>>> semantics >>>> >>> of setName so I'm not sure what you were thinking here. To take >>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>> need to >>>> call >>>> >>> it directly as no Java code will call it . ??? >>>> >>> > >> >>>> >>> > >> David >>>> >>> > >> ----- >>>> >>> > >> >>>> >>> > >>> } >>>> >>> > >>> diff -r f02139a1ac84 >>>> src/java.base/share/native/libjli/java.c >>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>>> Apr 13 >>>> 14:19:30 >>>> >>> > >>> 2016 +0000 >>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>>> Apr 16 >>>> 11:25:53 >>>> >>> > >>> 2016 +0900 >>>> >>> > >>> @@ -125,6 +125,7 @@ >>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>>> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>> >>> > >>> >>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>> >>> > >>> >>>> >>> > >>> @@ -325,6 +326,7 @@ >>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>> >>> > >>> */ >>>> >>> > >>> #define LEAVE() \ >>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>> >>> > >>> do { \ >>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>> >>> > >>> @@ -488,6 +490,9 @@ >>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>> >>> > >>> >>>> >>> > >>> + /* Set native thread name. */ >>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>> >>> > >>> + >>>> >>> > >>> /* Invoke main method. */ >>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>> mainArgs); >>>> >>> > >>> >>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>> >>> > >>> joptString); >>>> >>> > >>> } >>>> >>> > >>> >>>> >>> > >>> +/** >>>> >>> > >>> + * Set native thread name as possible. >>>> >>> > >>> + */ >>>> >>> > >>> +static void >>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>> >>> > >>> +{ >>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>> >>> > >>> + jstring nameString; >>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>> >>> > >>> + NULL_CHECK(cls); >>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>> >>> (*env)->GetStaticMethodID(env, cls, >>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>> name)); >>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>> setNativeThreadNameID, >>>> >>> > >>> nameString); >>>> >>> > >>> +} >>>> >>> > >>> + >>>> >>> > >>> /* >>>> >>> > >>> * Prints default usage or the Xusage message, see >>>> >>> > >>> sun.launcher.LauncherHelper.java >>>> >>> > >>> */ >>>> >>> > >>> ---------------- >>>> >>> > >>> >>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>> >>> > >>> >>>> >>> > >>>> However this is still a change to the exported JVM >>>> interface and so >>>> >>> > >>>> has to be approved. >>>> >>> > >>> >>>> >>> > >>> Do you mean that this change needs CCC? >>>> >>> > >>> >>>> >>> > >>> >>>> >>> > >>> Thanks, >>>> >>> > >>> >>>> >>> > >>> Yasumasa >>>> >>> > >>> >>>> >>> > >>> >>>> >>> > >>> [1] >>>> >>> > >>> >>>> >>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>> >>>> >>> > >>> >>>> >>> > >>> >>>> >>> > >>> >>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>> >>> > >>>>> Hi David, >>>> >>> > >>>>> >>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>> >>> > >>>>>> >>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>> for main >>>> >>> thread and >>>> >>> > >>>>>> JNI attached threads >>>> >>> > >>>>> >>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>> >>> > >>>>> >>>> >>> > >>>>> >>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>> itself as >>>> >>> setName >>>> >>> > >>>>>> will no longer set the native name for the main thread. >>>> >>> > >>>>> >>>> >>> > >>>>> I know. >>>> >>> > >>>> >>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>> considered a >>>> >>> > >>>> regression that setName stops setting the native thread >>>> main, even >>>> >>> > >>>> though we never really intended it to work in the >>>> first place. >>>> >>> :( Such >>>> >>> > >>>> a change needs to go through CCC. >>>> >>> > >>>> >>>> >>> > >>>>> I checked changeset history. >>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, >>>> and it is >>>> >>> > >>>>> backported JDK 8. >>>> >>> > >>>> >>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>> >>> > >>>> >>>> >>> > >>>>> However, this function seems to be called from >>>> >>> Thread#setNativeName() >>>> >>> > >>>>> only. >>>> >>> > >>>>> In addition, Thread#setNativeName() is private method. >>>> >>> > >>>>> >>>> >>> > >>>>> Thus I think that we can add an argument to >>>> >>> JVM_SetNativeThreadName() >>>> >>> > >>>>> for force setting. >>>> >>> > >>>>> (e.g. "bool forced") >>>> >>> > >>>>> >>>> >>> > >>>>> It makes a change of JVM API. >>>> >>> > >>>>> However, this function is NOT public, so I think we can >>>> add one >>>> >>> more >>>> >>> > >>>>> argument. >>>> >>> > >>>>> >>>> >>> > >>>>> What do you think about this? >>>> >>> > >>>>> If it is accepted, we can set native thread name from >>>> Java >>>> >>> launcher. >>>> >>> > >>>> >>>> >>> > >>>> The private/public aspect of the Java API is not >>>> really at >>>> >>> issue. Yes >>>> >>> > >>>> we would add another arg to the JVM function to allow >>>> it to >>>> apply to >>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>> reflect that >>>> >>> not just >>>> >>> > >>>> "force"). However this is still a change to the >>>> exported JVM >>>> >>> interface >>>> >>> > >>>> and so has to be approved. Further, we expect the >>>> launcher to >>>> >>> use the >>>> >>> > >>>> supported JNI interface (as other processes would), >>>> not the >>>> internal >>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>> communicate >>>> >>> with the >>>> >>> > >>>> JVM. >>>> >>> > >>>> >>>> >>> > >>>> David >>>> >>> > >>>> ----- >>>> >>> > >>>> >>>> >>> > >>>>> >>>> >>> > >>>>> Thanks, >>>> >>> > >>>>> >>>> >>> > >>>>> Yasumasa >>>> >>> > >>>>> >>>> >>> > >>>>> >>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>> >>> > >>>>>> Hi Yasumasa, >>>> >>> > >>>>>> >>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>> Hi David, >>>> >>> > >>>>>>> >>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>>> being a >>>> >>> JNI-attached >>>> >>> > >>>>>>>> thread seems accidental to me >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> Should I file it to JBS? >>>> >>> > >>>>>> >>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>> >>> > >>>>>> >>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>> for main >>>> >>> thread and >>>> >>> > >>>>>> JNI attached threads >>>> >>> > >>>>>> >>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>> itself as >>>> >>> setName >>>> >>> > >>>>>> will no longer set the native name for the main thread. >>>> >>> > >>>>>> >>>> >>> > >>>>>>> I think that we can fix as below: >>>> >>> > >>>>>>> --------------- >>>> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 >>>> 13:31:11 >>>> >>> 2016 +0200 >>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 >>>> 17:50:10 >>>> >>> 2016 +0900 >>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>> >>> > >>>>>>> // must do this before set_active_handles >>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization is >>>> complete >>>> >>> - nop if >>>> >>> > >>>>>>> no agents. >>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> + // Change attach status to "attached" >>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>> >>> > >>>>>>> + >>>> >>> > >>>>>> >>>> >>> > >>>>>> I think we can do this straight after the JavaThread >>>> constructor. >>>> >>> > >>>>>> >>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start tracing >>>> >>> > >>>>>>> backend."); >>>> >>> > >>>>>>> } >>>> >>> > >>>>>>> --------------- >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> >>>> >>> > >>>>>>>> If it wants to name its native threads then it is >>>> free >>>> to do so, >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change >>>> native >>>> >>> thread name >>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>> >>> > >>>>>>> However, I think that it should be changed if Java >>>> developer >>>> >>> calls >>>> >>> > >>>>>>> Thread#setName() explicitly. >>>> >>> > >>>>>>> It is not the same of changing native thread name at >>>> >>> > >>>>>>> Threads::create_vm(). >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> If it is allowed, I want to fix >>>> SetNativeThreadName() as >>>> below. >>>> >>> > >>>>>>> What do you think about this? >>>> >>> > >>>>>> >>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>> threads was a >>>> >>> > >>>>>> deliberate one** - this functionality originated >>>> with the OSX >>>> >>> port and >>>> >>> > >>>>>> it was reported that the initial feedback with this >>>> feature was to >>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>> been set by >>>> >>> the host >>>> >>> > >>>>>> process. If we do as you propose then we will just >>>> have an >>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>> does my >>>> >>> native thread >>>> >>> > >>>>>> only have a name if I call >>>> cur.setName(cur.getName()) ?" >>>> >>> > >>>>>> >>>> >>> > >>>>>> ** If you follow the bugs and related discussions on >>>> this, the >>>> >>> > >>>>>> semantics and limitations (truncation, current >>>> thread only, >>>> >>> non-JNI >>>> >>> > >>>>>> threads only) of setting the native thread name were >>>> supposed >>>> >>> to be >>>> >>> > >>>>>> documented in the release notes - but as far as I >>>> can see >>>> that >>>> >>> never >>>> >>> > >>>>>> happened. :( >>>> >>> > >>>>>> >>>> >>> > >>>>>> My position on this remains that if it is desirable for >>>> the main >>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native names >>>> then the >>>> >>> > >>>>>> launcher needs to be setting them using the available >>>> platform >>>> >>> APIs. >>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by >>>> the VM >>>> >>> code for >>>> >>> > >>>>>> this - due to the need to verify API availability. >>>> >>> > >>>>>> >>>> >>> > >>>>>> Any change in behaviour in relation to >>>> Thread.setName would >>>> >>> have to go >>>> >>> > >>>>>> through our CCC process I think. But a change in the >>>> launcher >>>> >>> would >>>> >>> > >>>>>> not. >>>> >>> > >>>>>> >>>> >>> > >>>>>> Sorry. >>>> >>> > >>>>>> >>>> >>> > >>>>>> David >>>> >>> > >>>>>> ----- >>>> >>> > >>>>>> >>>> >>> > >>>>>>> --------------- >>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 >>>> 13:31:11 >>>> >>> 2016 +0200 >>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 >>>> 17:50:10 >>>> >>> 2016 +0900 >>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>> >>> > >>>>>>> JavaThread* thr = >>>> java_lang_Thread::thread(java_thread); >>>> >>> > >>>>>>> // Thread naming only supported for the current >>>> thread, >>>> >>> doesn't >>>> >>> > >>>>>>> work >>>> >>> > >>>>>>> for >>>> >>> > >>>>>>> // target threads. >>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>> >>> !thr->has_attached_via_jni()) { >>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>> >>> > >>>>>>> // we don't set the name of an attached thread >>>> to avoid >>>> >>> stepping >>>> >>> > >>>>>>> // on other programs >>>> >>> > >>>>>>> const char *thread_name = >>>> >>> > >>>>>>> >>>> >>> >>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>> >>> > >>>>>>> --------------- >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> Thanks, >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> Yasumasa >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>> Roger, >>>> >>> > >>>>>>>>> Thanks for your comment! >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> David, >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>> don't like >>>> >>> > >>>>>>>>>>>> exposing >>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>> initializing VM >>>> (before >>>> >>> > >>>>>>>>> calling >>>> >>> > >>>>>>>>> main method), >>>> >>> > >>>>>>>>> I could set native thread name. >>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>> AttachCurrentThread(). >>>> So we >>>> >>> can't >>>> >>> > >>>>>>>>> set >>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> Right - I came to the same realization earlier this >>>> morning. >>>> >>> Which, >>>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise >>>> here that >>>> >>> we don't >>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>> The fact >>>> >>> that the >>>> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >>>> thread seems >>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only >>>> working by >>>> >>> > >>>>>>>> accident for the initial attach, and can't be used >>>> for the >>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>> inconsistently >>>> >>> named at >>>> >>> > >>>>>>>> the native level. >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has >>>> to be >>>> >>> treated like >>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>> wants to >>>> name its >>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>> would not be >>>> >>> exporting >>>> >>> > >>>>>>>> a function from the JVM to do that - it would have to >>>> use the OS >>>> >>> > >>>>>>>> specific API's for that on a platform-by-platform >>>> basis. >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> Sorry. >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> David >>>> >>> > >>>>>>>> ----- >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> Thanks, >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>> >>> > >>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> Comments: >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>>> perform >>>> >>> different >>>> >>> > >>>>>>>>>> functions: >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>> JVM_SetNativeThreadName >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> - The first function applies to the current >>>> thread, the >>>> >>> second >>>> >>> > >>>>>>>>>> one a >>>> >>> > >>>>>>>>>> specific java thread. >>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>>> somewhere >>>> >>> about >>>> >>> > >>>>>>>>>> what >>>> >>> > >>>>>>>>>> the new function does. >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to >>>> (void*) >>>> >>> > >>>>>>>>>> instead of >>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>> overwriteifn->GetCreatedJavaVMs >>>> >>> used at >>>> >>> > >>>>>>>>>> line 730 >>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>>> the cast >>>> >>> on the >>>> >>> > >>>>>>>>>> same >>>> >>> > >>>>>>>>>> line as dlsym... >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> $.02, Roger >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>> haven't had >>>> time to >>>> >>> > >>>>>>>>>>>> check - >>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>> JNI-attached >>>> >>> thread >>>> >>> > >>>>>>>>>>>> then >>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>> suggestion >>>> >>> should >>>> >>> > >>>>>>>>>>>> work >>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>> treatment of >>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >>>> confirmed >>>> >>> native >>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>> >>> > >>>>>>>>>>> --------- >>>> >>> > >>>>>>>>>>> public class Sleep{ >>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>> Exception{ >>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>> >>> > >>>>>>>>>>> } >>>> >>> > >>>>>>>>>>> } >>>> >>> > >>>>>>>>>>> --------- >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>> don't like >>>> >>> > >>>>>>>>>>>> exposing >>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>> comment. >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>> >>> > >>>>>>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>>> thread >>>> >>> name, and JLI >>>> >>> > >>>>>>>>>>>>>>> uses it >>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>> >>> > >>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>>> >>> core-libs will >>>> >>> > >>>>>>>>>>>>>> need to >>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - >>>> now cc'd. >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> Thanks! >>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>> >>> Thread.setName >>>> >>> > >>>>>>>>>>>>>> rather >>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>> hotspot changes >>>> >>> > >>>>>>>>>>>>>> needed in >>>> >>> > >>>>>>>>>>>>>> that case. >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>> Thread#setName() in >>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>>> which is >>>> >>> why the >>>> >>> > >>>>>>>>>>>> native >>>> >>> > >>>>>>>>>>>> name is not set. >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI attached >>>> thread. >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>> haven't had >>>> time to >>>> >>> > >>>>>>>>>>>> check - >>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>> JNI-attached >>>> >>> thread >>>> >>> > >>>>>>>>>>>> then >>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>> suggestion >>>> >>> should >>>> >>> > >>>>>>>>>>>> work >>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>> treatment of >>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>> don't like >>>> >>> > >>>>>>>>>>>> exposing >>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>> David >>>> >>> > >>>>>>>>>>>> ----- >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>> function to set >>>> >>> native >>>> >>> > >>>>>>>>>>>>> thread name. >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> [1] >>>> >>> > >>>>>>>>>>>>> >>>> >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>>> David >>>> >>> > >>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>> well ... >>>> >>> > >>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>> >>> > >>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have >>>> been on >>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>> >>> > >>>>>>>>>>>>>>>> This >>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>> correct >>>> as we >>>> >>> do not >>>> >>> > >>>>>>>>>>>>>>>> set the >>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >>>> includes the >>>> >>> > >>>>>>>>>>>>>>>> "main" >>>> >>> > >>>>>>>>>>>>>>>> thread. >>>> >>> > >>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>> David >>>> >>> > >>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>> wrote: >>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>> >>> > >>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>> >>> > >>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>> >>>> >>> >>: >>>> >>> > >>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>> >>> > >>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>> >>> > >>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>> >>> > >>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>> Suenaga wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga >>>> wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>> >>> >>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>>> >>> >>>: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>> Suenaga wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>>> >>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>>> >>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>>> >>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>>> >>> >>>>: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set >>>> it: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>> a/src/share/vm/runtime/thread.cpp Thu >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>> b/src/share/vm/runtime/thread.cpp Thu >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>> >>> JavaThread(); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> main_thread->initialize_thread_current(); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>> >>> main_thread->set_native_thread_name("main"); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>> >>> set_active_handles >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> main_thread->record_stack_base_and_size(); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> >>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>> something? >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to >>>> thread >>>> >>> name in >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>> setName(). >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java >>>> app, >>>> native >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is >>>> already >>>> >>> starte >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >>>> thrrad name >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>> something like >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp >>>> Tue >>>> >>> Mar 29 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp >>>> Wed >>>> >>> Mar 30 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>> create_initial_thread(Handle >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>> initial_thread_name = >>>> >>> "main"; >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>> (THREAD, k); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> klass->allocate_instance_handle(CHECK_NULL); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> java_lang_Thread::set_thread(thread_oop(), >>>> >>> thread); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> java_lang_Thread::set_priority(thread_oop(), >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> java_lang_String::create_from_str("main", >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> thread->set_native_thread_name(initial_thread_name); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>> thread_oop, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself >>>> 'java' and >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>> process >>>> (and >>>> >>> thus >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>> process >>>> is not >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>> >>> JavaThread. So I >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>>> thread. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>> anyhow, since >>>> >>> we want >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread >>>> name >>>> might >>>> >>> have >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | >>>> head -4 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like >>>> 'Java Main >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java >>>> >>> launcher - e.g. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>> thread >>>> name, >>>> >>> I think >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa >>>> >>> Suenaga wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>>> thread >>>> >>> name via >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >>>> have it. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native >>>> name, >>>> and main >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >>>> should have >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you >>>> review it? >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>> >>>> >>> > >>>> >>> >>>> > From coleen.phillimore at oracle.com Fri Apr 22 17:57:16 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Apr 2016 13:57:16 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571A41D1.30707@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> Message-ID: <571A65FC.3060805@oracle.com> Great! Sounds good (better hurry, JPRT is going down at 3) Coleen On 4/22/16 11:22 AM, Rachel Protacio wrote: > Hi, Coleen, > > Thanks for the review! I'll remove the arrayKlass entries and, seeing > no other objections, will commit. > > Rachel > > On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >> >> Hi, >> >> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >> >> >> I don't think you need module or package declared in arrayKlass.hpp >> since it should be abstract also, ie. there should be no instances of >> ArrayKlass. >> >> Otherwise, looks great. I love seeing those InstanceKlass::casts go >> away. >> >> Coleen >> >> >> On 4/21/16 10:26 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review this fix for the package() and module() functions, >>>> making >>>> them pure virtual functions of Klass and implementing them in the >>>> relevant child classes. This cleans up some verbose and repetitive >>>> code >>>> that was casting and checking klass types. Also added test cases to >>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>> module() functions work as expected. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>> >>> The refactoring all looks good to me (though C++ annoys me in >>> needing to re-declare the functions in each subclass :) ). >>> >>> Cheers, >>> David >>> >>>> Tested with jtreg tests in jdk/test (java/lang, java/io, >>>> java/security, >>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >>>> hotspot and non-colo tests. >>>> >>>> Thanks! >>>> Rachel >> > From coleen.phillimore at oracle.com Fri Apr 22 17:58:40 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Apr 2016 13:58:40 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571A41D1.30707@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> Message-ID: <571A6650.8060003@oracle.com> Also, thank you for doing this cleanup. It's a lot nicer now. Coleen On 4/22/16 11:22 AM, Rachel Protacio wrote: > Hi, Coleen, > > Thanks for the review! I'll remove the arrayKlass entries and, seeing > no other objections, will commit. > > Rachel > > On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >> >> Hi, >> >> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >> >> >> I don't think you need module or package declared in arrayKlass.hpp >> since it should be abstract also, ie. there should be no instances of >> ArrayKlass. >> >> Otherwise, looks great. I love seeing those InstanceKlass::casts go >> away. >> >> Coleen >> >> >> On 4/21/16 10:26 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review this fix for the package() and module() functions, >>>> making >>>> them pure virtual functions of Klass and implementing them in the >>>> relevant child classes. This cleans up some verbose and repetitive >>>> code >>>> that was casting and checking klass types. Also added test cases to >>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>> module() functions work as expected. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>> >>> The refactoring all looks good to me (though C++ annoys me in >>> needing to re-declare the functions in each subclass :) ). >>> >>> Cheers, >>> David >>> >>>> Tested with jtreg tests in jdk/test (java/lang, java/io, >>>> java/security, >>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >>>> hotspot and non-colo tests. >>>> >>>> Thanks! >>>> Rachel >> > From daniel.daugherty at oracle.com Fri Apr 22 18:01:36 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 22 Apr 2016 12:01:36 -0600 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571A65FC.3060805@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> <571A65FC.3060805@oracle.com> Message-ID: <571A6700.7070602@oracle.com> There's less than one hour before JPRT goes off the air. Even with an empty queue, it's hard to get a job through in < 60 minutes... and the queue is not empty... :-( Dan On 4/22/16 11:57 AM, Coleen Phillimore wrote: > > Great! Sounds good (better hurry, JPRT is going down at 3) > Coleen > > On 4/22/16 11:22 AM, Rachel Protacio wrote: >> Hi, Coleen, >> >> Thanks for the review! I'll remove the arrayKlass entries and, seeing >> no other objections, will commit. >> >> Rachel >> >> On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >>> >>> Hi, >>> >>> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >>> >>> >>> I don't think you need module or package declared in arrayKlass.hpp >>> since it should be abstract also, ie. there should be no instances >>> of ArrayKlass. >>> >>> Otherwise, looks great. I love seeing those InstanceKlass::casts go >>> away. >>> >>> Coleen >>> >>> >>> On 4/21/16 10:26 PM, David Holmes wrote: >>>> Hi Rachel, >>>> >>>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>>> Hello, >>>>> >>>>> Please review this fix for the package() and module() functions, >>>>> making >>>>> them pure virtual functions of Klass and implementing them in the >>>>> relevant child classes. This cleans up some verbose and repetitive >>>>> code >>>>> that was casting and checking klass types. Also added test cases to >>>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>>> module() functions work as expected. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>>> >>>> The refactoring all looks good to me (though C++ annoys me in >>>> needing to re-declare the functions in each subclass :) ). >>>> >>>> Cheers, >>>> David >>>> >>>>> Tested with jtreg tests in jdk/test (java/lang, java/io, >>>>> java/security, >>>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >>>>> hotspot and non-colo tests. >>>>> >>>>> Thanks! >>>>> Rachel >>> >> > From goetz.lindenmaier at sap.com Fri Apr 22 20:40:22 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Apr 2016 20:40:22 +0000 Subject: RFR(S): 8154921: Fix aix after "8146879: Add option for handling existing log files in UL" In-Reply-To: <571A2658.3030202@oracle.com> References: <2e0e2e288163415fb4e1ddcb764c1434@DEWDFE13DE09.global.corp.sap> <571A2658.3030202@oracle.com> Message-ID: Hi Coleen, it's already in, thanks a lot! Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Coleen Phillimore > Sent: Friday, April 22, 2016 3:26 PM > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8154921: Fix aix after "8146879: Add option for handling > existing log files in UL" > > Looks good. I'll sponsor. I think it only needs one code review under > the "trivial" rule. > Coleen > > > On 4/22/16 9:17 AM, Lindenmaier, Goetz wrote: > > Hi > > > > 8146879 breaks the build on AIX, as stdio.h defines a macro fileno. > > I renamed os::fileno() to os::get_fileno(). > > > > Please review this small fix. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/wr16/8154921-aix_fileno/webrev.01/ > > > > Best regards, > > Goetz. From coleen.phillimore at oracle.com Fri Apr 22 20:54:41 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 22 Apr 2016 16:54:41 -0400 Subject: RFR(S): 8154921: Fix aix after "8146879: Add option for handling existing log files in UL" In-Reply-To: References: <2e0e2e288163415fb4e1ddcb764c1434@DEWDFE13DE09.global.corp.sap> <571A2658.3030202@oracle.com> Message-ID: <571A8F91.5080009@oracle.com> You are welcome - thanks for the fix. Coleen On 4/22/16 4:40 PM, Lindenmaier, Goetz wrote: > Hi Coleen, > > it's already in, thanks a lot! > > Best regards, > Goetz. > >> -----Original Message----- >> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- >> bounces at openjdk.java.net] On Behalf Of Coleen Phillimore >> Sent: Friday, April 22, 2016 3:26 PM >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(S): 8154921: Fix aix after "8146879: Add option for handling >> existing log files in UL" >> >> Looks good. I'll sponsor. I think it only needs one code review under >> the "trivial" rule. >> Coleen >> >> >> On 4/22/16 9:17 AM, Lindenmaier, Goetz wrote: >>> Hi >>> >>> 8146879 breaks the build on AIX, as stdio.h defines a macro fileno. >>> I renamed os::fileno() to os::get_fileno(). >>> >>> Please review this small fix. I please need a sponsor. >>> http://cr.openjdk.java.net/~goetz/wr16/8154921-aix_fileno/webrev.01/ >>> >>> Best regards, >>> Goetz. From calvin.cheung at oracle.com Fri Apr 22 21:18:45 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 22 Apr 2016 14:18:45 -0700 Subject: RFR(xs): 8152356: Change to -Xshare:auto for 32-bit platforms In-Reply-To: <5719D6A3.8070502@oracle.com> References: <5719CB6F.1080801@oracle.com> <5719D6A3.8070502@oracle.com> Message-ID: <571A9535.7040706@oracle.com> Hi David, Thanks for your review. On 4/22/16, 12:45 AM, David Holmes wrote: > Hi Calvin, > > On 22/04/2016 4:57 PM, Calvin Cheung wrote: >> >> Please review this small fix for enabling -Xshare:auto as the default >> for 32-bit platforms. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8152356 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8152356/webrev.00/ > > I find the selection logic for this to be almost unfathomable - and > made worse by the conditional compilation! But looking at your changes: > > -#if defined(COMPILER2) || INCLUDE_JVMCI || defined(_LP64) || > !INCLUDE_CDS > +#if INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS > > Ok - 64-bit implies compiler2 as we don't do 64-bit client, so this > reduction is fine. > > -#if defined(COMPILER2) || INCLUDE_JVMCI > +#if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI > > Ok - we're relaxing the constraint so that we skip this code block for > 32-bit compiler2. > > // Shared spaces work fine with other GCs but causes bytecode > rewriting > // to be disabled, which hurts interpreter performance and decreases > - // server performance. When -server is specified, keep the default > off > - // unless it is asked for. Future work: either add bytecode rewriting > - // at link time, or rewrite bytecodes in non-shared methods. > + // server performance. After JDK-8074345, bytecode rewriting is > enabled for > + // non-shared classes. So share spaces should no longer affect the > performance of > + // benchmarks executed by C2. Enabling the default (-Xshare:auto) > on 32-bit platforms when > + // -server is specified. When -server is specified on a 64-bit > platform, keep the default > + // off unless it is asked for. > > I'm not a fan of history lessons in comments - they tend to only make > sense at the time of writing. If the code works fine now then it works > fine now, we don't need to document that it didn't used to work fine > but bug XXX fixed it. I'd simplify the comment to just state what > exactly you are checking for, because to be honest I find this: > > if (!DumpSharedSpaces && !RequireSharedSpaces && > (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { > > very hard to unwravel. The first part is fine - not dumping. The > second part indicates we are either in -Xshare:off or -Xshare:auto. > But the third part is quite puzzling - and even when I think I have it > figured out I can't reconcile with what I see when I use > -XX:+PrintFlagsFinal. So the "what are we doing" is much more > important to comment than the history. How about the following? // skip the following block of code for 32-bit platforms #if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI // For 64-bit compiler2 (-server), keep the default sharing off unless // it is enabled via -Xshare:on. if (!DumpSharedSpaces && !RequireSharedSpaces && (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { no_shared_spaces("COMPILER2 default: -Xshare:auto | off, have to manually setup to on."); } #endif > > --- > > Query: In the tests, should they be @driver rather than @run ? I think you meant the following? @run driver From the jtreg documentation: > driver[/fail][/timeout=] * > Invoke the main method of the specified class, passing any arguments > after the class name. Although superficially similar to @run main, > this is for use when it is desirable to perform additional setup or > configuration before running the class containing the actual test > code, possibly in a child VM. > > The named will be compiled on demand, just as though an "@run > build " action had been inserted before this action. If this > action requires classes other than to be up to date, insert an > appropriate build action before this action. For the 2 tests in this change, there's no setup or configuration step required. So I think it is unnecessary to use "driver" action. I did try the 2 tests with the "driver" action and they worked as well. e.g. @run driver DefaultSharing Let me know if you want to see a new webrev with the changes above. thanks, Calvin > > Thanks, > David > >> Testing: >> JPRT >> jtreg tests under hotspot/test/runtime >> >> thanks, >> Calvin From jiangli.zhou at oracle.com Fri Apr 22 22:08:28 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 22 Apr 2016 15:08:28 -0700 Subject: RFR(xs): 8152356: Change to -Xshare:auto for 32-bit platforms In-Reply-To: <571A9535.7040706@oracle.com> References: <5719CB6F.1080801@oracle.com> <5719D6A3.8070502@oracle.com> <571A9535.7040706@oracle.com> Message-ID: Hi Calvin, Please see comments below. > On Apr 22, 2016, at 2:18 PM, Calvin Cheung wrote: > > Hi David, > > Thanks for your review. > > On 4/22/16, 12:45 AM, David Holmes wrote: >> Hi Calvin, >> >> On 22/04/2016 4:57 PM, Calvin Cheung wrote: >>> >>> Please review this small fix for enabling -Xshare:auto as the default >>> for 32-bit platforms. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8152356 >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8152356/webrev.00/ >> >> I find the selection logic for this to be almost unfathomable - and made worse by the conditional compilation! But looking at your changes: >> >> -#if defined(COMPILER2) || INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >> +#if INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >> >> Ok - 64-bit implies compiler2 as we don't do 64-bit client, so this reduction is fine. >> >> -#if defined(COMPILER2) || INCLUDE_JVMCI >> +#if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI >> >> Ok - we're relaxing the constraint so that we skip this code block for 32-bit compiler2. >> >> // Shared spaces work fine with other GCs but causes bytecode rewriting >> // to be disabled, which hurts interpreter performance and decreases >> - // server performance. When -server is specified, keep the default off >> - // unless it is asked for. Future work: either add bytecode rewriting >> - // at link time, or rewrite bytecodes in non-shared methods. >> + // server performance. After JDK-8074345, bytecode rewriting is enabled for >> + // non-shared classes. So share spaces should no longer affect the performance of >> + // benchmarks executed by C2. Enabling the default (-Xshare:auto) on 32-bit platforms when >> + // -server is specified. When -server is specified on a 64-bit platform, keep the default >> + // off unless it is asked for. >> >> I'm not a fan of history lessons in comments - they tend to only make sense at the time of writing. If the code works fine now then it works fine now, we don't need to document that it didn't used to work fine but bug XXX fixed it. I'd simplify the comment to just state what exactly you are checking for, because to be honest I find this: >> >> if (!DumpSharedSpaces && !RequireSharedSpaces && >> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >> >> very hard to unwravel. The first part is fine - not dumping. The second part indicates we are either in -Xshare:off or -Xshare:auto. But the third part is quite puzzling - and even when I think I have it figured out I can't reconcile with what I see when I use -XX:+PrintFlagsFinal. So the "what are we doing" is much more important to comment than the history. > How about the following? > > // skip the following block of code for 32-bit platforms > #if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI > // For 64-bit compiler2 (-server), keep the default sharing off unless > // it is enabled via -Xshare:on. > if (!DumpSharedSpaces && !RequireSharedSpaces && > (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { > no_shared_spaces("COMPILER2 default: -Xshare:auto | off, have to manually setup to on."); > } > #endif I felt the same as David when looking at the code. The above simplified comment looks better. However the comments only explain the selection logic for 64-bit server. It would be helpful to find out why -Xshare:auto is off by default with INCLUDE_JVMCI enabled as part of your exercise. Thanks, Jiangli >> >> --- >> >> Query: In the tests, should they be @driver rather than @run ? > I think you meant the following? > @run driver > > From the jtreg documentation: >> driver[/fail][/timeout=] * >> Invoke the main method of the specified class, passing any arguments after the class name. Although superficially similar to @run main, this is for use when it is desirable to perform additional setup or configuration before running the class containing the actual test code, possibly in a child VM. >> >> The named will be compiled on demand, just as though an "@run build " action had been inserted before this action. If this action requires classes other than to be up to date, insert an appropriate build action before this action. > > For the 2 tests in this change, there's no setup or configuration step required. > So I think it is unnecessary to use "driver" action. > > I did try the 2 tests with the "driver" action and they worked as well. > e.g. @run driver DefaultSharing > > Let me know if you want to see a new webrev with the changes above. > > thanks, > Calvin > >> >> Thanks, >> David >> >>> Testing: >>> JPRT >>> jtreg tests under hotspot/test/runtime >>> >>> thanks, >>> Calvin From christian.thalinger at oracle.com Fri Apr 22 22:16:00 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 22 Apr 2016 12:16:00 -1000 Subject: RFR(xs): 8152356: Change to -Xshare:auto for 32-bit platforms In-Reply-To: References: <5719CB6F.1080801@oracle.com> <5719D6A3.8070502@oracle.com> <571A9535.7040706@oracle.com> Message-ID: > On Apr 22, 2016, at 12:08 PM, Jiangli Zhou wrote: > > Hi Calvin, > > Please see comments below. > >> On Apr 22, 2016, at 2:18 PM, Calvin Cheung wrote: >> >> Hi David, >> >> Thanks for your review. >> >> On 4/22/16, 12:45 AM, David Holmes wrote: >>> Hi Calvin, >>> >>> On 22/04/2016 4:57 PM, Calvin Cheung wrote: >>>> >>>> Please review this small fix for enabling -Xshare:auto as the default >>>> for 32-bit platforms. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8152356 >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8152356/webrev.00/ >>> >>> I find the selection logic for this to be almost unfathomable - and made worse by the conditional compilation! But looking at your changes: >>> >>> -#if defined(COMPILER2) || INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >>> +#if INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >>> >>> Ok - 64-bit implies compiler2 as we don't do 64-bit client, so this reduction is fine. >>> >>> -#if defined(COMPILER2) || INCLUDE_JVMCI >>> +#if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI >>> >>> Ok - we're relaxing the constraint so that we skip this code block for 32-bit compiler2. >>> >>> // Shared spaces work fine with other GCs but causes bytecode rewriting >>> // to be disabled, which hurts interpreter performance and decreases >>> - // server performance. When -server is specified, keep the default off >>> - // unless it is asked for. Future work: either add bytecode rewriting >>> - // at link time, or rewrite bytecodes in non-shared methods. >>> + // server performance. After JDK-8074345, bytecode rewriting is enabled for >>> + // non-shared classes. So share spaces should no longer affect the performance of >>> + // benchmarks executed by C2. Enabling the default (-Xshare:auto) on 32-bit platforms when >>> + // -server is specified. When -server is specified on a 64-bit platform, keep the default >>> + // off unless it is asked for. >>> >>> I'm not a fan of history lessons in comments - they tend to only make sense at the time of writing. If the code works fine now then it works fine now, we don't need to document that it didn't used to work fine but bug XXX fixed it. I'd simplify the comment to just state what exactly you are checking for, because to be honest I find this: >>> >>> if (!DumpSharedSpaces && !RequireSharedSpaces && >>> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >>> >>> very hard to unwravel. The first part is fine - not dumping. The second part indicates we are either in -Xshare:off or -Xshare:auto. But the third part is quite puzzling - and even when I think I have it figured out I can't reconcile with what I see when I use -XX:+PrintFlagsFinal. So the "what are we doing" is much more important to comment than the history. >> How about the following? >> >> // skip the following block of code for 32-bit platforms >> #if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI >> // For 64-bit compiler2 (-server), keep the default sharing off unless >> // it is enabled via -Xshare:on. >> if (!DumpSharedSpaces && !RequireSharedSpaces && >> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >> no_shared_spaces("COMPILER2 default: -Xshare:auto | off, have to manually setup to on."); >> } >> #endif > > I felt the same as David when looking at the code. The above simplified comment looks better. However the comments only explain the selection logic for 64-bit server. It would be helpful to find out why -Xshare:auto is off by default with INCLUDE_JVMCI enabled as part of your exercise. There is no technical reason; INCLUDE_JVMCI was pretty much added everywhere where there is a #ifdef COMPILER2. > > Thanks, > > Jiangli > >>> >>> --- >>> >>> Query: In the tests, should they be @driver rather than @run ? >> I think you meant the following? >> @run driver >> >> From the jtreg documentation: >>> driver[/fail][/timeout=] * >>> Invoke the main method of the specified class, passing any arguments after the class name. Although superficially similar to @run main, this is for use when it is desirable to perform additional setup or configuration before running the class containing the actual test code, possibly in a child VM. >>> >>> The named will be compiled on demand, just as though an "@run build " action had been inserted before this action. If this action requires classes other than to be up to date, insert an appropriate build action before this action. >> >> For the 2 tests in this change, there's no setup or configuration step required. >> So I think it is unnecessary to use "driver" action. >> >> I did try the 2 tests with the "driver" action and they worked as well. >> e.g. @run driver DefaultSharing >> >> Let me know if you want to see a new webrev with the changes above. >> >> thanks, >> Calvin >> >>> >>> Thanks, >>> David >>> >>>> Testing: >>>> JPRT >>>> jtreg tests under hotspot/test/runtime >>>> >>>> thanks, >>>> Calvin From vladimir.kozlov at oracle.com Fri Apr 22 23:17:21 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Apr 2016 16:17:21 -0700 Subject: RFR(xs): 8152356: Change to -Xshare:auto for 32-bit platforms In-Reply-To: References: <5719CB6F.1080801@oracle.com> <5719D6A3.8070502@oracle.com> <571A9535.7040706@oracle.com> Message-ID: <4347ebd8-cfcf-5e41-55cf-9f9512f24073@oracle.com> >> However the comments only explain the selection logic for 64-bit server. It would be helpful to find out why -Xshare:auto is off by default with INCLUDE_JVMCI enabled as part of your exercise. > > There is no technical reason; INCLUDE_JVMCI was pretty much added everywhere where there is a #ifdef COMPILER2. > Note, the only one current implementation of JVMCI compiler, Graal, is available only for 64-bit VM. I don't think it will change in a future. I would more expect that we will stop supporting 32-bit Server VM on all platforms (may be except embedded) in a very near future. The only 32-bit platforms with Server VM are Win7, Win8 and Ubuntu. Win10 has only 64-bit VM. Based on this I question the need for this change only for 32-bit VM. I would prefer to see it for all configurations. It will simplify #if conditions you complain about. Note, changing from Client VM to Server VM will have much high impact on user experience on 32-bit platforms than using or not using CDS. David said: "Just because -Xshare:auto is the default, it doesn't mean we have to generate an archive as part of the install process. That is an independent action/decision. This RFE is simply asking the question "if there exists an archive should we use it by default?"" If we do 64-bit too it will not change default behavior for 64-bit VM since by default there will be no CDS archive installed. And checking if archive exists is very cheap. If needed we can say in release document that we support it only on 32-bit VM in jdk 9 (as before). And lastly I agree with complains that current condition when it is enabled it very complicated. We should just enable it by default and done with it. Thanks, Vladimir On 4/22/16 3:16 PM, Christian Thalinger wrote: > >> On Apr 22, 2016, at 12:08 PM, Jiangli Zhou wrote: >> >> Hi Calvin, >> >> Please see comments below. >> >>> On Apr 22, 2016, at 2:18 PM, Calvin Cheung wrote: >>> >>> Hi David, >>> >>> Thanks for your review. >>> >>> On 4/22/16, 12:45 AM, David Holmes wrote: >>>> Hi Calvin, >>>> >>>> On 22/04/2016 4:57 PM, Calvin Cheung wrote: >>>>> >>>>> Please review this small fix for enabling -Xshare:auto as the default >>>>> for 32-bit platforms. >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8152356 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8152356/webrev.00/ >>>> >>>> I find the selection logic for this to be almost unfathomable - and made worse by the conditional compilation! But looking at your changes: >>>> >>>> -#if defined(COMPILER2) || INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >>>> +#if INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >>>> >>>> Ok - 64-bit implies compiler2 as we don't do 64-bit client, so this reduction is fine. >>>> >>>> -#if defined(COMPILER2) || INCLUDE_JVMCI >>>> +#if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI >>>> >>>> Ok - we're relaxing the constraint so that we skip this code block for 32-bit compiler2. >>>> >>>> // Shared spaces work fine with other GCs but causes bytecode rewriting >>>> // to be disabled, which hurts interpreter performance and decreases >>>> - // server performance. When -server is specified, keep the default off >>>> - // unless it is asked for. Future work: either add bytecode rewriting >>>> - // at link time, or rewrite bytecodes in non-shared methods. >>>> + // server performance. After JDK-8074345, bytecode rewriting is enabled for >>>> + // non-shared classes. So share spaces should no longer affect the performance of >>>> + // benchmarks executed by C2. Enabling the default (-Xshare:auto) on 32-bit platforms when >>>> + // -server is specified. When -server is specified on a 64-bit platform, keep the default >>>> + // off unless it is asked for. >>>> >>>> I'm not a fan of history lessons in comments - they tend to only make sense at the time of writing. If the code works fine now then it works fine now, we don't need to document that it didn't used to work fine but bug XXX fixed it. I'd simplify the comment to just state what exactly you are checking for, because to be honest I find this: >>>> >>>> if (!DumpSharedSpaces && !RequireSharedSpaces && >>>> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >>>> >>>> very hard to unwravel. The first part is fine - not dumping. The second part indicates we are either in -Xshare:off or -Xshare:auto. But the third part is quite puzzling - and even when I think I have it figured out I can't reconcile with what I see when I use -XX:+PrintFlagsFinal. So the "what are we doing" is much more important to comment than the history. >>> How about the following? >>> >>> // skip the following block of code for 32-bit platforms >>> #if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI >>> // For 64-bit compiler2 (-server), keep the default sharing off unless >>> // it is enabled via -Xshare:on. >>> if (!DumpSharedSpaces && !RequireSharedSpaces && >>> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >>> no_shared_spaces("COMPILER2 default: -Xshare:auto | off, have to manually setup to on."); >>> } >>> #endif >> >> I felt the same as David when looking at the code. The above simplified comment looks better. However the comments only explain the selection logic for 64-bit server. It would be helpful to find out why -Xshare:auto is off by default with INCLUDE_JVMCI enabled as part of your exercise. > > There is no technical reason; INCLUDE_JVMCI was pretty much added everywhere where there is a #ifdef COMPILER2. > >> >> Thanks, >> >> Jiangli >> >>>> >>>> --- >>>> >>>> Query: In the tests, should they be @driver rather than @run ? >>> I think you meant the following? >>> @run driver >>> >>> From the jtreg documentation: >>>> driver[/fail][/timeout=] * >>>> Invoke the main method of the specified class, passing any arguments after the class name. Although superficially similar to @run main, this is for use when it is desirable to perform additional setup or configuration before running the class containing the actual test code, possibly in a child VM. >>>> >>>> The named will be compiled on demand, just as though an "@run build " action had been inserted before this action. If this action requires classes other than to be up to date, insert an appropriate build action before this action. >>> >>> For the 2 tests in this change, there's no setup or configuration step required. >>> So I think it is unnecessary to use "driver" action. >>> >>> I did try the 2 tests with the "driver" action and they worked as well. >>> e.g. @run driver DefaultSharing >>> >>> Let me know if you want to see a new webrev with the changes above. >>> >>> thanks, >>> Calvin >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Testing: >>>>> JPRT >>>>> jtreg tests under hotspot/test/runtime >>>>> >>>>> thanks, >>>>> Calvin > From jiangli.zhou at oracle.com Sat Apr 23 00:18:11 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 22 Apr 2016 17:18:11 -0700 Subject: RFR(xs): 8152356: Change to -Xshare:auto for 32-bit platforms In-Reply-To: <4347ebd8-cfcf-5e41-55cf-9f9512f24073@oracle.com> References: <5719CB6F.1080801@oracle.com> <5719D6A3.8070502@oracle.com> <571A9535.7040706@oracle.com> <4347ebd8-cfcf-5e41-55cf-9f9512f24073@oracle.com> Message-ID: <6716B848-270C-4AF4-858F-8F1D22AA8C62@oracle.com> Christian, thank you for the information. It seems like INCLUD_JVMCI should be handled the same as COMPILER2 in this case. I agree with Vladimir?s view and prefer avoiding unnecessary complication. Thanks, Jiangli > On Apr 22, 2016, at 4:17 PM, Vladimir Kozlov wrote: > > >> However the comments only explain the selection logic for 64-bit server. It would be helpful to find out why -Xshare:auto is off by default with INCLUDE_JVMCI enabled as part of your exercise. > > > > There is no technical reason; INCLUDE_JVMCI was pretty much added everywhere where there is a #ifdef COMPILER2. > > > > Note, the only one current implementation of JVMCI compiler, Graal, is available only for 64-bit VM. I don't think it will change in a future. > > I would more expect that we will stop supporting 32-bit Server VM on all platforms (may be except embedded) in a very near future. The only 32-bit platforms with Server VM are Win7, Win8 and Ubuntu. Win10 has only 64-bit VM. > > Based on this I question the need for this change only for 32-bit VM. I would prefer to see it for all configurations. It will simplify #if conditions you complain about. > > Note, changing from Client VM to Server VM will have much high impact on user experience on 32-bit platforms than using or not using CDS. > > David said: "Just because -Xshare:auto is the default, it doesn't mean we have to generate an archive as part of the install process. That is an independent action/decision. This RFE is simply asking the question "if there exists an archive should we use it by default?"" > > If we do 64-bit too it will not change default behavior for 64-bit VM since by default there will be no CDS archive installed. And checking if archive exists is very cheap. If needed we can say in release document that we support it only on 32-bit VM in jdk 9 (as before). > > And lastly I agree with complains that current condition when it is enabled it very complicated. We should just enable it by default and done with it. > > Thanks, > Vladimir > > On 4/22/16 3:16 PM, Christian Thalinger wrote: >> >>> On Apr 22, 2016, at 12:08 PM, Jiangli Zhou wrote: >>> >>> Hi Calvin, >>> >>> Please see comments below. >>> >>>> On Apr 22, 2016, at 2:18 PM, Calvin Cheung wrote: >>>> >>>> Hi David, >>>> >>>> Thanks for your review. >>>> >>>> On 4/22/16, 12:45 AM, David Holmes wrote: >>>>> Hi Calvin, >>>>> >>>>> On 22/04/2016 4:57 PM, Calvin Cheung wrote: >>>>>> >>>>>> Please review this small fix for enabling -Xshare:auto as the default >>>>>> for 32-bit platforms. >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8152356 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8152356/webrev.00/ >>>>> >>>>> I find the selection logic for this to be almost unfathomable - and made worse by the conditional compilation! But looking at your changes: >>>>> >>>>> -#if defined(COMPILER2) || INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >>>>> +#if INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >>>>> >>>>> Ok - 64-bit implies compiler2 as we don't do 64-bit client, so this reduction is fine. >>>>> >>>>> -#if defined(COMPILER2) || INCLUDE_JVMCI >>>>> +#if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI >>>>> >>>>> Ok - we're relaxing the constraint so that we skip this code block for 32-bit compiler2. >>>>> >>>>> // Shared spaces work fine with other GCs but causes bytecode rewriting >>>>> // to be disabled, which hurts interpreter performance and decreases >>>>> - // server performance. When -server is specified, keep the default off >>>>> - // unless it is asked for. Future work: either add bytecode rewriting >>>>> - // at link time, or rewrite bytecodes in non-shared methods. >>>>> + // server performance. After JDK-8074345, bytecode rewriting is enabled for >>>>> + // non-shared classes. So share spaces should no longer affect the performance of >>>>> + // benchmarks executed by C2. Enabling the default (-Xshare:auto) on 32-bit platforms when >>>>> + // -server is specified. When -server is specified on a 64-bit platform, keep the default >>>>> + // off unless it is asked for. >>>>> >>>>> I'm not a fan of history lessons in comments - they tend to only make sense at the time of writing. If the code works fine now then it works fine now, we don't need to document that it didn't used to work fine but bug XXX fixed it. I'd simplify the comment to just state what exactly you are checking for, because to be honest I find this: >>>>> >>>>> if (!DumpSharedSpaces && !RequireSharedSpaces && >>>>> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >>>>> >>>>> very hard to unwravel. The first part is fine - not dumping. The second part indicates we are either in -Xshare:off or -Xshare:auto. But the third part is quite puzzling - and even when I think I have it figured out I can't reconcile with what I see when I use -XX:+PrintFlagsFinal. So the "what are we doing" is much more important to comment than the history. >>>> How about the following? >>>> >>>> // skip the following block of code for 32-bit platforms >>>> #if (defined(COMPILER2) && defined(_LP64)) || INCLUDE_JVMCI >>>> // For 64-bit compiler2 (-server), keep the default sharing off unless >>>> // it is enabled via -Xshare:on. >>>> if (!DumpSharedSpaces && !RequireSharedSpaces && >>>> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >>>> no_shared_spaces("COMPILER2 default: -Xshare:auto | off, have to manually setup to on."); >>>> } >>>> #endif >>> >>> I felt the same as David when looking at the code. The above simplified comment looks better. However the comments only explain the selection logic for 64-bit server. It would be helpful to find out why -Xshare:auto is off by default with INCLUDE_JVMCI enabled as part of your exercise. >> >> There is no technical reason; INCLUDE_JVMCI was pretty much added everywhere where there is a #ifdef COMPILER2. >> >>> >>> Thanks, >>> >>> Jiangli >>> >>>>> >>>>> --- >>>>> >>>>> Query: In the tests, should they be @driver rather than @run ? >>>> I think you meant the following? >>>> @run driver >>>> >>>> From the jtreg documentation: >>>>> driver[/fail][/timeout=] * >>>>> Invoke the main method of the specified class, passing any arguments after the class name. Although superficially similar to @run main, this is for use when it is desirable to perform additional setup or configuration before running the class containing the actual test code, possibly in a child VM. >>>>> >>>>> The named will be compiled on demand, just as though an "@run build " action had been inserted before this action. If this action requires classes other than to be up to date, insert an appropriate build action before this action. >>>> >>>> For the 2 tests in this change, there's no setup or configuration step required. >>>> So I think it is unnecessary to use "driver" action. >>>> >>>> I did try the 2 tests with the "driver" action and they worked as well. >>>> e.g. @run driver DefaultSharing >>>> >>>> Let me know if you want to see a new webrev with the changes above. >>>> >>>> thanks, >>>> Calvin >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Testing: >>>>>> JPRT >>>>>> jtreg tests under hotspot/test/runtime >>>>>> >>>>>> thanks, >>>>>> Calvin >> From yasuenag at gmail.com Sat Apr 23 13:24:38 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 23 Apr 2016 22:24:38 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571A4DE8.8060508@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> Message-ID: <571B7796.8030905@gmail.com> Hi Kumar, Thank you for your comment! I've fixed them and uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ Thanks, Yasumasa On 2016/04/23 1:14, Kumar Srinivasan wrote: > > Also a couple of minor suggestions: > > - * Set native thread name as possible. > + * Set native thread name if possible. > > > + /* > - * We can clear pending exception because exception at this point > - * is not critical. > + */ > > + /* > + * Clear non critical pending exceptions at this point. > + */ > > Thanks > Kumar > >> Hi, >> >> This is in the wrong place: >> >> 1715 if ((*env)->ExceptionOccurred(env)) { >> 1716 /* >> 1717 * We can clear pending exception because exception at this point >> 1718 * is not critical. >> 1719 */ >> 1720 (*env)->ExceptionClear(env); >> 1721 } >> >> This above needs to be after >> 391 SetNativeThreadName(env, "main"); >> 392 >> >> Here is why, supposing 1704 through 1711, returns a NULL, >> but have also encountered an exception. In which case >> the method SetNativeThreadName will return to the caller, as >> if nothing has happened, because NULL_CHECK simply checks for NULL >> and returns to the caller. This will cause the caller to enter >> the VM with exceptions. >> >> Kumar >> >> >> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> I don't think we need to report the exception, but can just ignore it. Either way we have to clear the exception before continuing. >>> >>> I've fixed it in new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/22 15:33, David Holmes wrote: >>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> I have uploaded webrev.04 as below. >>>>> Could you review again? >>>>> >>>>> > - hotspot: >>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>> >>>> Looks fine. >>>> >>>>> > >>>>> > - jdk: >>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>> >>>> As per private email (but repeated here on the record) in java.c: >>>> >>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>> 1716 JLI_ReportExceptionDescription(env); >>>> 1717 } >>>> >>>> I don't think we need to report the exception, but can just ignore it. Either way we have to clear the exception before continuing. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>> >: >>>>> > >>>>> > Hi David, >>>>> > >>>>> > Thank you for your comment. >>>>> > I uploaded new webrev. Could you review again? >>>>> > >>>>> > - hotspot: >>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>> > >>>>> > - jdk: >>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>> > >>>>> > >>>>> >> That aside I'm not sure why you do this so late in the process, I >>>>> would have done it immediately after here: >>>>> > >>>>> > >>>>> > I think that native thread name ("main") should be set just before >>>>> > main method call. >>>>> > However, main thread is already started, so I moved it as you suggested. >>>>> > >>>>> > >>>>> >> One thing I dislike about the current structure is that we have to >>>>> go from char* to java.lang.String to call setNativeName which then calls >>>>> JVM_SetNativeThreadName which converts the j.l.String back to a char* ! >>>>> > >>>>> > >>>>> > SoI proposed to export new JVM function to set native thread name with >>>>> > const char *. >>>>> > >>>>> > >>>>> > Thanks, >>>>> > >>>>> > Yasumasa >>>>> > >>>>> > >>>>> > >>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>> >> >>>>> >> Hi Yasumasa, >>>>> >> >>>>> >> Thanks for persevering with this to get it into the current form. >>>>> Sorry I haven't been able to do a detailed review until now. >>>>> >> >>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>> >>> >>>>> >>> Hi Gerard, >>>>> >>> >>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>> >>>>> >>> >>: >>>>> >>> > >>>>> >>> > hi Yasumasa, >>>>> >>> > >>>>> >>> > Nice work. I have 2 questions: >>>>> >>> > >>>>> >>> > ======== >>>>> >>> > File: java.c >>>>> >>> > >>>>> >>> > #1 Shouldn?t we be checking for ?(*env)->ExceptionOccurred(env)? >>>>> >>> after every single JNI call? In this example instead of NULL_CHECK, >>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>> >>> >>>>> >>> It is not critical if we encounter error at JNI function call because >>>>> >>> we cannot set native thread name only. >>>>> >>> So I think that we do not need to leave from launcher process. >>>>> >> >>>>> >> >>>>> >> I agree we do not need to abort if an exception occurs (and in fact >>>>> I don't think an exception is even possible from this code), but we >>>>> should ensure any pending exception is cleared before any futher JNI >>>>> calls might be made. Note that NULL_CHECK is already used extensively >>>>> throughout the launcher code - so if this usage is wrong then it is all >>>>> wrong! More on this code below ... >>>>> >> >>>>> >> Other comments: >>>>> >> >>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>> >> >>>>> >> Please add a comment to the method now that you removed the internal >>>>> comment: >>>>> >> >>>>> >> // Sets the native thread name for a JavaThread. If specifically >>>>> >> // requested JNI-attached threads can also have their native name set; >>>>> >> // otherwise we do not modify JNI-attached threads as it may interfere >>>>> >> // with the application that created them. >>>>> >> >>>>> >> --- >>>>> >> >>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>> >> >>>>> >> Please add the following comments: >>>>> >> >>>>> >> + // Don't modify JNI-attached threads >>>>> >> setNativeName(name, false); >>>>> >> >>>>> >> + // May be called directly via JNI or reflection (when permitted) to >>>>> >> + // allow JNI-attached threads to set their native name >>>>> >> private native void setNativeName(String name, boolean >>>>> allowAttachedThread); >>>>> >> >>>>> >> --- >>>>> >> >>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>> >> >>>>> >> 328 #define LEAVE() \ >>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>> >> >>>>> >> I was going to suggest this be set later, but realized we have to be >>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>> >> >>>>> >> + /* Set native thread name. */ >>>>> >> + SetNativeThreadName(env, "main"); >>>>> >> >>>>> >> The comment is redundant given the name of the method. That aside >>>>> I'm not sure why you do this so late in the process, I would have done >>>>> it immediately after here: >>>>> >> >>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>> >> 388 exit(1); >>>>> >> 389 } >>>>> >> + SetNativeThreadName(env, "main"); >>>>> >> >>>>> >> >>>>> >> + /** >>>>> >> + * Set native thread name as possible. >>>>> >> + */ >>>>> >> >>>>> >> Other than the as->if change I'm unclear where the "possible" bit >>>>> comes into play - why would it not be possible? >>>>> >> >>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >>>>> >> 1706 NULL_CHECK(currentThreadID = (*env)->GetStaticMethodID(env, >>>>> cls, >>>>> >> 1707 "currentThread", >>>>> "()Ljava/lang/Thread;")); >>>>> >> 1708 NULL_CHECK(currentThread = >>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>> >> 1709 currentThreadID)); >>>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, cls, >>>>> >> 1711 "setNativeName", >>>>> "(Ljava/lang/String;Z)V")); >>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, setNativeNameID, >>>>> >> 1714 nameString, JNI_TRUE); >>>>> >> >>>>> >> As above NULL_CHECK is fine here, but we should check for and clear >>>>> any pending exception after CallVoidMethod. >>>>> >> >>>>> >> One thing I dislike about the current structure is that we have to >>>>> go from char* to java.lang.String to call setNativeName which then calls >>>>> JVM_SetNativeThreadName which converts the j.l.String back to a char* ! >>>>> Overall I wonder about the affect on startup cost. But if there is an >>>>> issue we can revisit this. >>>>> >> >>>>> >> Thanks, >>>>> >> David >>>>> >> ----- >>>>> >> >>>>> >> >>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set native >>>>> thread >>>>> >>> name if possible.? not "Set native thread name as possible.?? >>>>> >>> >>>>> >>> Sorry for my bad English :-) >>>>> >>> >>>>> >>> Thanks, >>>>> >>> >>>>> >>> Yasumasa >>>>> >>> >>>>> >>> > cheers >>>>> >>> > >>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>> >>>>> >>> >> wrote: >>>>> >>> > > >>>>> >>> > > Hi David, >>>>> >>> > > >>>>> >>> > > I uploaded new webrev: >>>>> >>> > > >>>>> >>> > > - hotspot: >>>>> >>> > > >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>> >>> > > >>>>> >>> > > - jdk: >>>>> >>> > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>> >>> > > >>>>> >>> > > >>>>> >>> > >> it won't work unless you change the semantics of setName so I'm >>>>> >>> not sure what you were thinking here. To take advantage of an arg >>>>> taking >>>>> >>> JVM_SetNativThreadName you would need to call it directly as no Java >>>>> >>> code will call it . ??? >>>>> >>> > > >>>>> >>> > > I added a flag for setting native thread name to JNI-attached >>>>> thread. >>>>> >>> > > This change can set native thread name if main thread changes to >>>>> >>> JNI-attached thread. >>>>> >>> > > >>>>> >>> > > >>>>> >>> > > Thanks, >>>>> >>> > > >>>>> >>> > > Yasumasa >>>>> >>> > > >>>>> >>> > > >>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>> >>> > >>> Hi David, >>>>> >>> > >>> >>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>> considered a >>>>> >>> > >>>> regression that setName stops setting the native thread >>>>> main, even >>>>> >>> > >>>> though we never really intended it to work in the first place. >>>>> >>> :( Such >>>>> >>> > >>>> a change needs to go through CCC. >>>>> >>> > >>> >>>>> >>> > >>> I understood. >>>>> >>> > >>> Can I send CCC request? >>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>> >>> > >> >>>>> >>> > >> Sorry you can't file a CCC request, you would need a sponsor for >>>>> >>> that. But at this stage I don't think I agree with the proposed change >>>>> >>> because of the change in behaviour - there's no way to restore the >>>>> >>> "broken" behaviour. >>>>> >>> > >> >>>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 [1]. >>>>> >>> > >> >>>>> >>> > >> Okay we can do that. >>>>> >>> > >> >>>>> >>> > >>> >>>>> >>> > >>>> Further, we expect the launcher to use the supported JNI >>>>> >>> interface (as >>>>> >>> > >>>> other processes would), not the internal JVM interface that >>>>> >>> exists for >>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>> >>> > >>> >>>>> >>> > >>> I think that we do not use JVM interface if we add new method in >>>>> >>> > >>> LauncherHelper as below: >>>>> >>> > >>> ---------------- >>>>> >>> > >>> diff -r f02139a1ac84 >>>>> >>> > >>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>> >>> > >>> --- >>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>> >>> > >>> +++ >>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>> >>> > >>> else >>>>> >>> > >>> return md.toNameAndVersion() + " (" + loc + ")"; >>>>> >>> > >>> } >>>>> >>> > >>> + >>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>> >>> > >>> + } >>>>> >>> > >> >>>>> >>> > >> You could also make that call via JNI directly, so not sure the >>>>> >>> helper adds much here. But it won't work unless you change the >>>>> semantics >>>>> >>> of setName so I'm not sure what you were thinking here. To take >>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would need to >>>>> call >>>>> >>> it directly as no Java code will call it . ??? >>>>> >>> > >> >>>>> >>> > >> David >>>>> >>> > >> ----- >>>>> >>> > >> >>>>> >>> > >>> } >>>>> >>> > >>> diff -r f02139a1ac84 src/java.base/share/native/libjli/java.c >>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed Apr 13 >>>>> 14:19:30 >>>>> >>> > >>> 2016 +0000 >>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat Apr 16 >>>>> 11:25:53 >>>>> >>> > >>> 2016 +0900 >>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>>>> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>>> >>> > >>> >>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>> >>> > >>> >>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>> >>> > >>> */ >>>>> >>> > >>> #define LEAVE() \ >>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>> >>> > >>> do { \ >>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>> >>> > >>> >>>>> >>> > >>> + /* Set native thread name. */ >>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>> >>> > >>> + >>>>> >>> > >>> /* Invoke main method. */ >>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>> mainArgs); >>>>> >>> > >>> >>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>> >>> > >>> joptString); >>>>> >>> > >>> } >>>>> >>> > >>> >>>>> >>> > >>> +/** >>>>> >>> > >>> + * Set native thread name as possible. >>>>> >>> > >>> + */ >>>>> >>> > >>> +static void >>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>> >>> > >>> +{ >>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>> >>> > >>> + jstring nameString; >>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>> >>> > >>> + NULL_CHECK(cls); >>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>> setNativeThreadNameID, >>>>> >>> > >>> nameString); >>>>> >>> > >>> +} >>>>> >>> > >>> + >>>>> >>> > >>> /* >>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>> >>> > >>> */ >>>>> >>> > >>> ---------------- >>>>> >>> > >>> >>>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>> >>> > >>> >>>>> >>> > >>>> However this is still a change to the exported JVM >>>>> interface and so >>>>> >>> > >>>> has to be approved. >>>>> >>> > >>> >>>>> >>> > >>> Do you mean that this change needs CCC? >>>>> >>> > >>> >>>>> >>> > >>> >>>>> >>> > >>> Thanks, >>>>> >>> > >>> >>>>> >>> > >>> Yasumasa >>>>> >>> > >>> >>>>> >>> > >>> >>>>> >>> > >>> [1] >>>>> >>> > >>> >>>>> >>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>> >>> > >>> >>>>> >>> > >>> >>>>> >>> > >>> >>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>> >>> > >>>>> Hi David, >>>>> >>> > >>>>> >>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>> >>> thread and >>>>> >>> > >>>>>> JNI attached threads >>>>> >>> > >>>>> >>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>> >>> > >>>>> >>>>> >>> > >>>>> >>>>> >>> > >>>>>> Though that will introduce a change in behaviour by itself as >>>>> >>> setName >>>>> >>> > >>>>>> will no longer set the native name for the main thread. >>>>> >>> > >>>>> >>>>> >>> > >>>>> I know. >>>>> >>> > >>>> >>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>> considered a >>>>> >>> > >>>> regression that setName stops setting the native thread >>>>> main, even >>>>> >>> > >>>> though we never really intended it to work in the first place. >>>>> >>> :( Such >>>>> >>> > >>>> a change needs to go through CCC. >>>>> >>> > >>>> >>>>> >>> > >>>>> I checked changeset history. >>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, >>>>> and it is >>>>> >>> > >>>>> backported JDK 8. >>>>> >>> > >>>> >>>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>>> >>> > >>>> >>>>> >>> > >>>>> However, this function seems to be called from >>>>> >>> Thread#setNativeName() >>>>> >>> > >>>>> only. >>>>> >>> > >>>>> In addition, Thread#setNativeName() is private method. >>>>> >>> > >>>>> >>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>> >>> JVM_SetNativeThreadName() >>>>> >>> > >>>>> for force setting. >>>>> >>> > >>>>> (e.g. "bool forced") >>>>> >>> > >>>>> >>>>> >>> > >>>>> It makes a change of JVM API. >>>>> >>> > >>>>> However, this function is NOT public, so I think we can >>>>> add one >>>>> >>> more >>>>> >>> > >>>>> argument. >>>>> >>> > >>>>> >>>>> >>> > >>>>> What do you think about this? >>>>> >>> > >>>>> If it is accepted, we can set native thread name from Java >>>>> >>> launcher. >>>>> >>> > >>>> >>>>> >>> > >>>> The private/public aspect of the Java API is not really at >>>>> >>> issue. Yes >>>>> >>> > >>>> we would add another arg to the JVM function to allow it to >>>>> apply to >>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg reflect that >>>>> >>> not just >>>>> >>> > >>>> "force"). However this is still a change to the exported JVM >>>>> >>> interface >>>>> >>> > >>>> and so has to be approved. Further, we expect the launcher to >>>>> >>> use the >>>>> >>> > >>>> supported JNI interface (as other processes would), not the >>>>> internal >>>>> >>> > >>>> JVM interface that exists for the JDK sources to communicate >>>>> >>> with the >>>>> >>> > >>>> JVM. >>>>> >>> > >>>> >>>>> >>> > >>>> David >>>>> >>> > >>>> ----- >>>>> >>> > >>>> >>>>> >>> > >>>>> >>>>> >>> > >>>>> Thanks, >>>>> >>> > >>>>> >>>>> >>> > >>>>> Yasumasa >>>>> >>> > >>>>> >>>>> >>> > >>>>> >>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>> >>> > >>>>>> Hi Yasumasa, >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>> >>> > >>>>>>> Hi David, >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as being a >>>>> >>> JNI-attached >>>>> >>> > >>>>>>>> thread seems accidental to me >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> Should I file it to JBS? >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for main >>>>> >>> thread and >>>>> >>> > >>>>>> JNI attached threads >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> Though that will introduce a change in behaviour by itself as >>>>> >>> setName >>>>> >>> > >>>>>> will no longer set the native name for the main thread. >>>>> >>> > >>>>>> >>>>> >>> > >>>>>>> I think that we can fix as below: >>>>> >>> > >>>>>>> --------------- >>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 13:31:11 >>>>> >>> 2016 +0200 >>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 17:50:10 >>>>> >>> 2016 +0900 >>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization is complete >>>>> >>> - nop if >>>>> >>> > >>>>>>> no agents. >>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>> >>> > >>>>>>> + >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> I think we can do this straight after the JavaThread >>>>> constructor. >>>>> >>> > >>>>>> >>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start tracing >>>>> >>> > >>>>>>> backend."); >>>>> >>> > >>>>>>> } >>>>> >>> > >>>>>>> --------------- >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>>> If it wants to name its native threads then it is free >>>>> to do so, >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change native >>>>> >>> thread name >>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>> >>> > >>>>>>> However, I think that it should be changed if Java developer >>>>> >>> calls >>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>> >>> > >>>>>>> It is not the same of changing native thread name at >>>>> >>> > >>>>>>> Threads::create_vm(). >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> If it is allowed, I want to fix SetNativeThreadName() as >>>>> below. >>>>> >>> > >>>>>>> What do you think about this? >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>>> threads was a >>>>> >>> > >>>>>> deliberate one** - this functionality originated with the OSX >>>>> >>> port and >>>>> >>> > >>>>>> it was reported that the initial feedback with this >>>>> feature was to >>>>> >>> > >>>>>> ensure it didn't mess with thread names that had been set by >>>>> >>> the host >>>>> >>> > >>>>>> process. If we do as you propose then we will just have an >>>>> >>> > >>>>>> inconsistency for people to complain about: "why does my >>>>> >>> native thread >>>>> >>> > >>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> ** If you follow the bugs and related discussions on >>>>> this, the >>>>> >>> > >>>>>> semantics and limitations (truncation, current thread only, >>>>> >>> non-JNI >>>>> >>> > >>>>>> threads only) of setting the native thread name were supposed >>>>> >>> to be >>>>> >>> > >>>>>> documented in the release notes - but as far as I can see >>>>> that >>>>> >>> never >>>>> >>> > >>>>>> happened. :( >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> My position on this remains that if it is desirable for >>>>> the main >>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native names >>>>> then the >>>>> >>> > >>>>>> launcher needs to be setting them using the available >>>>> platform >>>>> >>> APIs. >>>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by the VM >>>>> >>> code for >>>>> >>> > >>>>>> this - due to the need to verify API availability. >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> Any change in behaviour in relation to Thread.setName would >>>>> >>> have to go >>>>> >>> > >>>>>> through our CCC process I think. But a change in the launcher >>>>> >>> would >>>>> >>> > >>>>>> not. >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> Sorry. >>>>> >>> > >>>>>> >>>>> >>> > >>>>>> David >>>>> >>> > >>>>>> ----- >>>>> >>> > >>>>>> >>>>> >>> > >>>>>>> --------------- >>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 13:31:11 >>>>> >>> 2016 +0200 >>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 17:50:10 >>>>> >>> 2016 +0900 >>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>> >>> > >>>>>>> JavaThread* thr = java_lang_Thread::thread(java_thread); >>>>> >>> > >>>>>>> // Thread naming only supported for the current thread, >>>>> >>> doesn't >>>>> >>> > >>>>>>> work >>>>> >>> > >>>>>>> for >>>>> >>> > >>>>>>> // target threads. >>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>> >>> !thr->has_attached_via_jni()) { >>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>> >>> > >>>>>>> // we don't set the name of an attached thread to avoid >>>>> >>> stepping >>>>> >>> > >>>>>>> // on other programs >>>>> >>> > >>>>>>> const char *thread_name = >>>>> >>> > >>>>>>> >>>>> >>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>> >>> > >>>>>>> --------------- >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> Thanks, >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> Yasumasa >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> >>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>> >>> > >>>>>>>> >>>>> >>> > >>>>>>>> >>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>> >>> > >>>>>>>>> Roger, >>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>> >>> > >>>>>>>>> >>>>> >>> > >>>>>>>>> David, >>>>> >>> > >>>>>>>>> >>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>>> don't like >>>>> >>> > >>>>>>>>>>>> exposing >>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>> >>> > >>>>>>>>> >>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after initializing VM >>>>> (before >>>>> >>> > >>>>>>>>> calling >>>>> >>> > >>>>>>>>> main method), >>>>> >>> > >>>>>>>>> I could set native thread name. >>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). >>>>> So we >>>>> >>> can't >>>>> >>> > >>>>>>>>> set >>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>> >>> > >>>>>>>> >>>>> >>> > >>>>>>>> Right - I came to the same realization earlier this >>>>> morning. >>>>> >>> Which, >>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise here that >>>>> >>> we don't >>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. The fact >>>>> >>> that the >>>>> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >>>>> thread seems >>>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only >>>>> working by >>>>> >>> > >>>>>>>> accident for the initial attach, and can't be used for the >>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread inconsistently >>>>> >>> named at >>>>> >>> > >>>>>>>> the native level. >>>>> >>> > >>>>>>>> >>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has to be >>>>> >>> treated like >>>>> >>> > >>>>>>>> any other process that might host a JVM. If it wants to >>>>> name its >>>>> >>> > >>>>>>>> native threads then it is free to do so, but I would not be >>>>> >>> exporting >>>>> >>> > >>>>>>>> a function from the JVM to do that - it would have to >>>>> use the OS >>>>> >>> > >>>>>>>> specific API's for that on a platform-by-platform basis. >>>>> >>> > >>>>>>>> >>>>> >>> > >>>>>>>> Sorry. >>>>> >>> > >>>>>>>> >>>>> >>> > >>>>>>>> David >>>>> >>> > >>>>>>>> ----- >>>>> >>> > >>>>>>>> >>>>> >>> > >>>>>>>> >>>>> >>> > >>>>>>>>> >>>>> >>> > >>>>>>>>> >>>>> >>> > >>>>>>>>> Thanks, >>>>> >>> > >>>>>>>>> >>>>> >>> > >>>>>>>>> Yasumasa >>>>> >>> > >>>>>>>>> >>>>> >>> > >>>>>>>>> >>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>> >>> > >>>>>>>>>> Hi, >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> Comments: >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but perform >>>>> >>> different >>>>> >>> > >>>>>>>>>> functions: >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> - The first function applies to the current thread, the >>>>> >>> second >>>>> >>> > >>>>>>>>>> one a >>>>> >>> > >>>>>>>>>> specific java thread. >>>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment somewhere >>>>> >>> about >>>>> >>> > >>>>>>>>>> what >>>>> >>> > >>>>>>>>>> the new function does. >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to >>>>> (void*) >>>>> >>> > >>>>>>>>>> instead of >>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>> >>> > >>>>>>>>>> - 737: looks wrong to overwriteifn->GetCreatedJavaVMs >>>>> >>> used at >>>>> >>> > >>>>>>>>>> line 730 >>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep the cast >>>>> >>> on the >>>>> >>> > >>>>>>>>>> same >>>>> >>> > >>>>>>>>>> line as dlsym... >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> $.02, Roger >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>> >>> > >>>>>>>>>>>> That is an interesting question which I haven't had >>>>> time to >>>>> >>> > >>>>>>>>>>>> check - >>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>>>> >>> thread >>>>> >>> > >>>>>>>>>>>> then >>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>> >>> should >>>>> >>> > >>>>>>>>>>>> work >>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>> treatment of >>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >>>>> confirmed >>>>> >>> native >>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>> >>> > >>>>>>>>>>> --------- >>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>>> Exception{ >>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>> >>> > >>>>>>>>>>> } >>>>> >>> > >>>>>>>>>>> } >>>>> >>> > >>>>>>>>>>> --------- >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>>> don't like >>>>> >>> > >>>>>>>>>>>> exposing >>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>> Thanks, >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>> Yasumasa >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>> >>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>> >>> > >>>>>>>>>>>>> Hi, >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>> >>> > >>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native thread >>>>> >>> name, and JLI >>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>> >>> > >>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>>>> >>> core-libs will >>>>> >>> > >>>>>>>>>>>>>> need to >>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - >>>>> now cc'd. >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>> >>> Thread.setName >>>>> >>> > >>>>>>>>>>>>>> rather >>>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>>> hotspot changes >>>>> >>> > >>>>>>>>>>>>>> needed in >>>>> >>> > >>>>>>>>>>>>>> that case. >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>> Thread#setName() in >>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>> >>> > >>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, which is >>>>> >>> why the >>>>> >>> > >>>>>>>>>>>> native >>>>> >>> > >>>>>>>>>>>> name is not set. >>>>> >>> > >>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI attached thread. >>>>> >>> > >>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>> That is an interesting question which I haven't had >>>>> time to >>>>> >>> > >>>>>>>>>>>> check - >>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a JNI-attached >>>>> >>> thread >>>>> >>> > >>>>>>>>>>>> then >>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my suggestion >>>>> >>> should >>>>> >>> > >>>>>>>>>>>> work >>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>> treatment of >>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>> >>> > >>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>>> don't like >>>>> >>> > >>>>>>>>>>>> exposing >>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>> >>> > >>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>> Thanks, >>>>> >>> > >>>>>>>>>>>> David >>>>> >>> > >>>>>>>>>>>> ----- >>>>> >>> > >>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a function to set >>>>> >>> native >>>>> >>> > >>>>>>>>>>>>> thread name. >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> [1] >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>> >>> > >>>>>>>>>>>>>> David >>>>> >>> > >>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as well ... >>>>> >>> > >>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>> >>> > >>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have >>>>> been on >>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>> >>> > >>>>>>>>>>>>>>>> This >>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct >>>>> as we >>>>> >>> do not >>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >>>>> includes the >>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>> >>> > >>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>> David >>>>> >>> > >>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>> >>> > >>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>> >>> > >>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>> >>>>> >>> >>: >>>>> >>> > >>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga wrote: >>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga >>>>> wrote: >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>> >>> >>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>> >>> >>>: >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>>> Suenaga wrote: >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>> >>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>> >>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>>>> >>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>>>> >>> >>>>: >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>>> >>> JavaThread(); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> main_thread->initialize_thread_current(); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>> >>> main_thread->set_native_thread_name("main"); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>> >>> set_active_handles >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> main_thread->record_stack_base_and_size(); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing something? >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to thread >>>>> >>> name in >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>>> setName(). >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, >>>>> native >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is already >>>>> >>> starte >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >>>>> thrrad name >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>> something like >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp >>>>> Tue >>>>> >>> Mar 29 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp >>>>> Wed >>>>> >>> Mar 30 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop create_initial_thread(Handle >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>> initial_thread_name = >>>>> >>> "main"; >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass (THREAD, k); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > java_lang_Thread::set_thread(thread_oop(), >>>>> >>> thread); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> java_lang_Thread::set_priority(thread_oop(), >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>>> thread_oop, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself >>>>> 'java' and >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process >>>>> (and >>>>> >>> thus >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process >>>>> is not >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>>> >>> JavaThread. So I >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main thread. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it anyhow, since >>>>> >>> we want >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name >>>>> might >>>>> >>> have >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | head -4 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like >>>>> 'Java Main >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java >>>>> >>> launcher - e.g. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread >>>>> name, >>>>> >>> I think >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa >>>>> >>> Suenaga wrote: >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set thread >>>>> >>> name via >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >>>>> have it. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, >>>>> and main >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >>>>> should have >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you >>>>> review it? >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>> > >>>>>>>>>> >>>>> >>> > >>>>> >>> >>>>> >> > From Alan.Bateman at oracle.com Sun Apr 24 08:22:25 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 24 Apr 2016 09:22:25 +0100 Subject: RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND In-Reply-To: <1A36919B-354F-43DA-9130-4156AADD001A@oracle.com> References: <1A36919B-354F-43DA-9130-4156AADD001A@oracle.com> Message-ID: <571C8241.5010905@oracle.com> On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: > JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the jdk jimage.hpp header. Brought the headers in line. > > http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html > https://bugs.openjdk.java.net/browse/JDK-8147426 > This looks okay to me but comment on JIMAGE_MAX_PATH about the JCK caught by eye and maybe now is a good time to remove that. -Alan From james.laskey at oracle.com Sun Apr 24 11:47:50 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Sun, 24 Apr 2016 08:47:50 -0300 Subject: RFR: JDK-8147426 - Missing definition for JIMAGE_NOT_FOUND In-Reply-To: <571C8241.5010905@oracle.com> References: <1A36919B-354F-43DA-9130-4156AADD001A@oracle.com> <571C8241.5010905@oracle.com> Message-ID: JCK change incorporated. Thank you. > On Apr 24, 2016, at 5:22 AM, Alan Bateman wrote: > > > On 22/04/2016 14:12, Jim Laskey (Oracle) wrote: >> JIMAGE_NOT_FOUND was defined in the hotspot jimage.hpp header but not in the jdk jimage.hpp header. Brought the headers in line. >> >> http://cr.openjdk.java.net/~jlaskey/8147426/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8147426 >> > This looks okay to me but comment on JIMAGE_MAX_PATH about the JCK caught by eye and maybe now is a good time to remove that. > > -Alan From kumar.x.srinivasan at oracle.com Sun Apr 24 14:52:47 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sun, 24 Apr 2016 07:52:47 -0700 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571B7796.8030905@gmail.com> References: <56F3F90D.9010408@gmail.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> Message-ID: <571CDDBF.7000909@oracle.com> Hi Yasumasa, Looks good. Thanks Kumar On 4/23/2016 6:24 AM, Yasumasa Suenaga wrote: > Hi Kumar, > > Thank you for your comment! > I've fixed them and uploaded new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ > > > Thanks, > > Yasumasa > > > On 2016/04/23 1:14, Kumar Srinivasan wrote: >> >> Also a couple of minor suggestions: >> >> - * Set native thread name as possible. >> + * Set native thread name if possible. >> >> >> + /* >> - * We can clear pending exception because exception at this point >> - * is not critical. >> + */ >> >> + /* >> + * Clear non critical pending exceptions at this point. >> + */ >> >> Thanks >> Kumar >> >>> Hi, >>> >>> This is in the wrong place: >>> >>> 1715 if ((*env)->ExceptionOccurred(env)) { >>> 1716 /* >>> 1717 * We can clear pending exception because exception at >>> this point >>> 1718 * is not critical. >>> 1719 */ >>> 1720 (*env)->ExceptionClear(env); >>> 1721 } >>> >>> This above needs to be after >>> 391 SetNativeThreadName(env, "main"); >>> 392 >>> >>> Here is why, supposing 1704 through 1711, returns a NULL, >>> but have also encountered an exception. In which case >>> the method SetNativeThreadName will return to the caller, as >>> if nothing has happened, because NULL_CHECK simply checks for NULL >>> and returns to the caller. This will cause the caller to enter >>> the VM with exceptions. >>> >>> Kumar >>> >>> >>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> I don't think we need to report the exception, but can just ignore >>>>> it. Either way we have to clear the exception before continuing. >>>> >>>> I've fixed it in new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/22 15:33, David Holmes wrote: >>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I have uploaded webrev.04 as below. >>>>>> Could you review again? >>>>>> >>>>>> > - hotspot: >>>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>> >>>>> Looks fine. >>>>> >>>>>> > >>>>>> > - jdk: >>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>> >>>>> As per private email (but repeated here on the record) in java.c: >>>>> >>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>> 1716 JLI_ReportExceptionDescription(env); >>>>> 1717 } >>>>> >>>>> I don't think we need to report the exception, but can just ignore >>>>> it. Either way we have to clear the exception before continuing. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>> >: >>>>>> > >>>>>> > Hi David, >>>>>> > >>>>>> > Thank you for your comment. >>>>>> > I uploaded new webrev. Could you review again? >>>>>> > >>>>>> > - hotspot: >>>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>> > >>>>>> > - jdk: >>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>> > >>>>>> > >>>>>> >> That aside I'm not sure why you do this so late in the >>>>>> process, I >>>>>> would have done it immediately after here: >>>>>> > >>>>>> > >>>>>> > I think that native thread name ("main") should be set just >>>>>> before >>>>>> > main method call. >>>>>> > However, main thread is already started, so I moved it as you >>>>>> suggested. >>>>>> > >>>>>> > >>>>>> >> One thing I dislike about the current structure is that we >>>>>> have to >>>>>> go from char* to java.lang.String to call setNativeName which >>>>>> then calls >>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>> char* ! >>>>>> > >>>>>> > >>>>>> > SoI proposed to export new JVM function to set native thread >>>>>> name with >>>>>> > const char *. >>>>>> > >>>>>> > >>>>>> > Thanks, >>>>>> > >>>>>> > Yasumasa >>>>>> > >>>>>> > >>>>>> > >>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>> >> >>>>>> >> Hi Yasumasa, >>>>>> >> >>>>>> >> Thanks for persevering with this to get it into the current >>>>>> form. >>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>> >> >>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>> >>> >>>>>> >>> Hi Gerard, >>>>>> >>> >>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>> >>>>>> >>> >>>>> >>: >>>>>> >>> > >>>>>> >>> > hi Yasumasa, >>>>>> >>> > >>>>>> >>> > Nice work. I have 2 questions: >>>>>> >>> > >>>>>> >>> > ======== >>>>>> >>> > File: java.c >>>>>> >>> > >>>>>> >>> > #1 Shouldn?t we be checking for >>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>> >>> after every single JNI call? In this example instead of >>>>>> NULL_CHECK, >>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>> >>> >>>>>> >>> It is not critical if we encounter error at JNI function >>>>>> call because >>>>>> >>> we cannot set native thread name only. >>>>>> >>> So I think that we do not need to leave from launcher process. >>>>>> >> >>>>>> >> >>>>>> >> I agree we do not need to abort if an exception occurs (and >>>>>> in fact >>>>>> I don't think an exception is even possible from this code), but we >>>>>> should ensure any pending exception is cleared before any futher JNI >>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>> extensively >>>>>> throughout the launcher code - so if this usage is wrong then it >>>>>> is all >>>>>> wrong! More on this code below ... >>>>>> >> >>>>>> >> Other comments: >>>>>> >> >>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>> >> >>>>>> >> Please add a comment to the method now that you removed the >>>>>> internal >>>>>> comment: >>>>>> >> >>>>>> >> // Sets the native thread name for a JavaThread. If specifically >>>>>> >> // requested JNI-attached threads can also have their native >>>>>> name set; >>>>>> >> // otherwise we do not modify JNI-attached threads as it may >>>>>> interfere >>>>>> >> // with the application that created them. >>>>>> >> >>>>>> >> --- >>>>>> >> >>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>> >> >>>>>> >> Please add the following comments: >>>>>> >> >>>>>> >> + // Don't modify JNI-attached threads >>>>>> >> setNativeName(name, false); >>>>>> >> >>>>>> >> + // May be called directly via JNI or reflection (when >>>>>> permitted) to >>>>>> >> + // allow JNI-attached threads to set their native name >>>>>> >> private native void setNativeName(String name, boolean >>>>>> allowAttachedThread); >>>>>> >> >>>>>> >> --- >>>>>> >> >>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>> >> >>>>>> >> 328 #define LEAVE() \ >>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>> >> >>>>>> >> I was going to suggest this be set later, but realized we >>>>>> have to be >>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>> >> >>>>>> >> + /* Set native thread name. */ >>>>>> >> + SetNativeThreadName(env, "main"); >>>>>> >> >>>>>> >> The comment is redundant given the name of the method. That >>>>>> aside >>>>>> I'm not sure why you do this so late in the process, I would have >>>>>> done >>>>>> it immediately after here: >>>>>> >> >>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>> >> 388 exit(1); >>>>>> >> 389 } >>>>>> >> + SetNativeThreadName(env, "main"); >>>>>> >> >>>>>> >> >>>>>> >> + /** >>>>>> >> + * Set native thread name as possible. >>>>>> >> + */ >>>>>> >> >>>>>> >> Other than the as->if change I'm unclear where the "possible" >>>>>> bit >>>>>> comes into play - why would it not be possible? >>>>>> >> >>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>> "java/lang/Thread")); >>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>> (*env)->GetStaticMethodID(env, >>>>>> cls, >>>>>> >> 1707 "currentThread", >>>>>> "()Ljava/lang/Thread;")); >>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>> >> 1709 currentThreadID)); >>>>>> >> 1710 NULL_CHECK(setNativeNameID = >>>>>> (*env)->GetMethodID(env, cls, >>>>>> >> 1711 "setNativeName", >>>>>> "(Ljava/lang/String;Z)V")); >>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>> name)); >>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>> setNativeNameID, >>>>>> >> 1714 nameString, JNI_TRUE); >>>>>> >> >>>>>> >> As above NULL_CHECK is fine here, but we should check for and >>>>>> clear >>>>>> any pending exception after CallVoidMethod. >>>>>> >> >>>>>> >> One thing I dislike about the current structure is that we >>>>>> have to >>>>>> go from char* to java.lang.String to call setNativeName which >>>>>> then calls >>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>> char* ! >>>>>> Overall I wonder about the affect on startup cost. But if there >>>>>> is an >>>>>> issue we can revisit this. >>>>>> >> >>>>>> >> Thanks, >>>>>> >> David >>>>>> >> ----- >>>>>> >> >>>>>> >> >>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set >>>>>> native >>>>>> thread >>>>>> >>> name if possible.? not "Set native thread name as possible.?? >>>>>> >>> >>>>>> >>> Sorry for my bad English :-) >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> >>>>>> >>> Yasumasa >>>>>> >>> >>>>>> >>> > cheers >>>>>> >>> > >>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>> >>>>>> >>> >> wrote: >>>>>> >>> > > >>>>>> >>> > > Hi David, >>>>>> >>> > > >>>>>> >>> > > I uploaded new webrev: >>>>>> >>> > > >>>>>> >>> > > - hotspot: >>>>>> >>> > > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>> >>> > > >>>>>> >>> > > - jdk: >>>>>> >>> > > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > >> it won't work unless you change the semantics of >>>>>> setName so I'm >>>>>> >>> not sure what you were thinking here. To take advantage of >>>>>> an arg >>>>>> taking >>>>>> >>> JVM_SetNativThreadName you would need to call it directly as >>>>>> no Java >>>>>> >>> code will call it . ??? >>>>>> >>> > > >>>>>> >>> > > I added a flag for setting native thread name to >>>>>> JNI-attached >>>>>> thread. >>>>>> >>> > > This change can set native thread name if main thread >>>>>> changes to >>>>>> >>> JNI-attached thread. >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > Thanks, >>>>>> >>> > > >>>>>> >>> > > Yasumasa >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>> >>> > >>> Hi David, >>>>>> >>> > >>> >>>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>>> considered a >>>>>> >>> > >>>> regression that setName stops setting the native thread >>>>>> main, even >>>>>> >>> > >>>> though we never really intended it to work in the >>>>>> first place. >>>>>> >>> :( Such >>>>>> >>> > >>>> a change needs to go through CCC. >>>>>> >>> > >>> >>>>>> >>> > >>> I understood. >>>>>> >>> > >>> Can I send CCC request? >>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>>> >>> > >> >>>>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>>>> sponsor for >>>>>> >>> that. But at this stage I don't think I agree with the >>>>>> proposed change >>>>>> >>> because of the change in behaviour - there's no way to >>>>>> restore the >>>>>> >>> "broken" behaviour. >>>>>> >>> > >> >>>>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 >>>>>> [1]. >>>>>> >>> > >> >>>>>> >>> > >> Okay we can do that. >>>>>> >>> > >> >>>>>> >>> > >>> >>>>>> >>> > >>>> Further, we expect the launcher to use the supported >>>>>> JNI >>>>>> >>> interface (as >>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>> interface that >>>>>> >>> exists for >>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>> >>> > >>> >>>>>> >>> > >>> I think that we do not use JVM interface if we add >>>>>> new method in >>>>>> >>> > >>> LauncherHelper as below: >>>>>> >>> > >>> ---------------- >>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>> >>> > >>> >>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> >>> > >>> --- >>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>> >>> > >>> +++ >>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>> >>> > >>> else >>>>>> >>> > >>> return md.toNameAndVersion() + " (" + >>>>>> loc + ")"; >>>>>> >>> > >>> } >>>>>> >>> > >>> + >>>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>> >>> > >>> + } >>>>>> >>> > >> >>>>>> >>> > >> You could also make that call via JNI directly, so not >>>>>> sure the >>>>>> >>> helper adds much here. But it won't work unless you change the >>>>>> semantics >>>>>> >>> of setName so I'm not sure what you were thinking here. To take >>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>>>> need to >>>>>> call >>>>>> >>> it directly as no Java code will call it . ??? >>>>>> >>> > >> >>>>>> >>> > >> David >>>>>> >>> > >> ----- >>>>>> >>> > >> >>>>>> >>> > >>> } >>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>> src/java.base/share/native/libjli/java.c >>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>>>>> Apr 13 >>>>>> 14:19:30 >>>>>> >>> > >>> 2016 +0000 >>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>>>>> Apr 16 >>>>>> 11:25:53 >>>>>> >>> > >>> 2016 +0900 >>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>>>>> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>> *name); >>>>>> >>> > >>> >>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>> >>> > >>> >>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>> >>> > >>> */ >>>>>> >>> > >>> #define LEAVE() \ >>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>> >>> > >>> do { \ >>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != >>>>>> JNI_OK) { \ >>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>> >>> > >>> >>>>>> >>> > >>> + /* Set native thread name. */ >>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>> >>> > >>> + >>>>>> >>> > >>> /* Invoke main method. */ >>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>> mainArgs); >>>>>> >>> > >>> >>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>> >>> > >>> joptString); >>>>>> >>> > >>> } >>>>>> >>> > >>> >>>>>> >>> > >>> +/** >>>>>> >>> > >>> + * Set native thread name as possible. >>>>>> >>> > >>> + */ >>>>>> >>> > >>> +static void >>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>> >>> > >>> +{ >>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>> >>> > >>> + jstring nameString; >>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>> name)); >>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>> setNativeThreadNameID, >>>>>> >>> > >>> nameString); >>>>>> >>> > >>> +} >>>>>> >>> > >>> + >>>>>> >>> > >>> /* >>>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>> >>> > >>> */ >>>>>> >>> > >>> ---------------- >>>>>> >>> > >>> >>>>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>> >>> > >>> >>>>>> >>> > >>>> However this is still a change to the exported JVM >>>>>> interface and so >>>>>> >>> > >>>> has to be approved. >>>>>> >>> > >>> >>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>> >>> > >>> >>>>>> >>> > >>> >>>>>> >>> > >>> Thanks, >>>>>> >>> > >>> >>>>>> >>> > >>> Yasumasa >>>>>> >>> > >>> >>>>>> >>> > >>> >>>>>> >>> > >>> [1] >>>>>> >>> > >>> >>>>>> >>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>> >>>>>> >>> > >>> >>>>>> >>> > >>> >>>>>> >>> > >>> >>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>> Hi David, >>>>>> >>> > >>>>> >>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>> for main >>>>>> >>> thread and >>>>>> >>> > >>>>>> JNI attached threads >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> >>>>>> >>> > >>>>>> Though that will introduce a change in behaviour >>>>>> by itself as >>>>>> >>> setName >>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>> thread. >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> I know. >>>>>> >>> > >>>> >>>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>>> considered a >>>>>> >>> > >>>> regression that setName stops setting the native thread >>>>>> main, even >>>>>> >>> > >>>> though we never really intended it to work in the >>>>>> first place. >>>>>> >>> :( Such >>>>>> >>> > >>>> a change needs to go through CCC. >>>>>> >>> > >>>> >>>>>> >>> > >>>>> I checked changeset history. >>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>> JDK-7098194, >>>>>> and it is >>>>>> >>> > >>>>> backported JDK 8. >>>>>> >>> > >>>> >>>>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>>>> >>> > >>>> >>>>>> >>> > >>>>> However, this function seems to be called from >>>>>> >>> Thread#setNativeName() >>>>>> >>> > >>>>> only. >>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private method. >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>> >>> JVM_SetNativeThreadName() >>>>>> >>> > >>>>> for force setting. >>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>> >>> > >>>>> However, this function is NOT public, so I think we >>>>>> can >>>>>> add one >>>>>> >>> more >>>>>> >>> > >>>>> argument. >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> What do you think about this? >>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>> from Java >>>>>> >>> launcher. >>>>>> >>> > >>>> >>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>> really at >>>>>> >>> issue. Yes >>>>>> >>> > >>>> we would add another arg to the JVM function to >>>>>> allow it to >>>>>> apply to >>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>> reflect that >>>>>> >>> not just >>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>> exported JVM >>>>>> >>> interface >>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>> launcher to >>>>>> >>> use the >>>>>> >>> > >>>> supported JNI interface (as other processes would), >>>>>> not the >>>>>> internal >>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>> communicate >>>>>> >>> with the >>>>>> >>> > >>>> JVM. >>>>>> >>> > >>>> >>>>>> >>> > >>>> David >>>>>> >>> > >>>> ----- >>>>>> >>> > >>>> >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> Thanks, >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> Yasumasa >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>> Hi David, >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>>>>> being a >>>>>> >>> JNI-attached >>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>> for main >>>>>> >>> thread and >>>>>> >>> > >>>>>> JNI attached threads >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> Though that will introduce a change in behaviour >>>>>> by itself as >>>>>> >>> setName >>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>> thread. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>> >>> > >>>>>>> --------------- >>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr >>>>>> 14 13:31:11 >>>>>> >>> 2016 +0200 >>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr >>>>>> 15 17:50:10 >>>>>> >>> 2016 +0900 >>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization >>>>>> is complete >>>>>> >>> - nop if >>>>>> >>> > >>>>>>> no agents. >>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>> >>> > >>>>>>> + >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> I think we can do this straight after the JavaThread >>>>>> constructor. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>> tracing >>>>>> >>> > >>>>>>> backend."); >>>>>> >>> > >>>>>>> } >>>>>> >>> > >>>>>>> --------------- >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>>> If it wants to name its native threads then it >>>>>> is free >>>>>> to do so, >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot >>>>>> change native >>>>>> >>> thread name >>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>> >>> > >>>>>>> However, I think that it should be changed if >>>>>> Java developer >>>>>> >>> calls >>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>> >>> > >>>>>>> It is not the same of changing native thread name at >>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>> SetNativeThreadName() as >>>>>> below. >>>>>> >>> > >>>>>>> What do you think about this? >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>>>> threads was a >>>>>> >>> > >>>>>> deliberate one** - this functionality originated >>>>>> with the OSX >>>>>> >>> port and >>>>>> >>> > >>>>>> it was reported that the initial feedback with this >>>>>> feature was to >>>>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>>>> been set by >>>>>> >>> the host >>>>>> >>> > >>>>>> process. If we do as you propose then we will just >>>>>> have an >>>>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>>>> does my >>>>>> >>> native thread >>>>>> >>> > >>>>>> only have a name if I call >>>>>> cur.setName(cur.getName()) ?" >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> ** If you follow the bugs and related discussions on >>>>>> this, the >>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>> thread only, >>>>>> >>> non-JNI >>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>> were supposed >>>>>> >>> to be >>>>>> >>> > >>>>>> documented in the release notes - but as far as I >>>>>> can see >>>>>> that >>>>>> >>> never >>>>>> >>> > >>>>>> happened. :( >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> My position on this remains that if it is >>>>>> desirable for >>>>>> the main >>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native >>>>>> names >>>>>> then the >>>>>> >>> > >>>>>> launcher needs to be setting them using the available >>>>>> platform >>>>>> >>> APIs. >>>>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced >>>>>> by the VM >>>>>> >>> code for >>>>>> >>> > >>>>>> this - due to the need to verify API availability. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>> Thread.setName would >>>>>> >>> have to go >>>>>> >>> > >>>>>> through our CCC process I think. But a change in >>>>>> the launcher >>>>>> >>> would >>>>>> >>> > >>>>>> not. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> Sorry. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> David >>>>>> >>> > >>>>>> ----- >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>>> --------------- >>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr >>>>>> 14 13:31:11 >>>>>> >>> 2016 +0200 >>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr >>>>>> 15 17:50:10 >>>>>> >>> 2016 +0900 >>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>> java_lang_Thread::thread(java_thread); >>>>>> >>> > >>>>>>> // Thread naming only supported for the >>>>>> current thread, >>>>>> >>> doesn't >>>>>> >>> > >>>>>>> work >>>>>> >>> > >>>>>>> for >>>>>> >>> > >>>>>>> // target threads. >>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>> >>> !thr->has_attached_via_jni()) { >>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>> thread to avoid >>>>>> >>> stepping >>>>>> >>> > >>>>>>> // on other programs >>>>>> >>> > >>>>>>> const char *thread_name = >>>>>> >>> > >>>>>>> >>>>>> >>> >>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>> >>>>>> >>> > >>>>>>> --------------- >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> Thanks, >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> Yasumasa >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>>>> Roger, >>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> David, >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>> this. I >>>>>> don't like >>>>>> >>> > >>>>>>>>>>>> exposing >>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>> initializing VM >>>>>> (before >>>>>> >>> > >>>>>>>>> calling >>>>>> >>> > >>>>>>>>> main method), >>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>> AttachCurrentThread(). >>>>>> So we >>>>>> >>> can't >>>>>> >>> > >>>>>>>>> set >>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier this >>>>>> morning. >>>>>> >>> Which, >>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic >>>>>> premise here that >>>>>> >>> we don't >>>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>>>> The fact >>>>>> >>> that the >>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >>>>>> thread seems >>>>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is >>>>>> only >>>>>> working by >>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>> used for the >>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>> inconsistently >>>>>> >>> named at >>>>>> >>> > >>>>>>>> the native level. >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has >>>>>> to be >>>>>> >>> treated like >>>>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>>>> wants to >>>>>> name its >>>>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>>>> would not be >>>>>> >>> exporting >>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>> have to >>>>>> use the OS >>>>>> >>> > >>>>>>>> specific API's for that on a >>>>>> platform-by-platform basis. >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> Sorry. >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> David >>>>>> >>> > >>>>>>>> ----- >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>> >>> > >>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> Comments: >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>>>>> perform >>>>>> >>> different >>>>>> >>> > >>>>>>>>>> functions: >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>> JVM_SetNativeThreadName >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> - The first function applies to the current >>>>>> thread, the >>>>>> >>> second >>>>>> >>> > >>>>>>>>>> one a >>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>>>>> somewhere >>>>>> >>> about >>>>>> >>> > >>>>>>>>>> what >>>>>> >>> > >>>>>>>>>> the new function does. >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>> casts to >>>>>> (void*) >>>>>> >>> > >>>>>>>>>> instead of >>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>> overwriteifn->GetCreatedJavaVMs >>>>>> >>> used at >>>>>> >>> > >>>>>>>>>> line 730 >>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>>>>> the cast >>>>>> >>> on the >>>>>> >>> > >>>>>>>>>> same >>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>> haven't had >>>>>> time to >>>>>> >>> > >>>>>>>>>>>> check - >>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>> JNI-attached >>>>>> >>> thread >>>>>> >>> > >>>>>>>>>>>> then >>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>> suggestion >>>>>> >>> should >>>>>> >>> > >>>>>>>>>>>> work >>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>> treatment of >>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >>>>>> confirmed >>>>>> >>> native >>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>> >>> > >>>>>>>>>>> --------- >>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>>>> Exception{ >>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>> >>> > >>>>>>>>>>> } >>>>>> >>> > >>>>>>>>>>> } >>>>>> >>> > >>>>>>>>>>> --------- >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>> this. I >>>>>> don't like >>>>>> >>> > >>>>>>>>>>>> exposing >>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>> comment. >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>>>>> thread >>>>>> >>> name, and JLI >>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>> >>> > >>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>>>>> >>> core-libs will >>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>> Kumar) - >>>>>> now cc'd. >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>>> >>> Thread.setName >>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>>>> hotspot changes >>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>> Thread#setName() in >>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>>>>> which is >>>>>> >>> why the >>>>>> >>> > >>>>>>>>>>>> native >>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>> attached thread. >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>> haven't had >>>>>> time to >>>>>> >>> > >>>>>>>>>>>> check - >>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>> JNI-attached >>>>>> >>> thread >>>>>> >>> > >>>>>>>>>>>> then >>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>> suggestion >>>>>> >>> should >>>>>> >>> > >>>>>>>>>>>> work >>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>> treatment of >>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>> this. I >>>>>> don't like >>>>>> >>> > >>>>>>>>>>>> exposing >>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>> David >>>>>> >>> > >>>>>>>>>>>> ----- >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>> function to set >>>>>> >>> native >>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>>> David >>>>>> >>> > >>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>>>> well ... >>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry >>>>>> have >>>>>> been on >>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>>>> correct >>>>>> as we >>>>>> >>> do not >>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >>>>>> includes the >>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer >>>>>> :-) >>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>> >>>>>> >>> >>: >>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>> Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>> Suenaga >>>>>> wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>> >>> >>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>> >>> >>>>> >>>: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>>>> Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>> >>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>> >>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>>>>> >>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>> >>> >>>>> >>>>: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't >>>>>> set it: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = >>>>>> new >>>>>> >>> JavaThread(); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> main_thread->initialize_thread_current(); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>> >>> set_active_handles >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> main_thread->record_stack_base_and_size(); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> >>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>>>> something? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same >>>>>> to thread >>>>>> >>> name in >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>>>> setName(). >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in >>>>>> Java app, >>>>>> native >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread >>>>>> is already >>>>>> >>> starte >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >>>>>> thrrad name >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>>> something like >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>> a/src/share/vm/runtime/thread.cpp >>>>>> Tue >>>>>> >>> Mar 29 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>> b/src/share/vm/runtime/thread.cpp >>>>>> Wed >>>>>> >>> Mar 30 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>> create_initial_thread(Handle >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>> initial_thread_name = >>>>>> >>> "main"; >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> >>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>> (THREAD, k); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>> >>> thread); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> thread->set_threadObj(thread_oop()); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> java_lang_String::create_from_str("main", >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>>>> thread_oop, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>> itself >>>>>> 'java' and >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>>>> process >>>>>> (and >>>>>> >>> thus >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>>>> process >>>>>> is not >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread >>>>>> with >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>>>> >>> JavaThread. So I >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>>>>> thread. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>> anyhow, since >>>>>> >>> we want >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java >>>>>> thread name >>>>>> might >>>>>> >>> have >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' >>>>>> | head -4 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something >>>>>> like >>>>>> 'Java Main >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a >>>>>> Java >>>>>> >>> launcher - e.g. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>>>> thread >>>>>> name, >>>>>> >>> I think >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>> Yasumasa >>>>>> >>> Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>>>>> thread >>>>>> >>> name via >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >>>>>> have it. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native >>>>>> name, >>>>>> and main >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >>>>>> should have >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could >>>>>> you >>>>>> review it? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>> >>> >>>>>> >>> >> From david.holmes at oracle.com Mon Apr 25 05:37:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Apr 2016 15:37:50 +1000 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571A41D1.30707@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> Message-ID: <571DAD2E.1000200@oracle.com> Hi Rachel, Maybe too late, but despite comments to the contrary from the other reviewers I think there are enough suggested changes being suggested that I would want to see another webrev. Thanks, David On 23/04/2016 1:22 AM, Rachel Protacio wrote: > Hi, Coleen, > > Thanks for the review! I'll remove the arrayKlass entries and, seeing no > other objections, will commit. > > Rachel > > On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >> >> Hi, >> >> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >> >> >> I don't think you need module or package declared in arrayKlass.hpp >> since it should be abstract also, ie. there should be no instances of >> ArrayKlass. >> >> Otherwise, looks great. I love seeing those InstanceKlass::casts go >> away. >> >> Coleen >> >> >> On 4/21/16 10:26 PM, David Holmes wrote: >>> Hi Rachel, >>> >>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>> Hello, >>>> >>>> Please review this fix for the package() and module() functions, making >>>> them pure virtual functions of Klass and implementing them in the >>>> relevant child classes. This cleans up some verbose and repetitive code >>>> that was casting and checking klass types. Also added test cases to >>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>> module() functions work as expected. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>> >>> The refactoring all looks good to me (though C++ annoys me in needing >>> to re-declare the functions in each subclass :) ). >>> >>> Cheers, >>> David >>> >>>> Tested with jtreg tests in jdk/test (java/lang, java/io, java/security, >>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >>>> hotspot and non-colo tests. >>>> >>>> Thanks! >>>> Rachel >> > From david.holmes at oracle.com Mon Apr 25 05:46:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Apr 2016 15:46:35 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571A381E.9050605@oracle.com> References: <56F3F90D.9010408@gmail.com> <56FC3D4B.2000700@oracle.com> <56FC3DF8.4080309@oracle.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> Message-ID: <571DAF3B.9030200@oracle.com> On 23/04/2016 12:41 AM, Kumar Srinivasan wrote: > Hi, > > This is in the wrong place: > > 1715 if ((*env)->ExceptionOccurred(env)) { > 1716 /* > 1717 * We can clear pending exception because exception at this > point > 1718 * is not critical. > 1719 */ > 1720 (*env)->ExceptionClear(env); > 1721 } > > This above needs to be after > 391 SetNativeThreadName(env, "main"); > 392 > > Here is why, supposing 1704 through 1711, returns a NULL, > but have also encountered an exception. In which case > the method SetNativeThreadName will return to the caller, as > if nothing has happened, because NULL_CHECK simply checks for NULL > and returns to the caller. This will cause the caller to enter > the VM with exceptions. Ah! Now I see the pattern. All the existing functions that use NULL_CHECK are followed by CHECK_EXCEPTION_LEAVE. Thanks for pointing that out Kumar! David > Kumar > > > On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >> Hi David, >> >>> I don't think we need to report the exception, but can just ignore >>> it. Either way we have to clear the exception before continuing. >> >> I've fixed it in new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/22 15:33, David Holmes wrote: >>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> I have uploaded webrev.04 as below. >>>> Could you review again? >>>> >>>> > - hotspot: >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>> >>> Looks fine. >>> >>>> > >>>> > - jdk: >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>> >>> As per private email (but repeated here on the record) in java.c: >>> >>> 715 if ((*env)->ExceptionOccurred(env)) { >>> 1716 JLI_ReportExceptionDescription(env); >>> 1717 } >>> >>> I don't think we need to report the exception, but can just ignore >>> it. Either way we have to clear the exception before continuing. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>> >: >>>> > >>>> > Hi David, >>>> > >>>> > Thank you for your comment. >>>> > I uploaded new webrev. Could you review again? >>>> > >>>> > - hotspot: >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>> > >>>> > - jdk: >>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>> > >>>> > >>>> >> That aside I'm not sure why you do this so late in the process, I >>>> would have done it immediately after here: >>>> > >>>> > >>>> > I think that native thread name ("main") should be set just before >>>> > main method call. >>>> > However, main thread is already started, so I moved it as you >>>> suggested. >>>> > >>>> > >>>> >> One thing I dislike about the current structure is that we have to >>>> go from char* to java.lang.String to call setNativeName which then >>>> calls >>>> JVM_SetNativeThreadName which converts the j.l.String back to a char* ! >>>> > >>>> > >>>> > SoI proposed to export new JVM function to set native thread name >>>> with >>>> > const char *. >>>> > >>>> > >>>> > Thanks, >>>> > >>>> > Yasumasa >>>> > >>>> > >>>> > >>>> > On 2016/04/19 14:04, David Holmes wrote: >>>> >> >>>> >> Hi Yasumasa, >>>> >> >>>> >> Thanks for persevering with this to get it into the current form. >>>> Sorry I haven't been able to do a detailed review until now. >>>> >> >>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>> >>> >>>> >>> Hi Gerard, >>>> >>> >>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>> >>>> >>> >>> >>: >>>> >>> > >>>> >>> > hi Yasumasa, >>>> >>> > >>>> >>> > Nice work. I have 2 questions: >>>> >>> > >>>> >>> > ======== >>>> >>> > File: java.c >>>> >>> > >>>> >>> > #1 Shouldn?t we be checking for >>>> ?(*env)->ExceptionOccurred(env)? >>>> >>> after every single JNI call? In this example instead of >>>> NULL_CHECK, >>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>> >>> >>>> >>> It is not critical if we encounter error at JNI function call >>>> because >>>> >>> we cannot set native thread name only. >>>> >>> So I think that we do not need to leave from launcher process. >>>> >> >>>> >> >>>> >> I agree we do not need to abort if an exception occurs (and in fact >>>> I don't think an exception is even possible from this code), but we >>>> should ensure any pending exception is cleared before any futher JNI >>>> calls might be made. Note that NULL_CHECK is already used extensively >>>> throughout the launcher code - so if this usage is wrong then it is all >>>> wrong! More on this code below ... >>>> >> >>>> >> Other comments: >>>> >> >>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>> >> >>>> >> Please add a comment to the method now that you removed the >>>> internal >>>> comment: >>>> >> >>>> >> // Sets the native thread name for a JavaThread. If specifically >>>> >> // requested JNI-attached threads can also have their native >>>> name set; >>>> >> // otherwise we do not modify JNI-attached threads as it may >>>> interfere >>>> >> // with the application that created them. >>>> >> >>>> >> --- >>>> >> >>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>> >> >>>> >> Please add the following comments: >>>> >> >>>> >> + // Don't modify JNI-attached threads >>>> >> setNativeName(name, false); >>>> >> >>>> >> + // May be called directly via JNI or reflection (when >>>> permitted) to >>>> >> + // allow JNI-attached threads to set their native name >>>> >> private native void setNativeName(String name, boolean >>>> allowAttachedThread); >>>> >> >>>> >> --- >>>> >> >>>> >> jd/src/java.base/share/native/libjli/java.c >>>> >> >>>> >> 328 #define LEAVE() \ >>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>> >> >>>> >> I was going to suggest this be set later, but realized we have >>>> to be >>>> attached to do this and that happens inside DestroyJavaVM. :) >>>> >> >>>> >> + /* Set native thread name. */ >>>> >> + SetNativeThreadName(env, "main"); >>>> >> >>>> >> The comment is redundant given the name of the method. That aside >>>> I'm not sure why you do this so late in the process, I would have done >>>> it immediately after here: >>>> >> >>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>> >> 388 exit(1); >>>> >> 389 } >>>> >> + SetNativeThreadName(env, "main"); >>>> >> >>>> >> >>>> >> + /** >>>> >> + * Set native thread name as possible. >>>> >> + */ >>>> >> >>>> >> Other than the as->if change I'm unclear where the "possible" bit >>>> comes into play - why would it not be possible? >>>> >> >>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>> "java/lang/Thread")); >>>> >> 1706 NULL_CHECK(currentThreadID = >>>> (*env)->GetStaticMethodID(env, >>>> cls, >>>> >> 1707 "currentThread", >>>> "()Ljava/lang/Thread;")); >>>> >> 1708 NULL_CHECK(currentThread = >>>> (*env)->CallStaticObjectMethod(env, cls, >>>> >> 1709 currentThreadID)); >>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, cls, >>>> >> 1711 "setNativeName", >>>> "(Ljava/lang/String;Z)V")); >>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, name)); >>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>> setNativeNameID, >>>> >> 1714 nameString, JNI_TRUE); >>>> >> >>>> >> As above NULL_CHECK is fine here, but we should check for and clear >>>> any pending exception after CallVoidMethod. >>>> >> >>>> >> One thing I dislike about the current structure is that we have to >>>> go from char* to java.lang.String to call setNativeName which then >>>> calls >>>> JVM_SetNativeThreadName which converts the j.l.String back to a char* ! >>>> Overall I wonder about the affect on startup cost. But if there is an >>>> issue we can revisit this. >>>> >> >>>> >> Thanks, >>>> >> David >>>> >> ----- >>>> >> >>>> >> >>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set native >>>> thread >>>> >>> name if possible.? not "Set native thread name as possible.?? >>>> >>> >>>> >>> Sorry for my bad English :-) >>>> >>> >>>> >>> Thanks, >>>> >>> >>>> >>> Yasumasa >>>> >>> >>>> >>> > cheers >>>> >>> > >>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>> >>>> >>> >> wrote: >>>> >>> > > >>>> >>> > > Hi David, >>>> >>> > > >>>> >>> > > I uploaded new webrev: >>>> >>> > > >>>> >>> > > - hotspot: >>>> >>> > > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>> >>> > > >>>> >>> > > - jdk: >>>> >>> > > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>> >>> > > >>>> >>> > > >>>> >>> > >> it won't work unless you change the semantics of setName >>>> so I'm >>>> >>> not sure what you were thinking here. To take advantage of an arg >>>> taking >>>> >>> JVM_SetNativThreadName you would need to call it directly as no >>>> Java >>>> >>> code will call it . ??? >>>> >>> > > >>>> >>> > > I added a flag for setting native thread name to JNI-attached >>>> thread. >>>> >>> > > This change can set native thread name if main thread >>>> changes to >>>> >>> JNI-attached thread. >>>> >>> > > >>>> >>> > > >>>> >>> > > Thanks, >>>> >>> > > >>>> >>> > > Yasumasa >>>> >>> > > >>>> >>> > > >>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>> >>> > >>> Hi David, >>>> >>> > >>> >>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>> considered a >>>> >>> > >>>> regression that setName stops setting the native thread >>>> main, even >>>> >>> > >>>> though we never really intended it to work in the first >>>> place. >>>> >>> :( Such >>>> >>> > >>>> a change needs to go through CCC. >>>> >>> > >>> >>>> >>> > >>> I understood. >>>> >>> > >>> Can I send CCC request? >>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>> >>> > >> >>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>> sponsor for >>>> >>> that. But at this stage I don't think I agree with the proposed >>>> change >>>> >>> because of the change in behaviour - there's no way to restore the >>>> >>> "broken" behaviour. >>>> >>> > >> >>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 [1]. >>>> >>> > >> >>>> >>> > >> Okay we can do that. >>>> >>> > >> >>>> >>> > >>> >>>> >>> > >>>> Further, we expect the launcher to use the supported JNI >>>> >>> interface (as >>>> >>> > >>>> other processes would), not the internal JVM interface >>>> that >>>> >>> exists for >>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>> >>> > >>> >>>> >>> > >>> I think that we do not use JVM interface if we add new >>>> method in >>>> >>> > >>> LauncherHelper as below: >>>> >>> > >>> ---------------- >>>> >>> > >>> diff -r f02139a1ac84 >>>> >>> > >>> >>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> >>> > >>> --- >>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>> >>> > >>> +++ >>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>> >>> > >>> @@ -960,4 +960,8 @@ >>>> >>> > >>> else >>>> >>> > >>> return md.toNameAndVersion() + " (" + loc + >>>> ")"; >>>> >>> > >>> } >>>> >>> > >>> + >>>> >>> > >>> + static void setNativeThreadName(String name) { >>>> >>> > >>> + Thread.currentThread().setName(name); >>>> >>> > >>> + } >>>> >>> > >> >>>> >>> > >> You could also make that call via JNI directly, so not >>>> sure the >>>> >>> helper adds much here. But it won't work unless you change the >>>> semantics >>>> >>> of setName so I'm not sure what you were thinking here. To take >>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>> need to >>>> call >>>> >>> it directly as no Java code will call it . ??? >>>> >>> > >> >>>> >>> > >> David >>>> >>> > >> ----- >>>> >>> > >> >>>> >>> > >>> } >>>> >>> > >>> diff -r f02139a1ac84 >>>> src/java.base/share/native/libjli/java.c >>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>>> Apr 13 >>>> 14:19:30 >>>> >>> > >>> 2016 +0000 >>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>>> Apr 16 >>>> 11:25:53 >>>> >>> > >>> 2016 +0900 >>>> >>> > >>> @@ -125,6 +125,7 @@ >>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>>> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char *name); >>>> >>> > >>> >>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>> >>> > >>> >>>> >>> > >>> @@ -325,6 +326,7 @@ >>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>> >>> > >>> */ >>>> >>> > >>> #define LEAVE() \ >>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>> >>> > >>> do { \ >>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>> >>> > >>> @@ -488,6 +490,9 @@ >>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>> >>> > >>> >>>> >>> > >>> + /* Set native thread name. */ >>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>> >>> > >>> + >>>> >>> > >>> /* Invoke main method. */ >>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>> mainArgs); >>>> >>> > >>> >>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>> >>> > >>> joptString); >>>> >>> > >>> } >>>> >>> > >>> >>>> >>> > >>> +/** >>>> >>> > >>> + * Set native thread name as possible. >>>> >>> > >>> + */ >>>> >>> > >>> +static void >>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>> >>> > >>> +{ >>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>> >>> > >>> + jstring nameString; >>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>> >>> > >>> + NULL_CHECK(cls); >>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>> >>> (*env)->GetStaticMethodID(env, cls, >>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>> name)); >>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>> setNativeThreadNameID, >>>> >>> > >>> nameString); >>>> >>> > >>> +} >>>> >>> > >>> + >>>> >>> > >>> /* >>>> >>> > >>> * Prints default usage or the Xusage message, see >>>> >>> > >>> sun.launcher.LauncherHelper.java >>>> >>> > >>> */ >>>> >>> > >>> ---------------- >>>> >>> > >>> >>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>> >>> > >>> >>>> >>> > >>>> However this is still a change to the exported JVM >>>> interface and so >>>> >>> > >>>> has to be approved. >>>> >>> > >>> >>>> >>> > >>> Do you mean that this change needs CCC? >>>> >>> > >>> >>>> >>> > >>> >>>> >>> > >>> Thanks, >>>> >>> > >>> >>>> >>> > >>> Yasumasa >>>> >>> > >>> >>>> >>> > >>> >>>> >>> > >>> [1] >>>> >>> > >>> >>>> >>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>> >>>> >>> > >>> >>>> >>> > >>> >>>> >>> > >>> >>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>> >>> > >>>>> Hi David, >>>> >>> > >>>>> >>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>> >>> > >>>>>> >>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for >>>> main >>>> >>> thread and >>>> >>> > >>>>>> JNI attached threads >>>> >>> > >>>>> >>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>> >>> > >>>>> >>>> >>> > >>>>> >>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>> itself as >>>> >>> setName >>>> >>> > >>>>>> will no longer set the native name for the main thread. >>>> >>> > >>>>> >>>> >>> > >>>>> I know. >>>> >>> > >>>> >>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>> considered a >>>> >>> > >>>> regression that setName stops setting the native thread >>>> main, even >>>> >>> > >>>> though we never really intended it to work in the first >>>> place. >>>> >>> :( Such >>>> >>> > >>>> a change needs to go through CCC. >>>> >>> > >>>> >>>> >>> > >>>>> I checked changeset history. >>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in JDK-7098194, >>>> and it is >>>> >>> > >>>>> backported JDK 8. >>>> >>> > >>>> >>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>> >>> > >>>> >>>> >>> > >>>>> However, this function seems to be called from >>>> >>> Thread#setNativeName() >>>> >>> > >>>>> only. >>>> >>> > >>>>> In addition, Thread#setNativeName() is private method. >>>> >>> > >>>>> >>>> >>> > >>>>> Thus I think that we can add an argument to >>>> >>> JVM_SetNativeThreadName() >>>> >>> > >>>>> for force setting. >>>> >>> > >>>>> (e.g. "bool forced") >>>> >>> > >>>>> >>>> >>> > >>>>> It makes a change of JVM API. >>>> >>> > >>>>> However, this function is NOT public, so I think we can >>>> add one >>>> >>> more >>>> >>> > >>>>> argument. >>>> >>> > >>>>> >>>> >>> > >>>>> What do you think about this? >>>> >>> > >>>>> If it is accepted, we can set native thread name from >>>> Java >>>> >>> launcher. >>>> >>> > >>>> >>>> >>> > >>>> The private/public aspect of the Java API is not really at >>>> >>> issue. Yes >>>> >>> > >>>> we would add another arg to the JVM function to allow >>>> it to >>>> apply to >>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>> reflect that >>>> >>> not just >>>> >>> > >>>> "force"). However this is still a change to the >>>> exported JVM >>>> >>> interface >>>> >>> > >>>> and so has to be approved. Further, we expect the >>>> launcher to >>>> >>> use the >>>> >>> > >>>> supported JNI interface (as other processes would), not >>>> the >>>> internal >>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>> communicate >>>> >>> with the >>>> >>> > >>>> JVM. >>>> >>> > >>>> >>>> >>> > >>>> David >>>> >>> > >>>> ----- >>>> >>> > >>>> >>>> >>> > >>>>> >>>> >>> > >>>>> Thanks, >>>> >>> > >>>>> >>>> >>> > >>>>> Yasumasa >>>> >>> > >>>>> >>>> >>> > >>>>> >>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>> >>> > >>>>>> Hi Yasumasa, >>>> >>> > >>>>>> >>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>> Hi David, >>>> >>> > >>>>>>> >>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>>> being a >>>> >>> JNI-attached >>>> >>> > >>>>>>>> thread seems accidental to me >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> Should I file it to JBS? >>>> >>> > >>>>>> >>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>> >>> > >>>>>> >>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // for >>>> main >>>> >>> thread and >>>> >>> > >>>>>> JNI attached threads >>>> >>> > >>>>>> >>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>> itself as >>>> >>> setName >>>> >>> > >>>>>> will no longer set the native name for the main thread. >>>> >>> > >>>>>> >>>> >>> > >>>>>>> I think that we can fix as below: >>>> >>> > >>>>>>> --------------- >>>> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 >>>> 13:31:11 >>>> >>> 2016 +0200 >>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 >>>> 17:50:10 >>>> >>> 2016 +0900 >>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>> >>> > >>>>>>> // must do this before set_active_handles >>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization is >>>> complete >>>> >>> - nop if >>>> >>> > >>>>>>> no agents. >>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> + // Change attach status to "attached" >>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>> >>> > >>>>>>> + >>>> >>> > >>>>>> >>>> >>> > >>>>>> I think we can do this straight after the JavaThread >>>> constructor. >>>> >>> > >>>>>> >>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start tracing >>>> >>> > >>>>>>> backend."); >>>> >>> > >>>>>>> } >>>> >>> > >>>>>>> --------------- >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> >>>> >>> > >>>>>>>> If it wants to name its native threads then it is free >>>> to do so, >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change >>>> native >>>> >>> thread name >>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>> >>> > >>>>>>> However, I think that it should be changed if Java >>>> developer >>>> >>> calls >>>> >>> > >>>>>>> Thread#setName() explicitly. >>>> >>> > >>>>>>> It is not the same of changing native thread name at >>>> >>> > >>>>>>> Threads::create_vm(). >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> If it is allowed, I want to fix >>>> SetNativeThreadName() as >>>> below. >>>> >>> > >>>>>>> What do you think about this? >>>> >>> > >>>>>> >>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>> threads was a >>>> >>> > >>>>>> deliberate one** - this functionality originated with >>>> the OSX >>>> >>> port and >>>> >>> > >>>>>> it was reported that the initial feedback with this >>>> feature was to >>>> >>> > >>>>>> ensure it didn't mess with thread names that had been >>>> set by >>>> >>> the host >>>> >>> > >>>>>> process. If we do as you propose then we will just >>>> have an >>>> >>> > >>>>>> inconsistency for people to complain about: "why does my >>>> >>> native thread >>>> >>> > >>>>>> only have a name if I call cur.setName(cur.getName()) ?" >>>> >>> > >>>>>> >>>> >>> > >>>>>> ** If you follow the bugs and related discussions on >>>> this, the >>>> >>> > >>>>>> semantics and limitations (truncation, current thread >>>> only, >>>> >>> non-JNI >>>> >>> > >>>>>> threads only) of setting the native thread name were >>>> supposed >>>> >>> to be >>>> >>> > >>>>>> documented in the release notes - but as far as I can >>>> see >>>> that >>>> >>> never >>>> >>> > >>>>>> happened. :( >>>> >>> > >>>>>> >>>> >>> > >>>>>> My position on this remains that if it is desirable for >>>> the main >>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native names >>>> then the >>>> >>> > >>>>>> launcher needs to be setting them using the available >>>> platform >>>> >>> APIs. >>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by >>>> the VM >>>> >>> code for >>>> >>> > >>>>>> this - due to the need to verify API availability. >>>> >>> > >>>>>> >>>> >>> > >>>>>> Any change in behaviour in relation to Thread.setName >>>> would >>>> >>> have to go >>>> >>> > >>>>>> through our CCC process I think. But a change in the >>>> launcher >>>> >>> would >>>> >>> > >>>>>> not. >>>> >>> > >>>>>> >>>> >>> > >>>>>> Sorry. >>>> >>> > >>>>>> >>>> >>> > >>>>>> David >>>> >>> > >>>>>> ----- >>>> >>> > >>>>>> >>>> >>> > >>>>>>> --------------- >>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 >>>> 13:31:11 >>>> >>> 2016 +0200 >>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 >>>> 17:50:10 >>>> >>> 2016 +0900 >>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>> >>> > >>>>>>> JavaThread* thr = >>>> java_lang_Thread::thread(java_thread); >>>> >>> > >>>>>>> // Thread naming only supported for the current >>>> thread, >>>> >>> doesn't >>>> >>> > >>>>>>> work >>>> >>> > >>>>>>> for >>>> >>> > >>>>>>> // target threads. >>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>> >>> !thr->has_attached_via_jni()) { >>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>> >>> > >>>>>>> // we don't set the name of an attached thread >>>> to avoid >>>> >>> stepping >>>> >>> > >>>>>>> // on other programs >>>> >>> > >>>>>>> const char *thread_name = >>>> >>> > >>>>>>> >>>> >>> >>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>> >>> > >>>>>>> --------------- >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> Thanks, >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> Yasumasa >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> >>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>> Roger, >>>> >>> > >>>>>>>>> Thanks for your comment! >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> David, >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>> don't like >>>> >>> > >>>>>>>>>>>> exposing >>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>> initializing VM >>>> (before >>>> >>> > >>>>>>>>> calling >>>> >>> > >>>>>>>>> main method), >>>> >>> > >>>>>>>>> I could set native thread name. >>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls AttachCurrentThread(). >>>> So we >>>> >>> can't >>>> >>> > >>>>>>>>> set >>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> Right - I came to the same realization earlier this >>>> morning. >>>> >>> Which, >>>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise >>>> here that >>>> >>> we don't >>>> >>> > >>>>>>>> set the name of threads not created by the JVM. The >>>> fact >>>> >>> that the >>>> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >>>> thread seems >>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is only >>>> working by >>>> >>> > >>>>>>>> accident for the initial attach, and can't be used >>>> for the >>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>> inconsistently >>>> >>> named at >>>> >>> > >>>>>>>> the native level. >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has to be >>>> >>> treated like >>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>> wants to >>>> name its >>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>> would not be >>>> >>> exporting >>>> >>> > >>>>>>>> a function from the JVM to do that - it would have to >>>> use the OS >>>> >>> > >>>>>>>> specific API's for that on a platform-by-platform >>>> basis. >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> Sorry. >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> David >>>> >>> > >>>>>>>> ----- >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> Thanks, >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> >>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>> >>> > >>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> Comments: >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>>> perform >>>> >>> different >>>> >>> > >>>>>>>>>> functions: >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs JVM_SetNativeThreadName >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> - The first function applies to the current >>>> thread, the >>>> >>> second >>>> >>> > >>>>>>>>>> one a >>>> >>> > >>>>>>>>>> specific java thread. >>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>>> somewhere >>>> >>> about >>>> >>> > >>>>>>>>>> what >>>> >>> > >>>>>>>>>> the new function does. >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to >>>> (void*) >>>> >>> > >>>>>>>>>> instead of >>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>> overwriteifn->GetCreatedJavaVMs >>>> >>> used at >>>> >>> > >>>>>>>>>> line 730 >>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>>> the cast >>>> >>> on the >>>> >>> > >>>>>>>>>> same >>>> >>> > >>>>>>>>>> line as dlsym... >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> $.02, Roger >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> >>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>>>>> That is an interesting question which I haven't >>>> had >>>> time to >>>> >>> > >>>>>>>>>>>> check - >>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>> JNI-attached >>>> >>> thread >>>> >>> > >>>>>>>>>>>> then >>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>> suggestion >>>> >>> should >>>> >>> > >>>>>>>>>>>> work >>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>> treatment of >>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >>>> confirmed >>>> >>> native >>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>> >>> > >>>>>>>>>>> --------- >>>> >>> > >>>>>>>>>>> public class Sleep{ >>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>> Exception{ >>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>> >>> > >>>>>>>>>>> } >>>> >>> > >>>>>>>>>>> } >>>> >>> > >>>>>>>>>>> --------- >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>> don't like >>>> >>> > >>>>>>>>>>>> exposing >>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's comment. >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> >>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>> >>> > >>>>>>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>>> thread >>>> >>> name, and JLI >>>> >>> > >>>>>>>>>>>>>>> uses it >>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>> >>> > >>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>>> >>> core-libs will >>>> >>> > >>>>>>>>>>>>>> need to >>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular Kumar) - >>>> now cc'd. >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> Thanks! >>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>> >>> Thread.setName >>>> >>> > >>>>>>>>>>>>>> rather >>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>> hotspot changes >>>> >>> > >>>>>>>>>>>>>> needed in >>>> >>> > >>>>>>>>>>>>>> that case. >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>> Thread#setName() in >>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>>> which is >>>> >>> why the >>>> >>> > >>>>>>>>>>>> native >>>> >>> > >>>>>>>>>>>> name is not set. >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI attached >>>> thread. >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> That is an interesting question which I haven't >>>> had >>>> time to >>>> >>> > >>>>>>>>>>>> check - >>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>> JNI-attached >>>> >>> thread >>>> >>> > >>>>>>>>>>>> then >>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>> suggestion >>>> >>> should >>>> >>> > >>>>>>>>>>>> work >>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>> treatment of >>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>> don't like >>>> >>> > >>>>>>>>>>>> exposing >>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>> David >>>> >>> > >>>>>>>>>>>> ----- >>>> >>> > >>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>> function to set >>>> >>> native >>>> >>> > >>>>>>>>>>>>> thread name. >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> [1] >>>> >>> > >>>>>>>>>>>>> >>>> >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>>> David >>>> >>> > >>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as well >>>> ... >>>> >>> > >>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>> >>> > >>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have >>>> been on >>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>> >>> > >>>>>>>>>>>>>>>> This >>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be correct >>>> as we >>>> >>> do not >>>> >>> > >>>>>>>>>>>>>>>> set the >>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >>>> includes the >>>> >>> > >>>>>>>>>>>>>>>> "main" >>>> >>> > >>>>>>>>>>>>>>>> thread. >>>> >>> > >>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>> David >>>> >>> > >>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga wrote: >>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>> >>> > >>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>> >>> > >>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>> >>>> >>> >>: >>>> >>> > >>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>> >>> > >>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>> >>> > >>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>> >>> > >>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa Suenaga >>>> wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa Suenaga >>>> wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>> >>> >>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>>> >>> >>>: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>> Suenaga wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>>> >>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>>> >>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>> >>>> >>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>> >>>> >>> >>>>: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't set it: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>> a/src/share/vm/runtime/thread.cpp Thu >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>> b/src/share/vm/runtime/thread.cpp Thu >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>> >>> JavaThread(); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> main_thread->initialize_thread_current(); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>> >>> main_thread->set_native_thread_name("main"); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>> >>> set_active_handles >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> main_thread->record_stack_base_and_size(); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>> something? >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same to >>>> thread >>>> >>> name in >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>> setName(). >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java app, >>>> native >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is >>>> already >>>> >>> starte >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >>>> thrrad name >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>> something like >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- a/src/share/vm/runtime/thread.cpp >>>> Tue >>>> >>> Mar 29 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ b/src/share/vm/runtime/thread.cpp >>>> Wed >>>> >>> Mar 30 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>> create_initial_thread(Handle >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>> initial_thread_name = >>>> >>> "main"; >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>> (THREAD, k); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> klass->allocate_instance_handle(CHECK_NULL); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> java_lang_Thread::set_thread(thread_oop(), >>>> >>> thread); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> java_lang_Thread::set_priority(thread_oop(), >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> java_lang_String::create_from_str("main", >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> thread->set_native_thread_name(initial_thread_name); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>> thread_oop, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself >>>> 'java' and >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the process >>>> (and >>>> >>> thus >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the process >>>> is not >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>> >>> JavaThread. So I >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>>> thread. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>> anyhow, since >>>> >>> we want >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread name >>>> might >>>> >>> have >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' | >>>> head -4 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like >>>> 'Java Main >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java >>>> >>> launcher - e.g. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main thread >>>> name, >>>> >>> I think >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa >>>> >>> Suenaga wrote: >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>>> thread >>>> >>> name via >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >>>> have it. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native name, >>>> and main >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >>>> should have >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you >>>> review it? >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>> >>> > >>>>>>>>>> >>>> >>> > >>>> >>> >>>> > From david.holmes at oracle.com Mon Apr 25 05:47:59 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Apr 2016 15:47:59 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571B7796.8030905@gmail.com> References: <56F3F90D.9010408@gmail.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> Message-ID: <571DAF8F.1080305@oracle.com> Looks good to me. I'll sponsor this "tomorrow". Thanks, David On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: > Hi Kumar, > > Thank you for your comment! > I've fixed them and uploaded new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ > > > Thanks, > > Yasumasa > > > On 2016/04/23 1:14, Kumar Srinivasan wrote: >> >> Also a couple of minor suggestions: >> >> - * Set native thread name as possible. >> + * Set native thread name if possible. >> >> >> + /* >> - * We can clear pending exception because exception at this point >> - * is not critical. >> + */ >> >> + /* >> + * Clear non critical pending exceptions at this point. >> + */ >> >> Thanks >> Kumar >> >>> Hi, >>> >>> This is in the wrong place: >>> >>> 1715 if ((*env)->ExceptionOccurred(env)) { >>> 1716 /* >>> 1717 * We can clear pending exception because exception at >>> this point >>> 1718 * is not critical. >>> 1719 */ >>> 1720 (*env)->ExceptionClear(env); >>> 1721 } >>> >>> This above needs to be after >>> 391 SetNativeThreadName(env, "main"); >>> 392 >>> >>> Here is why, supposing 1704 through 1711, returns a NULL, >>> but have also encountered an exception. In which case >>> the method SetNativeThreadName will return to the caller, as >>> if nothing has happened, because NULL_CHECK simply checks for NULL >>> and returns to the caller. This will cause the caller to enter >>> the VM with exceptions. >>> >>> Kumar >>> >>> >>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> I don't think we need to report the exception, but can just ignore >>>>> it. Either way we have to clear the exception before continuing. >>>> >>>> I've fixed it in new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/22 15:33, David Holmes wrote: >>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> I have uploaded webrev.04 as below. >>>>>> Could you review again? >>>>>> >>>>>> > - hotspot: >>>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>> >>>>> Looks fine. >>>>> >>>>>> > >>>>>> > - jdk: >>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>> >>>>> As per private email (but repeated here on the record) in java.c: >>>>> >>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>> 1716 JLI_ReportExceptionDescription(env); >>>>> 1717 } >>>>> >>>>> I don't think we need to report the exception, but can just ignore >>>>> it. Either way we have to clear the exception before continuing. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>> >: >>>>>> > >>>>>> > Hi David, >>>>>> > >>>>>> > Thank you for your comment. >>>>>> > I uploaded new webrev. Could you review again? >>>>>> > >>>>>> > - hotspot: >>>>>> > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>> > >>>>>> > - jdk: >>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>> > >>>>>> > >>>>>> >> That aside I'm not sure why you do this so late in the process, I >>>>>> would have done it immediately after here: >>>>>> > >>>>>> > >>>>>> > I think that native thread name ("main") should be set just before >>>>>> > main method call. >>>>>> > However, main thread is already started, so I moved it as you >>>>>> suggested. >>>>>> > >>>>>> > >>>>>> >> One thing I dislike about the current structure is that we >>>>>> have to >>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>> calls >>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>> char* ! >>>>>> > >>>>>> > >>>>>> > SoI proposed to export new JVM function to set native thread >>>>>> name with >>>>>> > const char *. >>>>>> > >>>>>> > >>>>>> > Thanks, >>>>>> > >>>>>> > Yasumasa >>>>>> > >>>>>> > >>>>>> > >>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>> >> >>>>>> >> Hi Yasumasa, >>>>>> >> >>>>>> >> Thanks for persevering with this to get it into the current form. >>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>> >> >>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>> >>> >>>>>> >>> Hi Gerard, >>>>>> >>> >>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>> >>>>>> >>> >>>>> >>: >>>>>> >>> > >>>>>> >>> > hi Yasumasa, >>>>>> >>> > >>>>>> >>> > Nice work. I have 2 questions: >>>>>> >>> > >>>>>> >>> > ======== >>>>>> >>> > File: java.c >>>>>> >>> > >>>>>> >>> > #1 Shouldn?t we be checking for >>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>> >>> after every single JNI call? In this example instead of >>>>>> NULL_CHECK, >>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>> >>> >>>>>> >>> It is not critical if we encounter error at JNI function call >>>>>> because >>>>>> >>> we cannot set native thread name only. >>>>>> >>> So I think that we do not need to leave from launcher process. >>>>>> >> >>>>>> >> >>>>>> >> I agree we do not need to abort if an exception occurs (and in >>>>>> fact >>>>>> I don't think an exception is even possible from this code), but we >>>>>> should ensure any pending exception is cleared before any futher JNI >>>>>> calls might be made. Note that NULL_CHECK is already used extensively >>>>>> throughout the launcher code - so if this usage is wrong then it >>>>>> is all >>>>>> wrong! More on this code below ... >>>>>> >> >>>>>> >> Other comments: >>>>>> >> >>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>> >> >>>>>> >> Please add a comment to the method now that you removed the >>>>>> internal >>>>>> comment: >>>>>> >> >>>>>> >> // Sets the native thread name for a JavaThread. If specifically >>>>>> >> // requested JNI-attached threads can also have their native >>>>>> name set; >>>>>> >> // otherwise we do not modify JNI-attached threads as it may >>>>>> interfere >>>>>> >> // with the application that created them. >>>>>> >> >>>>>> >> --- >>>>>> >> >>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>> >> >>>>>> >> Please add the following comments: >>>>>> >> >>>>>> >> + // Don't modify JNI-attached threads >>>>>> >> setNativeName(name, false); >>>>>> >> >>>>>> >> + // May be called directly via JNI or reflection (when >>>>>> permitted) to >>>>>> >> + // allow JNI-attached threads to set their native name >>>>>> >> private native void setNativeName(String name, boolean >>>>>> allowAttachedThread); >>>>>> >> >>>>>> >> --- >>>>>> >> >>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>> >> >>>>>> >> 328 #define LEAVE() \ >>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>> >> >>>>>> >> I was going to suggest this be set later, but realized we have >>>>>> to be >>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>> >> >>>>>> >> + /* Set native thread name. */ >>>>>> >> + SetNativeThreadName(env, "main"); >>>>>> >> >>>>>> >> The comment is redundant given the name of the method. That aside >>>>>> I'm not sure why you do this so late in the process, I would have >>>>>> done >>>>>> it immediately after here: >>>>>> >> >>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>> >> 388 exit(1); >>>>>> >> 389 } >>>>>> >> + SetNativeThreadName(env, "main"); >>>>>> >> >>>>>> >> >>>>>> >> + /** >>>>>> >> + * Set native thread name as possible. >>>>>> >> + */ >>>>>> >> >>>>>> >> Other than the as->if change I'm unclear where the "possible" bit >>>>>> comes into play - why would it not be possible? >>>>>> >> >>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>> "java/lang/Thread")); >>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>> (*env)->GetStaticMethodID(env, >>>>>> cls, >>>>>> >> 1707 "currentThread", >>>>>> "()Ljava/lang/Thread;")); >>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>> >> 1709 currentThreadID)); >>>>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, >>>>>> cls, >>>>>> >> 1711 "setNativeName", >>>>>> "(Ljava/lang/String;Z)V")); >>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>> name)); >>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>> setNativeNameID, >>>>>> >> 1714 nameString, JNI_TRUE); >>>>>> >> >>>>>> >> As above NULL_CHECK is fine here, but we should check for and >>>>>> clear >>>>>> any pending exception after CallVoidMethod. >>>>>> >> >>>>>> >> One thing I dislike about the current structure is that we >>>>>> have to >>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>> calls >>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>> char* ! >>>>>> Overall I wonder about the affect on startup cost. But if there is an >>>>>> issue we can revisit this. >>>>>> >> >>>>>> >> Thanks, >>>>>> >> David >>>>>> >> ----- >>>>>> >> >>>>>> >> >>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set >>>>>> native >>>>>> thread >>>>>> >>> name if possible.? not "Set native thread name as possible.?? >>>>>> >>> >>>>>> >>> Sorry for my bad English :-) >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> >>>>>> >>> Yasumasa >>>>>> >>> >>>>>> >>> > cheers >>>>>> >>> > >>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>> >>>>>> >>> >> wrote: >>>>>> >>> > > >>>>>> >>> > > Hi David, >>>>>> >>> > > >>>>>> >>> > > I uploaded new webrev: >>>>>> >>> > > >>>>>> >>> > > - hotspot: >>>>>> >>> > > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>> >>> > > >>>>>> >>> > > - jdk: >>>>>> >>> > > >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > >> it won't work unless you change the semantics of >>>>>> setName so I'm >>>>>> >>> not sure what you were thinking here. To take advantage of an >>>>>> arg >>>>>> taking >>>>>> >>> JVM_SetNativThreadName you would need to call it directly as >>>>>> no Java >>>>>> >>> code will call it . ??? >>>>>> >>> > > >>>>>> >>> > > I added a flag for setting native thread name to >>>>>> JNI-attached >>>>>> thread. >>>>>> >>> > > This change can set native thread name if main thread >>>>>> changes to >>>>>> >>> JNI-attached thread. >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > Thanks, >>>>>> >>> > > >>>>>> >>> > > Yasumasa >>>>>> >>> > > >>>>>> >>> > > >>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>> >>> > >>> Hi David, >>>>>> >>> > >>> >>>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>>> considered a >>>>>> >>> > >>>> regression that setName stops setting the native thread >>>>>> main, even >>>>>> >>> > >>>> though we never really intended it to work in the >>>>>> first place. >>>>>> >>> :( Such >>>>>> >>> > >>>> a change needs to go through CCC. >>>>>> >>> > >>> >>>>>> >>> > >>> I understood. >>>>>> >>> > >>> Can I send CCC request? >>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>>> >>> > >> >>>>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>>>> sponsor for >>>>>> >>> that. But at this stage I don't think I agree with the >>>>>> proposed change >>>>>> >>> because of the change in behaviour - there's no way to >>>>>> restore the >>>>>> >>> "broken" behaviour. >>>>>> >>> > >> >>>>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 >>>>>> [1]. >>>>>> >>> > >> >>>>>> >>> > >> Okay we can do that. >>>>>> >>> > >> >>>>>> >>> > >>> >>>>>> >>> > >>>> Further, we expect the launcher to use the supported JNI >>>>>> >>> interface (as >>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>> interface that >>>>>> >>> exists for >>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>> >>> > >>> >>>>>> >>> > >>> I think that we do not use JVM interface if we add new >>>>>> method in >>>>>> >>> > >>> LauncherHelper as below: >>>>>> >>> > >>> ---------------- >>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>> >>> > >>> >>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> >>> > >>> --- >>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>> >>> > >>> +++ >>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>> >>> > >>> else >>>>>> >>> > >>> return md.toNameAndVersion() + " (" + loc >>>>>> + ")"; >>>>>> >>> > >>> } >>>>>> >>> > >>> + >>>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>> >>> > >>> + } >>>>>> >>> > >> >>>>>> >>> > >> You could also make that call via JNI directly, so not >>>>>> sure the >>>>>> >>> helper adds much here. But it won't work unless you change the >>>>>> semantics >>>>>> >>> of setName so I'm not sure what you were thinking here. To take >>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>>>> need to >>>>>> call >>>>>> >>> it directly as no Java code will call it . ??? >>>>>> >>> > >> >>>>>> >>> > >> David >>>>>> >>> > >> ----- >>>>>> >>> > >> >>>>>> >>> > >>> } >>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>> src/java.base/share/native/libjli/java.c >>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>>>>> Apr 13 >>>>>> 14:19:30 >>>>>> >>> > >>> 2016 +0000 >>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>>>>> Apr 16 >>>>>> 11:25:53 >>>>>> >>> > >>> 2016 +0900 >>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>>>>> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>> *name); >>>>>> >>> > >>> >>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>> >>> > >>> >>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>> >>> > >>> */ >>>>>> >>> > >>> #define LEAVE() \ >>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>> >>> > >>> do { \ >>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) >>>>>> { \ >>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>> >>> > >>> >>>>>> >>> > >>> + /* Set native thread name. */ >>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>> >>> > >>> + >>>>>> >>> > >>> /* Invoke main method. */ >>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>> mainArgs); >>>>>> >>> > >>> >>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>> >>> > >>> joptString); >>>>>> >>> > >>> } >>>>>> >>> > >>> >>>>>> >>> > >>> +/** >>>>>> >>> > >>> + * Set native thread name as possible. >>>>>> >>> > >>> + */ >>>>>> >>> > >>> +static void >>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>> >>> > >>> +{ >>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>> >>> > >>> + jstring nameString; >>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>> name)); >>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>> setNativeThreadNameID, >>>>>> >>> > >>> nameString); >>>>>> >>> > >>> +} >>>>>> >>> > >>> + >>>>>> >>> > >>> /* >>>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>> >>> > >>> */ >>>>>> >>> > >>> ---------------- >>>>>> >>> > >>> >>>>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>> >>> > >>> >>>>>> >>> > >>>> However this is still a change to the exported JVM >>>>>> interface and so >>>>>> >>> > >>>> has to be approved. >>>>>> >>> > >>> >>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>> >>> > >>> >>>>>> >>> > >>> >>>>>> >>> > >>> Thanks, >>>>>> >>> > >>> >>>>>> >>> > >>> Yasumasa >>>>>> >>> > >>> >>>>>> >>> > >>> >>>>>> >>> > >>> [1] >>>>>> >>> > >>> >>>>>> >>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>> >>>>>> >>> > >>> >>>>>> >>> > >>> >>>>>> >>> > >>> >>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>> Hi David, >>>>>> >>> > >>>>> >>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>> for main >>>>>> >>> thread and >>>>>> >>> > >>>>>> JNI attached threads >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> >>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>> itself as >>>>>> >>> setName >>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>> thread. >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> I know. >>>>>> >>> > >>>> >>>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>>> considered a >>>>>> >>> > >>>> regression that setName stops setting the native thread >>>>>> main, even >>>>>> >>> > >>>> though we never really intended it to work in the >>>>>> first place. >>>>>> >>> :( Such >>>>>> >>> > >>>> a change needs to go through CCC. >>>>>> >>> > >>>> >>>>>> >>> > >>>>> I checked changeset history. >>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>> JDK-7098194, >>>>>> and it is >>>>>> >>> > >>>>> backported JDK 8. >>>>>> >>> > >>>> >>>>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>>>> >>> > >>>> >>>>>> >>> > >>>>> However, this function seems to be called from >>>>>> >>> Thread#setNativeName() >>>>>> >>> > >>>>> only. >>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private method. >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>> >>> JVM_SetNativeThreadName() >>>>>> >>> > >>>>> for force setting. >>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>> >>> > >>>>> However, this function is NOT public, so I think we can >>>>>> add one >>>>>> >>> more >>>>>> >>> > >>>>> argument. >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> What do you think about this? >>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>> from Java >>>>>> >>> launcher. >>>>>> >>> > >>>> >>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>> really at >>>>>> >>> issue. Yes >>>>>> >>> > >>>> we would add another arg to the JVM function to allow >>>>>> it to >>>>>> apply to >>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>> reflect that >>>>>> >>> not just >>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>> exported JVM >>>>>> >>> interface >>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>> launcher to >>>>>> >>> use the >>>>>> >>> > >>>> supported JNI interface (as other processes would), >>>>>> not the >>>>>> internal >>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>> communicate >>>>>> >>> with the >>>>>> >>> > >>>> JVM. >>>>>> >>> > >>>> >>>>>> >>> > >>>> David >>>>>> >>> > >>>> ----- >>>>>> >>> > >>>> >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> Thanks, >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> Yasumasa >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> >>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>> Hi David, >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>>>>> being a >>>>>> >>> JNI-attached >>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>> for main >>>>>> >>> thread and >>>>>> >>> > >>>>>> JNI attached threads >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>> itself as >>>>>> >>> setName >>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>> thread. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>> >>> > >>>>>>> --------------- >>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 >>>>>> 13:31:11 >>>>>> >>> 2016 +0200 >>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 >>>>>> 17:50:10 >>>>>> >>> 2016 +0900 >>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization >>>>>> is complete >>>>>> >>> - nop if >>>>>> >>> > >>>>>>> no agents. >>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>> >>> > >>>>>>> + >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> I think we can do this straight after the JavaThread >>>>>> constructor. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>> tracing >>>>>> >>> > >>>>>>> backend."); >>>>>> >>> > >>>>>>> } >>>>>> >>> > >>>>>>> --------------- >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>>> If it wants to name its native threads then it is >>>>>> free >>>>>> to do so, >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change >>>>>> native >>>>>> >>> thread name >>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>> >>> > >>>>>>> However, I think that it should be changed if Java >>>>>> developer >>>>>> >>> calls >>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>> >>> > >>>>>>> It is not the same of changing native thread name at >>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>> SetNativeThreadName() as >>>>>> below. >>>>>> >>> > >>>>>>> What do you think about this? >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>>>> threads was a >>>>>> >>> > >>>>>> deliberate one** - this functionality originated >>>>>> with the OSX >>>>>> >>> port and >>>>>> >>> > >>>>>> it was reported that the initial feedback with this >>>>>> feature was to >>>>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>>>> been set by >>>>>> >>> the host >>>>>> >>> > >>>>>> process. If we do as you propose then we will just >>>>>> have an >>>>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>>>> does my >>>>>> >>> native thread >>>>>> >>> > >>>>>> only have a name if I call >>>>>> cur.setName(cur.getName()) ?" >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> ** If you follow the bugs and related discussions on >>>>>> this, the >>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>> thread only, >>>>>> >>> non-JNI >>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>> were supposed >>>>>> >>> to be >>>>>> >>> > >>>>>> documented in the release notes - but as far as I >>>>>> can see >>>>>> that >>>>>> >>> never >>>>>> >>> > >>>>>> happened. :( >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> My position on this remains that if it is desirable >>>>>> for >>>>>> the main >>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native names >>>>>> then the >>>>>> >>> > >>>>>> launcher needs to be setting them using the available >>>>>> platform >>>>>> >>> APIs. >>>>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by >>>>>> the VM >>>>>> >>> code for >>>>>> >>> > >>>>>> this - due to the need to verify API availability. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>> Thread.setName would >>>>>> >>> have to go >>>>>> >>> > >>>>>> through our CCC process I think. But a change in >>>>>> the launcher >>>>>> >>> would >>>>>> >>> > >>>>>> not. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> Sorry. >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>> David >>>>>> >>> > >>>>>> ----- >>>>>> >>> > >>>>>> >>>>>> >>> > >>>>>>> --------------- >>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 >>>>>> 13:31:11 >>>>>> >>> 2016 +0200 >>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 >>>>>> 17:50:10 >>>>>> >>> 2016 +0900 >>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>> java_lang_Thread::thread(java_thread); >>>>>> >>> > >>>>>>> // Thread naming only supported for the current >>>>>> thread, >>>>>> >>> doesn't >>>>>> >>> > >>>>>>> work >>>>>> >>> > >>>>>>> for >>>>>> >>> > >>>>>>> // target threads. >>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>> >>> !thr->has_attached_via_jni()) { >>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>> thread to avoid >>>>>> >>> stepping >>>>>> >>> > >>>>>>> // on other programs >>>>>> >>> > >>>>>>> const char *thread_name = >>>>>> >>> > >>>>>>> >>>>>> >>> >>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>> >>> > >>>>>>> --------------- >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> Thanks, >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> Yasumasa >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> >>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>>>> Roger, >>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> David, >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>>>> don't like >>>>>> >>> > >>>>>>>>>>>> exposing >>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>> initializing VM >>>>>> (before >>>>>> >>> > >>>>>>>>> calling >>>>>> >>> > >>>>>>>>> main method), >>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>> AttachCurrentThread(). >>>>>> So we >>>>>> >>> can't >>>>>> >>> > >>>>>>>>> set >>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier this >>>>>> morning. >>>>>> >>> Which, >>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise >>>>>> here that >>>>>> >>> we don't >>>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>>>> The fact >>>>>> >>> that the >>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >>>>>> thread seems >>>>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is >>>>>> only >>>>>> working by >>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>> used for the >>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>> inconsistently >>>>>> >>> named at >>>>>> >>> > >>>>>>>> the native level. >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has >>>>>> to be >>>>>> >>> treated like >>>>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>>>> wants to >>>>>> name its >>>>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>>>> would not be >>>>>> >>> exporting >>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>> have to >>>>>> use the OS >>>>>> >>> > >>>>>>>> specific API's for that on a platform-by-platform >>>>>> basis. >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> Sorry. >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> David >>>>>> >>> > >>>>>>>> ----- >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>> >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> >>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>> >>> > >>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> Comments: >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>>>>> perform >>>>>> >>> different >>>>>> >>> > >>>>>>>>>> functions: >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>> JVM_SetNativeThreadName >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> - The first function applies to the current >>>>>> thread, the >>>>>> >>> second >>>>>> >>> > >>>>>>>>>> one a >>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>>>>> somewhere >>>>>> >>> about >>>>>> >>> > >>>>>>>>>> what >>>>>> >>> > >>>>>>>>>> the new function does. >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 casts to >>>>>> (void*) >>>>>> >>> > >>>>>>>>>> instead of >>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>> overwriteifn->GetCreatedJavaVMs >>>>>> >>> used at >>>>>> >>> > >>>>>>>>>> line 730 >>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>>>>> the cast >>>>>> >>> on the >>>>>> >>> > >>>>>>>>>> same >>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>> haven't had >>>>>> time to >>>>>> >>> > >>>>>>>>>>>> check - >>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>> JNI-attached >>>>>> >>> thread >>>>>> >>> > >>>>>>>>>>>> then >>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>> suggestion >>>>>> >>> should >>>>>> >>> > >>>>>>>>>>>> work >>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>> treatment of >>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >>>>>> confirmed >>>>>> >>> native >>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>> >>> > >>>>>>>>>>> --------- >>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>>>> Exception{ >>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>> >>> > >>>>>>>>>>> } >>>>>> >>> > >>>>>>>>>>> } >>>>>> >>> > >>>>>>>>>>> --------- >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>>>> don't like >>>>>> >>> > >>>>>>>>>>>> exposing >>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>> comment. >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>>>>> thread >>>>>> >>> name, and JLI >>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>> >>> > >>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>>>>> >>> core-libs will >>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>> Kumar) - >>>>>> now cc'd. >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>>> >>> Thread.setName >>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>>>> hotspot changes >>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>> Thread#setName() in >>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>>>>> which is >>>>>> >>> why the >>>>>> >>> > >>>>>>>>>>>> native >>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>> attached thread. >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>> haven't had >>>>>> time to >>>>>> >>> > >>>>>>>>>>>> check - >>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>> JNI-attached >>>>>> >>> thread >>>>>> >>> > >>>>>>>>>>>> then >>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>> suggestion >>>>>> >>> should >>>>>> >>> > >>>>>>>>>>>> work >>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>> treatment of >>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about this. I >>>>>> don't like >>>>>> >>> > >>>>>>>>>>>> exposing >>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>> David >>>>>> >>> > >>>>>>>>>>>> ----- >>>>>> >>> > >>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>> function to set >>>>>> >>> native >>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>>> David >>>>>> >>> > >>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>>>> well ... >>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry have >>>>>> been on >>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>>>> correct >>>>>> as we >>>>>> >>> do not >>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >>>>>> includes the >>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>>>> wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer :-) >>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>> >>>>>> >>> >>: >>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>> Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>> Suenaga >>>>>> wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>> >>> >>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>> >>> >>>: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>>>> Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>> >>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>> >>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>> >>>>>> >>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>> >>>>>> >>> >>>>> >>>>: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't >>>>>> set it: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = new >>>>>> >>> JavaThread(); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> main_thread->initialize_thread_current(); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>> >>> set_active_handles >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> main_thread->record_stack_base_and_size(); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> >>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>>>> something? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same >>>>>> to thread >>>>>> >>> name in >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>>>> setName(). >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java >>>>>> app, >>>>>> native >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is >>>>>> already >>>>>> >>> starte >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >>>>>> thrrad name >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>>> something like >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>> a/src/share/vm/runtime/thread.cpp >>>>>> Tue >>>>>> >>> Mar 29 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>> b/src/share/vm/runtime/thread.cpp >>>>>> Wed >>>>>> >>> Mar 30 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>> create_initial_thread(Handle >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>> initial_thread_name = >>>>>> >>> "main"; >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>> (THREAD, k); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>> >>> thread); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > thread->set_threadObj(thread_oop()); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> java_lang_String::create_from_str("main", >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>>>> thread_oop, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name itself >>>>>> 'java' and >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>>>> process >>>>>> (and >>>>>> >>> thus >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>>>> process >>>>>> is not >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread with >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>>>> >>> JavaThread. So I >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>>>>> thread. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>> anyhow, since >>>>>> >>> we want >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread >>>>>> name >>>>>> might >>>>>> >>> have >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' >>>>>> | head -4 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something like >>>>>> 'Java Main >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a Java >>>>>> >>> launcher - e.g. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>>>> thread >>>>>> name, >>>>>> >>> I think >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, Yasumasa >>>>>> >>> Suenaga wrote: >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>>>>> thread >>>>>> >>> name via >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >>>>>> have it. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native >>>>>> name, >>>>>> and main >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >>>>>> should have >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could you >>>>>> review it? >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>> > >>>>>>>>>> >>>>>> >>> > >>>>>> >>> >>>>>> >>> >> From HORII at jp.ibm.com Mon Apr 25 07:09:30 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Mon, 25 Apr 2016 16:09:30 +0900 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <571A1FA3.9030006@oracle.com> References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> Message-ID: <201604250709.u3P79iOJ024100@d19av07.sagamino.japan.ibm.com> Hi David, Thank you for your comments and questions. > 1. Are the current cmpxchg semantics exactly the same as > memory_order_seq_cst? This is very good question.. I guess, cmpxchg needs a more conservative constraint for memory ordering than C++11, to add sync after a compare-and-exchange operation. Could someone give comments or thoughts? memory_order_seq_cst is defined as "Any operation with this memory order is both an acquire operation and a release operation, plus a single total order exists in which all threads observe all modifications (see below) in the same order." (http://en.cppreference.com/w/cpp/atomic/memory_order) In my environment, g++ and xlc generate following assemblies on ppc64le. (interestingly, they generates the same assemblies for any memory_order) g++ (4.9.2) 100008a4: ac 04 00 7c sync 100008a8: 28 50 20 7d lwarx r9,0,r10 100008ac: 00 18 09 7c cmpw r9,r3 100008b0: 0c 00 c2 40 bne- 100008bc 100008b4: 2d 51 80 7c stwcx. r4,0,r10 100008b8: f0 ff c2 40 bne- 100008a8 100008bc: 2c 01 00 4c isync xlc (13.1.3) 10000888: ac 04 00 7c sync 1000088c: 28 28 c0 7c lwarx r6,0,r5 10000890: 40 00 26 7c cmpld r6,r0 10000894: 0c 00 82 40 bne 100008a0 10000898: 2d 29 80 7c stwcx. r4,0,r5 1000089c: f0 ff e2 40 bne+ 1000088c 100008a0: 2c 01 00 4c isync On the other hand, the current OpenJDK generates following assemblies. 508: ac 04 00 7c sync 50c: 00 00 5c e9 ld r10,0(r28) 510: 00 50 3b 7c cmpd r27,r10 514: 1c 00 c2 40 bne- 530 518: a8 40 5c 7d ldarx r10,r28,r8 51c: 00 50 3b 7c cmpd r27,r10 520: 10 00 c2 40 bne- 530 524: ad 41 3c 7d stdcx. r9,r28,r8 528: f0 ff c2 40 bne- 518 52c: ac 04 00 7c sync 530: 00 50 bb 7f ... Though we can ignore 50c-514 (because they are a duplicated guard condition), the last sync instruction (52c) makes cmpxchg more strict than memory_order_seq_cst. In some cases, the last sync is necessary when this thread must be able to read all of the changes in the other threads while executing from 508 to 530 (that processes compare-and-exchange). > 2. Has there been a discussion already, establishing that the modified > GC code can indeed use memory_order_relaxed? Otherwise who is > postulating that and based on what evidence? Volker and his colleagues have investigated the current GC codes according to this. http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019079.html However, I believe, we need comments of other GC experts to change the shared codes. Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo David Holmes wrote on 04/22/2016 21:57:07: > From: David Holmes > To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- > dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net > Cc: Tim Ellison , ppc-aix-port-dev at openjdk.java.net > Date: 04/22/2016 21:58 > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > Hi Hiroshi, > > Two initial questions: > > 1. Are the current cmpxchg semantics exactly the same as > memory_order_seq_cst? > > 2. Has there been a discussion already, establishing that the modified > GC code can indeed use memory_order_relaxed? Otherwise who is > postulating that and based on what evidence? > > Missing memory barriers have caused very difficult to track down bugs in > the past - very rare race conditions. So any relaxation here has to be > done with extreme confidence. > > Thanks, > David > > On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: > > Dear all: > > > > Can I please request reviews for the following change? > > > > Code change: > > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ > > (I initially created and Martin enhanced so much) > > > > This change follows the discussion started from this mail. > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > April/018960.html > > > > Description: > > This change provides relaxed compare-and-exchange by introducing > > similar semantics of C++ atomic memory operators, enum memory_order. > > As described in atomic_linux_ppc.inline.hpp, the current implementation of > > cmpxchg is fence_cmpxchg_acquire. This implementation is useful for > > general purposes because twice calls of sync before and after cmpxchg will > > provide strict consistency. However, they sometimes cause overheads > > because > > sync instructions are very expensive in the current POWER chip design. > > In addition, for the other platforms, such as aarch64, this strict > > semantics > > may cause some overheads (according to the Andrew's mail). > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > April/019073.html > > > > With this change, callers can explicitly specify constraints of memory > > ordering > > for cmpxchg with an additional parameter, memory_order order. > > > > typedef enum memory_order { > > memory_order_relaxed, > > memory_order_consume, > > memory_order_acquire, > > memory_order_release, > > memory_order_acq_rel, > > memory_order_seq_cst > > } memory_order; > > > > Because the default value of the parameter is memory_order_seq_cst, > > existing codes can use the same semantics of cmpxchg without any > > modification. The relaxed cmpxchg is implemented only on ppc > > in this changeset. Therefore, the behavior on the other platforms will > > not be changed with this changeset. > > > > In addition, with the new parameter of cmpxchg, this change improves > > performance of copy_to_survivor in the parallel GC. > > copy_to_survivor changes forward pointers by using cmpxchg. This > > operation doesn't require any sync instructions. A pointer is changed > > at most once in a GC and when cmpxchg fails, the latest pointer is > > available for the caller. cas_set_mark and cas_forward_to are extended > > with an additional memory_order parameter as cmpxchg and copy_to_survivor > > uses memory_order_relaxed to modify the forward pointers. > > > > Summary of source code changes: > > > > * src/share/vm/runtime/atomic.hpp > > - Defines enum memory_order and adds a parameter to cmpxchg. > > > > * src/share/vm/runtime/atomic.cpp > > * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > > * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > > * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > > * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > > * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > > * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > > * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > > * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > > * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > > - Added a parameter for each cmpxchg function to follow > > the change of atomic.hpp. Their implementations are not changed. > > > > * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > > * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > > - Added a parameter for each cmpxchg function to follow > > the change of atomic.hpp. In addition, implementations > > are changed corresponding to the specified memory_order. > > > > * src/share/vm/oops/oop.hpp > > * src/share/vm/oops/oop.inline.hpp > > - Add a memory_order parameter to use relaxed cmpxchg in > > cas_set_mark and cas_forward_to. > > > > * src/share/vm/gc/parallel/psPromotionManager.cpp > > * src/share/vm/gc/parallel/psPromotionManager.inline.hpp > > > > Martin tested this changeset on linuxx86_64, linuxppc64le and > > darwinintel64. > > Though more time is needed to test on the other platform, we would like to > > ask > > reviews and start discussion on this changeset. > > I also tested this changeset with SPECjbb2013 and confirmed that gc pause > > time > > is reduced. > > > > Regards, > > Hiroshi > > ----------------------- > > Hiroshi Horii, Ph.D. > > IBM Research - Tokyo > > > > > From jini.george at oracle.com Mon Apr 25 08:59:16 2016 From: jini.george at oracle.com (Jini George) Date: Mon, 25 Apr 2016 01:59:16 -0700 (PDT) Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: References: Message-ID: Adding hotspot-runtime as well since this includes runtime changes. Regards, Jini. From: Jini George Sent: Monday, April 25, 2016 1:23 PM To: serviceability-dev at openjdk.java.net Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync Hello, Please review the fix for the JVMTI bug: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync https://bugs.openjdk.java.net/browse/JDK-8043571 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8043571/webrev/ (Thanks to Dmitry for hosting this webrev). The changes here are built on top of the changes which were done for JDK-8041934 (https://bugs.openjdk.java.net/browse/JDK-8041934). The issue was that JVMTI's internal notion of the number of stack frames was getting messed up. While single stepping or when method entry/exit events are enabled, the compiled stack frames except for the native wrapper frames are reverted to interpreter frames. And for the exit of these native wrapper frames, there was no JVMTI method exit event generated - which, in turn messed up JVMTI's internal bookkeeping. The changes done here in addition to generating method exit events in the native wrapper frames when interpreter mode is enabled, are to: 1. Decrement the current stack depth (to keep JVMTI's bookkeeping wrt the number of stack frames correct) 2. Avoid the code which tries to read the return value from the location corresponding to the interpreter generated native stub, which is an invalid location in this case. With these changes the jdi tests which were failing with -Xcomp pass now. Since, at this point, we are not reading in the native return value, I have created the issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8043571"JDK-8043571 (For JVMTI method exits from native wrapper frames, read in the native results from the correct location) to do so. Testing done: JPRT testsets: hotspot and SVC (with and without -Xcomp). I will be sending the changes for the JDK8 backport for this in a while, in a separate webrev. Thanks, - Jini Susan George From martin.doerr at sap.com Mon Apr 25 10:25:15 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 25 Apr 2016 10:25:15 +0000 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <201604250709.u3P79lDi013336@d19av08.sagamino.japan.ibm.com> References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79lDi013336@d19av08.sagamino.japan.ibm.com> Message-ID: Hi David and Hiroshi, thank you very much for this interesting question and analysis. I think we shouldn't better use an own enum (e.g. like AccessKind in library_call.cpp). Otherwise we'll get trouble when we switch to C++11. Would you agree? Would it be better to split this bug into 2 and discuss the cmpxchg interface change on the runtime list and the GC change on the gc list? Best regards, Martin From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] Sent: Montag, 25. April 2016 09:10 To: David Holmes Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Tim Ellison ; Volker Simonis ; Doerr, Martin ; Lindenmaier, Goetz Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 Hi David, Thank you for your comments and questions. > 1. Are the current cmpxchg semantics exactly the same as > memory_order_seq_cst? This is very good question.. I guess, cmpxchg needs a more conservative constraint for memory ordering than C++11, to add sync after a compare-and-exchange operation. Could someone give comments or thoughts? memory_order_seq_cst is defined as "Any operation with this memory order is both an acquire operation and a release operation, plus a single total order exists in which all threads observe all modifications (see below) in the same order." (http://en.cppreference.com/w/cpp/atomic/memory_order) In my environment, g++ and xlc generate following assemblies on ppc64le. (interestingly, they generates the same assemblies for any memory_order) g++ (4.9.2) 100008a4: ac 04 00 7c sync 100008a8: 28 50 20 7d lwarx r9,0,r10 100008ac: 00 18 09 7c cmpw r9,r3 100008b0: 0c 00 c2 40 bne- 100008bc 100008b4: 2d 51 80 7c stwcx. r4,0,r10 100008b8: f0 ff c2 40 bne- 100008a8 100008bc: 2c 01 00 4c isync xlc (13.1.3) 10000888: ac 04 00 7c sync 1000088c: 28 28 c0 7c lwarx r6,0,r5 10000890: 40 00 26 7c cmpld r6,r0 10000894: 0c 00 82 40 bne 100008a0 10000898: 2d 29 80 7c stwcx. r4,0,r5 1000089c: f0 ff e2 40 bne+ 1000088c 100008a0: 2c 01 00 4c isync On the other hand, the current OpenJDK generates following assemblies. 508: ac 04 00 7c sync 50c: 00 00 5c e9 ld r10,0(r28) 510: 00 50 3b 7c cmpd r27,r10 514: 1c 00 c2 40 bne- 530 518: a8 40 5c 7d ldarx r10,r28,r8 51c: 00 50 3b 7c cmpd r27,r10 520: 10 00 c2 40 bne- 530 524: ad 41 3c 7d stdcx. r9,r28,r8 528: f0 ff c2 40 bne- 518 52c: ac 04 00 7c sync 530: 00 50 bb 7f ... Though we can ignore 50c-514 (because they are a duplicated guard condition), the last sync instruction (52c) makes cmpxchg more strict than memory_order_seq_cst. In some cases, the last sync is necessary when this thread must be able to read all of the changes in the other threads while executing from 508 to 530 (that processes compare-and-exchange). > 2. Has there been a discussion already, establishing that the modified > GC code can indeed use memory_order_relaxed? Otherwise who is > postulating that and based on what evidence? Volker and his colleagues have investigated the current GC codes according to this. http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019079.html However, I believe, we need comments of other GC experts to change the shared codes. Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo David Holmes > wrote on 04/22/2016 21:57:07: > From: David Holmes > > To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- > dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net > Cc: Tim Ellison >, ppc-aix-port-dev at openjdk.java.net > Date: 04/22/2016 21:58 > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > Hi Hiroshi, > > Two initial questions: > > 1. Are the current cmpxchg semantics exactly the same as > memory_order_seq_cst? > > 2. Has there been a discussion already, establishing that the modified > GC code can indeed use memory_order_relaxed? Otherwise who is > postulating that and based on what evidence? > > Missing memory barriers have caused very difficult to track down bugs in > the past - very rare race conditions. So any relaxation here has to be > done with extreme confidence. > > Thanks, > David > > On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: > > Dear all: > > > > Can I please request reviews for the following change? > > > > Code change: > > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ > > (I initially created and Martin enhanced so much) > > > > This change follows the discussion started from this mail. > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > April/018960.html > > > > Description: > > This change provides relaxed compare-and-exchange by introducing > > similar semantics of C++ atomic memory operators, enum memory_order. > > As described in atomic_linux_ppc.inline.hpp, the current implementation of > > cmpxchg is fence_cmpxchg_acquire. This implementation is useful for > > general purposes because twice calls of sync before and after cmpxchg will > > provide strict consistency. However, they sometimes cause overheads > > because > > sync instructions are very expensive in the current POWER chip design. > > In addition, for the other platforms, such as aarch64, this strict > > semantics > > may cause some overheads (according to the Andrew's mail). > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > April/019073.html > > > > With this change, callers can explicitly specify constraints of memory > > ordering > > for cmpxchg with an additional parameter, memory_order order. > > > > typedef enum memory_order { > > memory_order_relaxed, > > memory_order_consume, > > memory_order_acquire, > > memory_order_release, > > memory_order_acq_rel, > > memory_order_seq_cst > > } memory_order; > > > > Because the default value of the parameter is memory_order_seq_cst, > > existing codes can use the same semantics of cmpxchg without any > > modification. The relaxed cmpxchg is implemented only on ppc > > in this changeset. Therefore, the behavior on the other platforms will > > not be changed with this changeset. > > > > In addition, with the new parameter of cmpxchg, this change improves > > performance of copy_to_survivor in the parallel GC. > > copy_to_survivor changes forward pointers by using cmpxchg. This > > operation doesn't require any sync instructions. A pointer is changed > > at most once in a GC and when cmpxchg fails, the latest pointer is > > available for the caller. cas_set_mark and cas_forward_to are extended > > with an additional memory_order parameter as cmpxchg and copy_to_survivor > > uses memory_order_relaxed to modify the forward pointers. > > > > Summary of source code changes: > > > > * src/share/vm/runtime/atomic.hpp > > - Defines enum memory_order and adds a parameter to cmpxchg. > > > > * src/share/vm/runtime/atomic.cpp > > * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > > * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > > * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > > * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > > * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > > * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > > * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > > * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > > * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > > - Added a parameter for each cmpxchg function to follow > > the change of atomic.hpp. Their implementations are not changed. > > > > * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > > * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > > - Added a parameter for each cmpxchg function to follow > > the change of atomic.hpp. In addition, implementations > > are changed corresponding to the specified memory_order. > > > > * src/share/vm/oops/oop.hpp > > * src/share/vm/oops/oop.inline.hpp > > - Add a memory_order parameter to use relaxed cmpxchg in > > cas_set_mark and cas_forward_to. > > > > * src/share/vm/gc/parallel/psPromotionManager.cpp > > * src/share/vm/gc/parallel/psPromotionManager.inline.hpp > > > > Martin tested this changeset on linuxx86_64, linuxppc64le and > > darwinintel64. > > Though more time is needed to test on the other platform, we would like to > > ask > > reviews and start discussion on this changeset. > > I also tested this changeset with SPECjbb2013 and confirmed that gc pause > > time > > is reduced. > > > > Regards, > > Hiroshi > > ----------------------- > > Hiroshi Horii, Ph.D. > > IBM Research - Tokyo > > > > > From goetz.lindenmaier at sap.com Mon Apr 25 11:03:20 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Apr 2016 11:03:20 +0000 Subject: RFR(S): 8154996: [aix] Implement compare_file_modified_times for "8146879: Add option ..." Message-ID: <8b3f93fa17e24a7ab47beaaaed0cf06f@DEWDFE13DE09.global.corp.sap> Hi I need another fix for AIX to 8146879. This is AIX-only, though: http://cr.openjdk.java.net/~goetz/wr16/8154996-aix_compFile/webrev.01/ It simply implements the new OS function. Please review. Thanks, Goetz. From yasuenag at gmail.com Mon Apr 25 12:04:44 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 25 Apr 2016 21:04:44 +0900 Subject: PING: Does CollectedHeap::print_on() need Heap_lock? In-Reply-To: <570CFE91.1070706@gmail.com> References: <570CFE91.1070706@gmail.com> Message-ID: <8156f77c-0fdd-1b84-296d-cb06689687b3@gmail.com> Hi all, I've sent a question for Heap_lock in Universe::print_*(). Have you read it? I think we need to lock Heap_lock in it. Actually, callers of Universe::print_on() seems to be in safepoint. However, I'm not sure that, so I want to hear about that before filing to JBS. Thanks, Yasumasa On 2016/04/12 22:56, Yasumasa Suenaga wrote: > Hi all, > > I have a question about Heap_lock in Universe::print_*(). > > Universe::print_heap_at_SIGBREAK() gets Heap_lock. > However, HeapInfoDCmd::execute() and Universe::print_on() do not get Heap_lock. > > Should we get Heap_lock when we print heap information? > I guess that we should get this lock for consistency. > > -------------------- > diff -r 87215e99d945 src/share/vm/memory/universe.cpp > --- a/src/share/vm/memory/universe.cpp Wed Apr 06 23:42:52 2016 +0000 > +++ b/src/share/vm/memory/universe.cpp Tue Apr 12 22:23:17 2016 +0900 > @@ -1069,6 +1069,7 @@ > } > > void Universe::print_on(outputStream* st) { > + MutexLocker hl(Heap_lock); > st->print_cr("Heap"); > heap()->print_on(st); > } > diff -r 87215e99d945 src/share/vm/services/diagnosticCommand.cpp > --- a/src/share/vm/services/diagnosticCommand.cpp Wed Apr 06 23:42:52 2016 +0000 > +++ b/src/share/vm/services/diagnosticCommand.cpp Tue Apr 12 22:23:17 2016 +0900 > @@ -413,6 +413,7 @@ > } > > void HeapInfoDCmd::execute(DCmdSource source, TRAPS) { > + MutexLocker hl(Heap_lock); > Universe::heap()->print_on(output()); > } > > -------------------- > > If it is correct, I file it to JBS and send review request. > > > Thanks, > > Yasumasa > > From yasuenag at gmail.com Mon Apr 25 12:11:42 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 25 Apr 2016 21:11:42 +0900 Subject: PING: RFR: JDK-8153743: AllocateHeap() and ReallocateHeap() should use ALWAYSINLINE macro In-Reply-To: <57111293.8070209@oracle.com> References: <57066B05.3030906@gmail.com> <5710EC7E.3020108@gmail.com> <57111293.8070209@oracle.com> Message-ID: <9c53da39-08aa-6928-5cb0-5fd8ea2d0562@gmail.com> Hi all, Could you review and sponsor it? I confirmed this patch can apply to jdk9/hs repos. However, I checked this patch with GCC on Linux. I cannot check with other compiler. Also other compilers might need "inline" statement in ALWAYSINLINE macro. So I want to hear whether this patch can work with other compilers. Thanks, Yasumasa On 2016/04/16 1:10, Daniel D. Daugherty wrote: > JDK9-hs and JDK9-hs-rt are currently locked down due to the merge. > Please see the "Merging jdk9/hs-rt with jdk9/hs" e-mail thread on > the hotspot-dev at openjdk.java.net alias. > > Dan > > > > On 4/15/16 7:28 AM, Yasumasa Suenaga wrote: >> PING: Could you review and sponsor it? >> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153743/webrev.00/ >> Yasumasa >> >> >> On 2016/04/07 23:13, Yasumasa Suenaga wrote: >>> For force inlining, JDK-8076212 uses always_inline attribute to them. >>> JDK-8151593 added ALWAYSINLINE macro for force inlining. >>> >>> For consistency, and for other compiler support, AllocateHeap() and >>> ReallocateHeap() should use ALWAYSINLINE. >>> >>> I used ALWAYSINLINE to them, but I got error message as below; >>> ------------------------------ >>> Building target 'images' in configuration 'linux-x86_64-normal-server-release' >>> In file included from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/utilities/array.hpp:29:0, >>> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/memory/universe.hpp:29, >>> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/code/oopRecorder.hpp:28, >>> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/asm/codeBuffer.hpp:28, >>> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/asm/assembler.hpp:28, >>> from /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/precompiled/precompiled.hpp:29: >>> /home/ysuenaga/OpenJDK/hs-rt/hotspot/src/share/vm/memory/allocation.inline.hpp:72:20: ???: always_inline function might not be inlinable [-Werror=attributes] >>> ALWAYSINLINE char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag, >>> ^ >>> ------------------------------ >>> * This message includes Japanese because my environment is Japanese locale :-) >>> >>> According to GCC manual [1], non-static inline function is always compiled >>> on its own in the usual fashion. >>> However, we can compile as inline function with "inline" and "always_inline". >>> always_inline attribute does not imply inlining [2]. >>> GCC testcase [3] uses both "inline" and "always_inline" actually. >>> >>> I uploaded webrev. Could you review it? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8153743/webrev.00/ >>> >>> I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html >>> [2] https://chromiumcodereview.appspot.com/14820003/ >>> [3] https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/testsuite/gcc.dg/vmx/gcc-bug-i.c?view=markup&pathrev=178730 >>> > From yasuenag at gmail.com Mon Apr 25 12:27:54 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 25 Apr 2016 21:27:54 +0900 Subject: To set boolean value via VM.set_flag jcmd Message-ID: <57c6e940-0537-11f0-2c90-80e8b1cdfc77@gmail.com> Hi all, I want to set boolean -XX option via VM.set_flag jcmd. Currently, we have to set 1 or 0 to VM.set_flag, however, we can set 0 or not. And I want to set with true/false for it. I think we can realize it as below: --------------- diff -r 3d289e4ba366 src/share/vm/services/writeableFlags.cpp --- a/src/share/vm/services/writeableFlags.cpp Fri Apr 22 19:40:39 2016 +0200 +++ b/src/share/vm/services/writeableFlags.cpp Mon Apr 25 21:25:06 2016 +0900 @@ -93,12 +93,12 @@ // set a boolean global flag Flag::Error WriteableFlags::set_bool_flag(const char* name, const char* arg, Flag::Flags origin, FormatBuffer<80>& err_msg) { - int value = true; - - if (sscanf(arg, "%d", &value)) { - return set_bool_flag(name, value != 0, origin, err_msg); + if ((strcmp(arg, "true") == 0) || (strcmp(arg, "1") == 0)) { + return set_bool_flag(name, true, origin, err_msg); + } else if ((strcmp(arg, "false") == 0) || (strcmp(arg, "0") == 0)) { + return set_bool_flag(name, false, origin, err_msg); } - err_msg.print("flag value must be a boolean (1 or 0)"); + err_msg.print("flag value must be a boolean (1/0 or true/false)"); return Flag::WRONG_FORMAT; } --------------- If it is accepted, I file it to JBS and send review request. What do you think about it? Thanks, Yasumasa From rachel.protacio at oracle.com Mon Apr 25 13:18:33 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 25 Apr 2016 09:18:33 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571DAD2E.1000200@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> <571DAD2E.1000200@oracle.com> Message-ID: <571E1929.8040608@oracle.com> Hi, No, that's fine. Here's the updated webrev: http://cr.openjdk.java.net/~rprotacio/8152844.01/ Rachel On 4/25/2016 1:37 AM, David Holmes wrote: > Hi Rachel, > > Maybe too late, but despite comments to the contrary from the other > reviewers I think there are enough suggested changes being suggested > that I would want to see another webrev. > > Thanks, > David > > On 23/04/2016 1:22 AM, Rachel Protacio wrote: >> Hi, Coleen, >> >> Thanks for the review! I'll remove the arrayKlass entries and, seeing no >> other objections, will commit. >> >> Rachel >> >> On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >>> >>> Hi, >>> >>> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >>> >>> >>> >>> I don't think you need module or package declared in arrayKlass.hpp >>> since it should be abstract also, ie. there should be no instances of >>> ArrayKlass. >>> >>> Otherwise, looks great. I love seeing those InstanceKlass::casts go >>> away. >>> >>> Coleen >>> >>> >>> On 4/21/16 10:26 PM, David Holmes wrote: >>>> Hi Rachel, >>>> >>>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>>> Hello, >>>>> >>>>> Please review this fix for the package() and module() functions, >>>>> making >>>>> them pure virtual functions of Klass and implementing them in the >>>>> relevant child classes. This cleans up some verbose and repetitive >>>>> code >>>>> that was casting and checking klass types. Also added test cases to >>>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>>> module() functions work as expected. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>>> >>>> The refactoring all looks good to me (though C++ annoys me in needing >>>> to re-declare the functions in each subclass :) ). >>>> >>>> Cheers, >>>> David >>>> >>>>> Tested with jtreg tests in jdk/test (java/lang, java/io, >>>>> java/security, >>>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >>>>> hotspot and non-colo tests. >>>>> >>>>> Thanks! >>>>> Rachel >>> >> From harold.seigel at oracle.com Mon Apr 25 13:37:21 2016 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 25 Apr 2016 09:37:21 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571E1929.8040608@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> <571DAD2E.1000200@oracle.com> <571E1929.8040608@oracle.com> Message-ID: <571E1D91.4000308@oracle.com> Hi Rachel, These changes look good! Thanks, Harold On 4/25/2016 9:18 AM, Rachel Protacio wrote: > Hi, > > No, that's fine. Here's the updated webrev: > http://cr.openjdk.java.net/~rprotacio/8152844.01/ > > Rachel > > On 4/25/2016 1:37 AM, David Holmes wrote: >> Hi Rachel, >> >> Maybe too late, but despite comments to the contrary from the other >> reviewers I think there are enough suggested changes being suggested >> that I would want to see another webrev. >> >> Thanks, >> David >> >> On 23/04/2016 1:22 AM, Rachel Protacio wrote: >>> Hi, Coleen, >>> >>> Thanks for the review! I'll remove the arrayKlass entries and, >>> seeing no >>> other objections, will commit. >>> >>> Rachel >>> >>> On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >>>> >>>> Hi, >>>> >>>> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >>>> >>>> >>>> >>>> I don't think you need module or package declared in arrayKlass.hpp >>>> since it should be abstract also, ie. there should be no instances of >>>> ArrayKlass. >>>> >>>> Otherwise, looks great. I love seeing those InstanceKlass::casts go >>>> away. >>>> >>>> Coleen >>>> >>>> >>>> On 4/21/16 10:26 PM, David Holmes wrote: >>>>> Hi Rachel, >>>>> >>>>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this fix for the package() and module() functions, >>>>>> making >>>>>> them pure virtual functions of Klass and implementing them in the >>>>>> relevant child classes. This cleans up some verbose and >>>>>> repetitive code >>>>>> that was casting and checking klass types. Also added test cases to >>>>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>>>> module() functions work as expected. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>>>> >>>>> The refactoring all looks good to me (though C++ annoys me in needing >>>>> to re-declare the functions in each subclass :) ). >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Tested with jtreg tests in jdk/test (java/lang, java/io, >>>>>> java/security, >>>>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >>>>>> hotspot and non-colo tests. >>>>>> >>>>>> Thanks! >>>>>> Rachel >>>> >>> > From rachel.protacio at oracle.com Mon Apr 25 13:41:39 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Mon, 25 Apr 2016 09:41:39 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571E1D91.4000308@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> <571DAD2E.1000200@oracle.com> <571E1929.8040608@oracle.com> <571E1D91.4000308@oracle.com> Message-ID: <571E1E93.5000604@oracle.com> Thanks, Harold! Rachel On 4/25/2016 9:37 AM, harold seigel wrote: > Hi Rachel, > > These changes look good! > > Thanks, Harold > > On 4/25/2016 9:18 AM, Rachel Protacio wrote: >> Hi, >> >> No, that's fine. Here's the updated webrev: >> http://cr.openjdk.java.net/~rprotacio/8152844.01/ >> >> Rachel >> >> On 4/25/2016 1:37 AM, David Holmes wrote: >>> Hi Rachel, >>> >>> Maybe too late, but despite comments to the contrary from the other >>> reviewers I think there are enough suggested changes being suggested >>> that I would want to see another webrev. >>> >>> Thanks, >>> David >>> >>> On 23/04/2016 1:22 AM, Rachel Protacio wrote: >>>> Hi, Coleen, >>>> >>>> Thanks for the review! I'll remove the arrayKlass entries and, >>>> seeing no >>>> other objections, will commit. >>>> >>>> Rachel >>>> >>>> On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >>>>> >>>>> Hi, >>>>> >>>>> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >>>>> >>>>> >>>>> >>>>> I don't think you need module or package declared in arrayKlass.hpp >>>>> since it should be abstract also, ie. there should be no instances of >>>>> ArrayKlass. >>>>> >>>>> Otherwise, looks great. I love seeing those InstanceKlass::casts go >>>>> away. >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 4/21/16 10:26 PM, David Holmes wrote: >>>>>> Hi Rachel, >>>>>> >>>>>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this fix for the package() and module() functions, >>>>>>> making >>>>>>> them pure virtual functions of Klass and implementing them in the >>>>>>> relevant child classes. This cleans up some verbose and >>>>>>> repetitive code >>>>>>> that was casting and checking klass types. Also added test cases to >>>>>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>>>>> module() functions work as expected. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>>>>> >>>>>> The refactoring all looks good to me (though C++ annoys me in >>>>>> needing >>>>>> to re-declare the functions in each subclass :) ). >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Tested with jtreg tests in jdk/test (java/lang, java/io, >>>>>>> java/security, >>>>>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and >>>>>>> RBT >>>>>>> hotspot and non-colo tests. >>>>>>> >>>>>>> Thanks! >>>>>>> Rachel >>>>> >>>> >> > From volker.simonis at gmail.com Mon Apr 25 15:29:17 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Apr 2016 17:29:17 +0200 Subject: RFR(S): 8154996: [aix] Implement compare_file_modified_times for "8146879: Add option ..." In-Reply-To: <8b3f93fa17e24a7ab47beaaaed0cf06f@DEWDFE13DE09.global.corp.sap> References: <8b3f93fa17e24a7ab47beaaaed0cf06f@DEWDFE13DE09.global.corp.sap> Message-ID: Hi Goetz, your change looks good. I'm only a little confused about the original change for 8146879 where 'compare_file_modified_times()' returns seconds on some platforms and seconds or nanoseconds on others. It's also not clear if "better than second" resolution is required (or desired). If that would improve the functionality we could additionally use the st_mtime_n field on AIX which provides nanosecond resolution. But as your change is "as good as" Solaris, I think its OK to push it and do the possible enhancement in a follow up change. Regards, Volker On Mon, Apr 25, 2016 at 1:03 PM, Lindenmaier, Goetz wrote: > Hi > > I need another fix for AIX to 8146879. This is AIX-only, though: > http://cr.openjdk.java.net/~goetz/wr16/8154996-aix_compFile/webrev.01/ > > It simply implements the new OS function. Please review. > > Thanks, > Goetz. From goetz.lindenmaier at sap.com Mon Apr 25 16:43:00 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 25 Apr 2016 16:43:00 +0000 Subject: RFR(S): 8154996: [aix] Implement compare_file_modified_times for "8146879: Add option ..." In-Reply-To: References: <8b3f93fa17e24a7ab47beaaaed0cf06f@DEWDFE13DE09.global.corp.sap> Message-ID: <2c321aa9e139428cb775a77dec2e8169@DEWDFE13DE09.global.corp.sap> Hi Volker, I also wondered about the semantics of the method. I think it's just supposed to return negative or positive differences to check which is the newer file. Stat contains different time representations on the platforms. GNU returns a struct with seconds and nanoseconds, therefore they check both. On AIX, a single value time_t is returned. (If you compile with _GNU_SOURCE set, AIX 7.1 knows the other format.). But all that should have been mentioned in the review of 8146879. Thanks for the review of my change, Goetz. > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Monday, April 25, 2016 5:29 PM > To: Lindenmaier, Goetz > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8154996: [aix] Implement compare_file_modified_times > for "8146879: Add option ..." > > Hi Goetz, > > your change looks good. > > I'm only a little confused about the original change for 8146879 where > 'compare_file_modified_times()' returns seconds on some platforms and > seconds or nanoseconds on others. It's also not clear if "better than > second" resolution is required (or desired). If that would improve the > functionality we could additionally use the st_mtime_n field on AIX > which provides nanosecond resolution. But as your change is "as good > as" Solaris, I think its OK to push it and do the possible enhancement > in a follow up change. > > Regards, > Volker > > > On Mon, Apr 25, 2016 at 1:03 PM, Lindenmaier, Goetz > wrote: > > Hi > > > > I need another fix for AIX to 8146879. This is AIX-only, though: > > http://cr.openjdk.java.net/~goetz/wr16/8154996- > aix_compFile/webrev.01/ > > > > It simply implements the new OS function. Please review. > > > > Thanks, > > Goetz. From daniel.daugherty at oracle.com Mon Apr 25 18:20:49 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 25 Apr 2016 12:20:49 -0600 Subject: PING: Does CollectedHeap::print_on() need Heap_lock? In-Reply-To: <8156f77c-0fdd-1b84-296d-cb06689687b3@gmail.com> References: <570CFE91.1070706@gmail.com> <8156f77c-0fdd-1b84-296d-cb06689687b3@gmail.com> Message-ID: <571E6001.1030605@oracle.com> Adding hotspot-gc-dev at ... Dan On 4/25/16 6:04 AM, Yasumasa Suenaga wrote: > Hi all, > > I've sent a question for Heap_lock in Universe::print_*(). > Have you read it? > > I think we need to lock Heap_lock in it. > Actually, callers of Universe::print_on() seems to be in safepoint. > > However, I'm not sure that, so I want to hear about that before > filing to JBS. > > > Thanks, > > Yasumasa > > > On 2016/04/12 22:56, Yasumasa Suenaga wrote: >> Hi all, >> >> I have a question about Heap_lock in Universe::print_*(). >> >> Universe::print_heap_at_SIGBREAK() gets Heap_lock. >> However, HeapInfoDCmd::execute() and Universe::print_on() do not get >> Heap_lock. >> >> Should we get Heap_lock when we print heap information? >> I guess that we should get this lock for consistency. >> >> -------------------- >> diff -r 87215e99d945 src/share/vm/memory/universe.cpp >> --- a/src/share/vm/memory/universe.cpp Wed Apr 06 23:42:52 2016 +0000 >> +++ b/src/share/vm/memory/universe.cpp Tue Apr 12 22:23:17 2016 +0900 >> @@ -1069,6 +1069,7 @@ >> } >> >> void Universe::print_on(outputStream* st) { >> + MutexLocker hl(Heap_lock); >> st->print_cr("Heap"); >> heap()->print_on(st); >> } >> diff -r 87215e99d945 src/share/vm/services/diagnosticCommand.cpp >> --- a/src/share/vm/services/diagnosticCommand.cpp Wed Apr 06 >> 23:42:52 2016 +0000 >> +++ b/src/share/vm/services/diagnosticCommand.cpp Tue Apr 12 >> 22:23:17 2016 +0900 >> @@ -413,6 +413,7 @@ >> } >> >> void HeapInfoDCmd::execute(DCmdSource source, TRAPS) { >> + MutexLocker hl(Heap_lock); >> Universe::heap()->print_on(output()); >> } >> >> -------------------- >> >> If it is correct, I file it to JBS and send review request. >> >> >> Thanks, >> >> Yasumasa >> >> From coleen.phillimore at oracle.com Mon Apr 25 19:09:18 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 25 Apr 2016 15:09:18 -0400 Subject: RFR: JDK-8147026- Convert an assert in ClassLoaderData to a guarantee In-Reply-To: <56C5D336.5000804@oracle.com> References: <56C2F10B.3080104@oracle.com> <56C579B4.8000807@oracle.com> <56C5D336.5000804@oracle.com> Message-ID: I updated the bug and think there's no harm turning this assert into a guarantee. If a class_loader is incorrectly unloaded, this might be a useful place to check this. Coleen On 2/18/16 9:20 AM, Coleen Phillimore wrote: > > Hi Shafi, > > I agree with Ioi, I don't see how this guarantee would have helped > you. From reading the bug, having some verification in jvm.cpp may > have been more likely to have found your bug, because it's closer to > the source of where you suspected the bug came from. For the record, I > don't think this would hurt performance, which is another concern with > turning some asserts into guarantees. > > I don't know if I like the idea of turning some asserts into > guarantees with another switch like the -Xlog switches (which I find > so complicated now I need wrapper scripts), > https://bugs.openjdk.java.net/browse/JDK-8149478 but we should discuss > on another thread. > > Coleen > > > On 2/18/16 2:58 AM, Ioi Lam wrote: >> Hi Shafi, >> >> I read the bug report, and it says, " the JVM was crashing during GC >> because the object it was looking at had a pointer to a bad klass. >> The core file analysis showed that the classloader object in the >> klass was not a valid Oop". Are you sure that >> ClassLoaderDataGraph::find_or_create was indeed called with an >> invalid loader? There are many reason for this to happen. E.g., there >> could have been strayed memory writes that corrupts the pointer to >> the classloader object. >> >> In fact, if you have a invalid loader here, the call will return junk >> >> inline ClassLoaderData *ClassLoaderDataGraph::find_or_create(Handle >> loader, TRAPS) { >> guarantee(loader() != NULL && loader()->is_oop(), "Loader must be >> oop"); >> // Gets the class loader data out of the java/lang/ClassLoader >> object, if non-null >> // it's already in the loader_data, so no need to add >> ClassLoaderData* loader_data= >> java_lang_ClassLoader::loader_data(loader()); >> if (loader_data) { >> return loader_data; <<<<<< junk >> } >> >> The callers of this code (systemDicrionary.cpp) will deference the >> returned value to do various operations related to class loading, and >> will crash quickly with a bad pointer. It's highly unlikely that your >> original test scenario would have been healthy enough to get to the >> next GC. >> >> So, I don't think changing the assert to guarantee will significantly >> affect how the product JVM would behave with bad input to >> find_or_create. >> >> - Ioi >> >> On 2/16/16 1:51 AM, David Holmes wrote: >>> Hi Shafi, >>> >>> On 16/02/2016 7:41 PM, Shafi Ahmad wrote: >>>> Hi All, >>>> >>>> >>>> >>>> Please review the trivial change of replacing 'assert' by 'guarantee' >>>> >>>> >>>> >>>> Summary: Having a guarantee in method >>>> "ClassLoaderDataGraph::find_or_create" ensuring that the >>>> classloader is a valid oop will help catch the errors at an early >>>> stage during the run rather than crashing the JVM later on in the GC. >>> >>> I'm not sure I agree with this change on principle. The assert says >>> "we never expect this to fail and we expect to weed out any problems >>> during testing". I could see the need to expand the assert to also >>> check for it being an oop though. >>> >>> I'll defer approval of this to Coleen and Ioi as they have the >>> expertise in this code area. >>> >>> Thanks, >>> David >>> >>>> >>>> >>>> Open webrev: http://cr.openjdk.java.net/~csahu/8147026/webrev.00 >>>> >>>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147026 >>>> >>>> Testing: JPRT >>>> >>>> >>>> >>>> Since we are changing 'assert' by 'guarantee' which will add few >>>> instruction into code in product build and I am not sure about the >>>> *hotness* of this method. >>>> >>>> So I run the performance test [refworkload] to make sure the impact >>>> of this change in the product build. >>>> >>>> I am attaching the performance run report for your reference. >>>> >>>> >>>> >>>> Regards, >>>> >>>> Shafi >>>> >>>> >>>> >> > From coleen.phillimore at oracle.com Tue Apr 26 02:03:36 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 25 Apr 2016 22:03:36 -0400 Subject: RFR: JDK-8147026- Convert an assert in ClassLoaderData to a guarantee In-Reply-To: References: <56C2F10B.3080104@oracle.com> <56C579B4.8000807@oracle.com> <56C5D336.5000804@oracle.com> Message-ID: <06968f25-51c0-bdbb-ab26-0a4ace796990@oracle.com> I should add that this is Reviewed by me. Thanks, Coleen On 4/25/16 3:09 PM, Coleen Phillimore wrote: > > I updated the bug and think there's no harm turning this assert into a > guarantee. If a class_loader is incorrectly unloaded, this might be a > useful place to check this. > > Coleen > > On 2/18/16 9:20 AM, Coleen Phillimore wrote: >> >> Hi Shafi, >> >> I agree with Ioi, I don't see how this guarantee would have helped >> you. From reading the bug, having some verification in jvm.cpp may >> have been more likely to have found your bug, because it's closer to >> the source of where you suspected the bug came from. For the record, >> I don't think this would hurt performance, which is another concern >> with turning some asserts into guarantees. >> >> I don't know if I like the idea of turning some asserts into >> guarantees with another switch like the -Xlog switches (which I find >> so complicated now I need wrapper scripts), >> https://bugs.openjdk.java.net/browse/JDK-8149478 but we should >> discuss on another thread. >> >> Coleen >> >> >> On 2/18/16 2:58 AM, Ioi Lam wrote: >>> Hi Shafi, >>> >>> I read the bug report, and it says, " the JVM was crashing during GC >>> because the object it was looking at had a pointer to a bad klass. >>> The core file analysis showed that the classloader object in the >>> klass was not a valid Oop". Are you sure that >>> ClassLoaderDataGraph::find_or_create was indeed called with an >>> invalid loader? There are many reason for this to happen. E.g., >>> there could have been strayed memory writes that corrupts the >>> pointer to the classloader object. >>> >>> In fact, if you have a invalid loader here, the call will return junk >>> >>> inline ClassLoaderData *ClassLoaderDataGraph::find_or_create(Handle >>> loader, TRAPS) { >>> guarantee(loader() != NULL && loader()->is_oop(), "Loader must be >>> oop"); >>> // Gets the class loader data out of the java/lang/ClassLoader >>> object, if non-null >>> // it's already in the loader_data, so no need to add >>> ClassLoaderData* loader_data= >>> java_lang_ClassLoader::loader_data(loader()); >>> if (loader_data) { >>> return loader_data; <<<<<< junk >>> } >>> >>> The callers of this code (systemDicrionary.cpp) will deference the >>> returned value to do various operations related to class loading, >>> and will crash quickly with a bad pointer. It's highly unlikely that >>> your original test scenario would have been healthy enough to get to >>> the next GC. >>> >>> So, I don't think changing the assert to guarantee will >>> significantly affect how the product JVM would behave with bad input >>> to find_or_create. >>> >>> - Ioi >>> >>> On 2/16/16 1:51 AM, David Holmes wrote: >>>> Hi Shafi, >>>> >>>> On 16/02/2016 7:41 PM, Shafi Ahmad wrote: >>>>> Hi All, >>>>> >>>>> >>>>> >>>>> Please review the trivial change of replacing 'assert' by 'guarantee' >>>>> >>>>> >>>>> >>>>> Summary: Having a guarantee in method >>>>> "ClassLoaderDataGraph::find_or_create" ensuring that the >>>>> classloader is a valid oop will help catch the errors at an early >>>>> stage during the run rather than crashing the JVM later on in the GC. >>>> >>>> I'm not sure I agree with this change on principle. The assert says >>>> "we never expect this to fail and we expect to weed out any >>>> problems during testing". I could see the need to expand the assert >>>> to also check for it being an oop though. >>>> >>>> I'll defer approval of this to Coleen and Ioi as they have the >>>> expertise in this code area. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Open webrev: http://cr.openjdk.java.net/~csahu/8147026/webrev.00 >>>>> >>>>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147026 >>>>> >>>>> Testing: JPRT >>>>> >>>>> >>>>> >>>>> Since we are changing 'assert' by 'guarantee' which will add few >>>>> instruction into code in product build and I am not sure about the >>>>> *hotness* of this method. >>>>> >>>>> So I run the performance test [refworkload] to make sure the >>>>> impact of this change in the product build. >>>>> >>>>> I am attaching the performance run report for your reference. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Shafi >>>>> >>>>> >>>>> >>> >> > From david.holmes at oracle.com Tue Apr 26 02:16:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Apr 2016 12:16:00 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571DAF8F.1080305@oracle.com> References: <56F3F90D.9010408@gmail.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> Message-ID: <571ECF60.4060703@oracle.com> Hi Yasumasa, Kumar, Turns out this change breaks the behaviour of the launcher in the case that main() completes by throwing an exception. What we have in the launcher is: (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; LEAVE(); where LEAVE would have expanded to: if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ JLI_ReportErrorMessage(JVM_ERROR2); \ ret = 1; \ } \ if (JNI_TRUE) { \ (*vm)->DestroyJavaVM(vm); \ return ret; \ } \ so note that we are potentially calling DetachCurrentThread with an exception pending - which is prohibited by JNI**, but which we actually rely on for desired operation as DetachCurrentThread calls thread->exit() which performs uncaught exception handling (ie it prints the exception message and stacktrace) and then clears the exception! (Hence DestroyJavaVM is not called with any pending exceptions.) **JNI spec needs to be modified here. With the current change we have now inserted the following at the start of LEAVE: SetNativeThreadName(env, "DestroyJavaVM"); \ if ((*env)->ExceptionOccurred(env)) { \ (*env)->ExceptionClear(env); \ } \ this has two unintended consequences: 1. SetNativeThreadName itself calls a number of JNI methods, with the exception pending - which is not permitted. So straight away where we have: NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); FindBootStrapClass calls JVM_FindClassFromBootLoader, which make calls using the VM's CHECK_NULL macro - which checks for a pending exception (which it finds) and returns NULL. So the jli NULL_CHECK macro then reports a JNI error: Error: A JNI error has occurred, please check your installation and try again 2. There is no longer an exception from main() for DetachCurrentThread to report, so we exit with a return code of 1 as required, but don't report the exception message/stacktrace. I don't see a reasonable solution for this other than abandoning the attempt to change the name from "main" to "DestroyJavaVM" - which if we can't do, I question the utility of setting the name in the first place (while it might be useful in some circumstances [when main() is running] it will cause confusion in others [when main() has exited]). David ----- On 25/04/2016 3:47 PM, David Holmes wrote: > Looks good to me. > > I'll sponsor this "tomorrow". > > Thanks, > David > > On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >> Hi Kumar, >> >> Thank you for your comment! >> I've fixed them and uploaded new webrev. Could you review again? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>> >>> Also a couple of minor suggestions: >>> >>> - * Set native thread name as possible. >>> + * Set native thread name if possible. >>> >>> >>> + /* >>> - * We can clear pending exception because exception at this point >>> - * is not critical. >>> + */ >>> >>> + /* >>> + * Clear non critical pending exceptions at this point. >>> + */ >>> >>> Thanks >>> Kumar >>> >>>> Hi, >>>> >>>> This is in the wrong place: >>>> >>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>> 1716 /* >>>> 1717 * We can clear pending exception because exception at >>>> this point >>>> 1718 * is not critical. >>>> 1719 */ >>>> 1720 (*env)->ExceptionClear(env); >>>> 1721 } >>>> >>>> This above needs to be after >>>> 391 SetNativeThreadName(env, "main"); >>>> 392 >>>> >>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>> but have also encountered an exception. In which case >>>> the method SetNativeThreadName will return to the caller, as >>>> if nothing has happened, because NULL_CHECK simply checks for NULL >>>> and returns to the caller. This will cause the caller to enter >>>> the VM with exceptions. >>>> >>>> Kumar >>>> >>>> >>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> I don't think we need to report the exception, but can just ignore >>>>>> it. Either way we have to clear the exception before continuing. >>>>> >>>>> I've fixed it in new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I have uploaded webrev.04 as below. >>>>>>> Could you review again? >>>>>>> >>>>>>> > - hotspot: >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>> >>>>>> Looks fine. >>>>>> >>>>>>> > >>>>>>> > - jdk: >>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>> >>>>>> As per private email (but repeated here on the record) in java.c: >>>>>> >>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>> 1717 } >>>>>> >>>>>> I don't think we need to report the exception, but can just ignore >>>>>> it. Either way we have to clear the exception before continuing. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>> >: >>>>>>> > >>>>>>> > Hi David, >>>>>>> > >>>>>>> > Thank you for your comment. >>>>>>> > I uploaded new webrev. Could you review again? >>>>>>> > >>>>>>> > - hotspot: >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>> > >>>>>>> > - jdk: >>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>> > >>>>>>> > >>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>> process, I >>>>>>> would have done it immediately after here: >>>>>>> > >>>>>>> > >>>>>>> > I think that native thread name ("main") should be set just >>>>>>> before >>>>>>> > main method call. >>>>>>> > However, main thread is already started, so I moved it as you >>>>>>> suggested. >>>>>>> > >>>>>>> > >>>>>>> >> One thing I dislike about the current structure is that we >>>>>>> have to >>>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>>> calls >>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>> char* ! >>>>>>> > >>>>>>> > >>>>>>> > SoI proposed to export new JVM function to set native thread >>>>>>> name with >>>>>>> > const char *. >>>>>>> > >>>>>>> > >>>>>>> > Thanks, >>>>>>> > >>>>>>> > Yasumasa >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>> >> >>>>>>> >> Hi Yasumasa, >>>>>>> >> >>>>>>> >> Thanks for persevering with this to get it into the current >>>>>>> form. >>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>> >> >>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>> >>> >>>>>>> >>> Hi Gerard, >>>>>>> >>> >>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>> >>>>>>> >>> >>>>>> >>: >>>>>>> >>> > >>>>>>> >>> > hi Yasumasa, >>>>>>> >>> > >>>>>>> >>> > Nice work. I have 2 questions: >>>>>>> >>> > >>>>>>> >>> > ======== >>>>>>> >>> > File: java.c >>>>>>> >>> > >>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>> >>> after every single JNI call? In this example instead of >>>>>>> NULL_CHECK, >>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>> >>> >>>>>>> >>> It is not critical if we encounter error at JNI function call >>>>>>> because >>>>>>> >>> we cannot set native thread name only. >>>>>>> >>> So I think that we do not need to leave from launcher process. >>>>>>> >> >>>>>>> >> >>>>>>> >> I agree we do not need to abort if an exception occurs (and in >>>>>>> fact >>>>>>> I don't think an exception is even possible from this code), but we >>>>>>> should ensure any pending exception is cleared before any futher JNI >>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>> extensively >>>>>>> throughout the launcher code - so if this usage is wrong then it >>>>>>> is all >>>>>>> wrong! More on this code below ... >>>>>>> >> >>>>>>> >> Other comments: >>>>>>> >> >>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>> >> >>>>>>> >> Please add a comment to the method now that you removed the >>>>>>> internal >>>>>>> comment: >>>>>>> >> >>>>>>> >> // Sets the native thread name for a JavaThread. If specifically >>>>>>> >> // requested JNI-attached threads can also have their native >>>>>>> name set; >>>>>>> >> // otherwise we do not modify JNI-attached threads as it may >>>>>>> interfere >>>>>>> >> // with the application that created them. >>>>>>> >> >>>>>>> >> --- >>>>>>> >> >>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>> >> >>>>>>> >> Please add the following comments: >>>>>>> >> >>>>>>> >> + // Don't modify JNI-attached threads >>>>>>> >> setNativeName(name, false); >>>>>>> >> >>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>> permitted) to >>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>> >> private native void setNativeName(String name, boolean >>>>>>> allowAttachedThread); >>>>>>> >> >>>>>>> >> --- >>>>>>> >> >>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>> >> >>>>>>> >> 328 #define LEAVE() \ >>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>> >> >>>>>>> >> I was going to suggest this be set later, but realized we have >>>>>>> to be >>>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>>> >> >>>>>>> >> + /* Set native thread name. */ >>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>> >> >>>>>>> >> The comment is redundant given the name of the method. That >>>>>>> aside >>>>>>> I'm not sure why you do this so late in the process, I would have >>>>>>> done >>>>>>> it immediately after here: >>>>>>> >> >>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>> >> 388 exit(1); >>>>>>> >> 389 } >>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>> >> >>>>>>> >> >>>>>>> >> + /** >>>>>>> >> + * Set native thread name as possible. >>>>>>> >> + */ >>>>>>> >> >>>>>>> >> Other than the as->if change I'm unclear where the "possible" >>>>>>> bit >>>>>>> comes into play - why would it not be possible? >>>>>>> >> >>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>> "java/lang/Thread")); >>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>> (*env)->GetStaticMethodID(env, >>>>>>> cls, >>>>>>> >> 1707 "currentThread", >>>>>>> "()Ljava/lang/Thread;")); >>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>> >> 1709 currentThreadID)); >>>>>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, >>>>>>> cls, >>>>>>> >> 1711 "setNativeName", >>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>> name)); >>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>> setNativeNameID, >>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>> >> >>>>>>> >> As above NULL_CHECK is fine here, but we should check for and >>>>>>> clear >>>>>>> any pending exception after CallVoidMethod. >>>>>>> >> >>>>>>> >> One thing I dislike about the current structure is that we >>>>>>> have to >>>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>>> calls >>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>> char* ! >>>>>>> Overall I wonder about the affect on startup cost. But if there >>>>>>> is an >>>>>>> issue we can revisit this. >>>>>>> >> >>>>>>> >> Thanks, >>>>>>> >> David >>>>>>> >> ----- >>>>>>> >> >>>>>>> >> >>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set >>>>>>> native >>>>>>> thread >>>>>>> >>> name if possible.? not "Set native thread name as possible.?? >>>>>>> >>> >>>>>>> >>> Sorry for my bad English :-) >>>>>>> >>> >>>>>>> >>> Thanks, >>>>>>> >>> >>>>>>> >>> Yasumasa >>>>>>> >>> >>>>>>> >>> > cheers >>>>>>> >>> > >>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>> >>>>>>> >>> >> wrote: >>>>>>> >>> > > >>>>>>> >>> > > Hi David, >>>>>>> >>> > > >>>>>>> >>> > > I uploaded new webrev: >>>>>>> >>> > > >>>>>>> >>> > > - hotspot: >>>>>>> >>> > > >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>> >>> > > >>>>>>> >>> > > - jdk: >>>>>>> >>> > > >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>> >>> > > >>>>>>> >>> > > >>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>> setName so I'm >>>>>>> >>> not sure what you were thinking here. To take advantage of an >>>>>>> arg >>>>>>> taking >>>>>>> >>> JVM_SetNativThreadName you would need to call it directly as >>>>>>> no Java >>>>>>> >>> code will call it . ??? >>>>>>> >>> > > >>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>> JNI-attached >>>>>>> thread. >>>>>>> >>> > > This change can set native thread name if main thread >>>>>>> changes to >>>>>>> >>> JNI-attached thread. >>>>>>> >>> > > >>>>>>> >>> > > >>>>>>> >>> > > Thanks, >>>>>>> >>> > > >>>>>>> >>> > > Yasumasa >>>>>>> >>> > > >>>>>>> >>> > > >>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>> >>> > >>> Hi David, >>>>>>> >>> > >>> >>>>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>>>> considered a >>>>>>> >>> > >>>> regression that setName stops setting the native thread >>>>>>> main, even >>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>> first place. >>>>>>> >>> :( Such >>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>> >>> > >>> >>>>>>> >>> > >>> I understood. >>>>>>> >>> > >>> Can I send CCC request? >>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>>>> >>> > >> >>>>>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>>>>> sponsor for >>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>> proposed change >>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>> restore the >>>>>>> >>> "broken" behaviour. >>>>>>> >>> > >> >>>>>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 >>>>>>> [1]. >>>>>>> >>> > >> >>>>>>> >>> > >> Okay we can do that. >>>>>>> >>> > >> >>>>>>> >>> > >>> >>>>>>> >>> > >>>> Further, we expect the launcher to use the supported >>>>>>> JNI >>>>>>> >>> interface (as >>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>> interface that >>>>>>> >>> exists for >>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>> >>> > >>> >>>>>>> >>> > >>> I think that we do not use JVM interface if we add new >>>>>>> method in >>>>>>> >>> > >>> LauncherHelper as below: >>>>>>> >>> > >>> ---------------- >>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>> >>> > >>> >>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> >>> > >>> --- >>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>> >>> > >>> +++ >>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>> >>> > >>> else >>>>>>> >>> > >>> return md.toNameAndVersion() + " (" + loc >>>>>>> + ")"; >>>>>>> >>> > >>> } >>>>>>> >>> > >>> + >>>>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>> >>> > >>> + } >>>>>>> >>> > >> >>>>>>> >>> > >> You could also make that call via JNI directly, so not >>>>>>> sure the >>>>>>> >>> helper adds much here. But it won't work unless you change the >>>>>>> semantics >>>>>>> >>> of setName so I'm not sure what you were thinking here. To take >>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>>>>> need to >>>>>>> call >>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>> >>> > >> >>>>>>> >>> > >> David >>>>>>> >>> > >> ----- >>>>>>> >>> > >> >>>>>>> >>> > >>> } >>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>> src/java.base/share/native/libjli/java.c >>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>>>>>> Apr 13 >>>>>>> 14:19:30 >>>>>>> >>> > >>> 2016 +0000 >>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>>>>>> Apr 16 >>>>>>> 11:25:53 >>>>>>> >>> > >>> 2016 +0900 >>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>>> *name); >>>>>>> >>> > >>> >>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>> >>> > >>> >>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>> >>> > >>> */ >>>>>>> >>> > >>> #define LEAVE() \ >>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>> >>> > >>> do { \ >>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) >>>>>>> { \ >>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>> >>> > >>> >>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>> >>> > >>> + >>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>> mainArgs); >>>>>>> >>> > >>> >>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>> >>> > >>> joptString); >>>>>>> >>> > >>> } >>>>>>> >>> > >>> >>>>>>> >>> > >>> +/** >>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>> >>> > >>> + */ >>>>>>> >>> > >>> +static void >>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>> >>> > >>> +{ >>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>> >>> > >>> + jstring nameString; >>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>> name)); >>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>> setNativeThreadNameID, >>>>>>> >>> > >>> nameString); >>>>>>> >>> > >>> +} >>>>>>> >>> > >>> + >>>>>>> >>> > >>> /* >>>>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>> >>> > >>> */ >>>>>>> >>> > >>> ---------------- >>>>>>> >>> > >>> >>>>>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>>> >>> > >>> >>>>>>> >>> > >>>> However this is still a change to the exported JVM >>>>>>> interface and so >>>>>>> >>> > >>>> has to be approved. >>>>>>> >>> > >>> >>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>> >>> > >>> >>>>>>> >>> > >>> >>>>>>> >>> > >>> Thanks, >>>>>>> >>> > >>> >>>>>>> >>> > >>> Yasumasa >>>>>>> >>> > >>> >>>>>>> >>> > >>> >>>>>>> >>> > >>> [1] >>>>>>> >>> > >>> >>>>>>> >>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>> >>>>>>> >>>>>>> >>> > >>> >>>>>>> >>> > >>> >>>>>>> >>> > >>> >>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>> >>> > >>>>> Hi David, >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>> for main >>>>>>> >>> thread and >>>>>>> >>> > >>>>>> JNI attached threads >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>>> itself as >>>>>>> >>> setName >>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>> thread. >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> I know. >>>>>>> >>> > >>>> >>>>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>>>> considered a >>>>>>> >>> > >>>> regression that setName stops setting the native thread >>>>>>> main, even >>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>> first place. >>>>>>> >>> :( Such >>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>> >>> > >>>> >>>>>>> >>> > >>>>> I checked changeset history. >>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>> JDK-7098194, >>>>>>> and it is >>>>>>> >>> > >>>>> backported JDK 8. >>>>>>> >>> > >>>> >>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>>>>> >>> > >>>> >>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>> >>> Thread#setNativeName() >>>>>>> >>> > >>>>> only. >>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private method. >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>> >>> JVM_SetNativeThreadName() >>>>>>> >>> > >>>>> for force setting. >>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>> >>> > >>>>> However, this function is NOT public, so I think we >>>>>>> can >>>>>>> add one >>>>>>> >>> more >>>>>>> >>> > >>>>> argument. >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> What do you think about this? >>>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>>> from Java >>>>>>> >>> launcher. >>>>>>> >>> > >>>> >>>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>>> really at >>>>>>> >>> issue. Yes >>>>>>> >>> > >>>> we would add another arg to the JVM function to allow >>>>>>> it to >>>>>>> apply to >>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>>> reflect that >>>>>>> >>> not just >>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>> exported JVM >>>>>>> >>> interface >>>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>>> launcher to >>>>>>> >>> use the >>>>>>> >>> > >>>> supported JNI interface (as other processes would), >>>>>>> not the >>>>>>> internal >>>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>>> communicate >>>>>>> >>> with the >>>>>>> >>> > >>>> JVM. >>>>>>> >>> > >>>> >>>>>>> >>> > >>>> David >>>>>>> >>> > >>>> ----- >>>>>>> >>> > >>>> >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> Thanks, >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> Yasumasa >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> >>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>> >>> > >>>>>>> Hi David, >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>>>>>> being a >>>>>>> >>> JNI-attached >>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>> for main >>>>>>> >>> thread and >>>>>>> >>> > >>>>>> JNI attached threads >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>>> itself as >>>>>>> >>> setName >>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>> thread. >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>> >>> > >>>>>>> --------------- >>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 >>>>>>> 13:31:11 >>>>>>> >>> 2016 +0200 >>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 >>>>>>> 17:50:10 >>>>>>> >>> 2016 +0900 >>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization >>>>>>> is complete >>>>>>> >>> - nop if >>>>>>> >>> > >>>>>>> no agents. >>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>> >>> > >>>>>>> + >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> I think we can do this straight after the JavaThread >>>>>>> constructor. >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>>> tracing >>>>>>> >>> > >>>>>>> backend."); >>>>>>> >>> > >>>>>>> } >>>>>>> >>> > >>>>>>> --------------- >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>>> If it wants to name its native threads then it is >>>>>>> free >>>>>>> to do so, >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change >>>>>>> native >>>>>>> >>> thread name >>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>>> >>> > >>>>>>> However, I think that it should be changed if Java >>>>>>> developer >>>>>>> >>> calls >>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>> >>> > >>>>>>> It is not the same of changing native thread name at >>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>> SetNativeThreadName() as >>>>>>> below. >>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>>>>> threads was a >>>>>>> >>> > >>>>>> deliberate one** - this functionality originated >>>>>>> with the OSX >>>>>>> >>> port and >>>>>>> >>> > >>>>>> it was reported that the initial feedback with this >>>>>>> feature was to >>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>>>>> been set by >>>>>>> >>> the host >>>>>>> >>> > >>>>>> process. If we do as you propose then we will just >>>>>>> have an >>>>>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>>>>> does my >>>>>>> >>> native thread >>>>>>> >>> > >>>>>> only have a name if I call >>>>>>> cur.setName(cur.getName()) ?" >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> ** If you follow the bugs and related discussions on >>>>>>> this, the >>>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>>> thread only, >>>>>>> >>> non-JNI >>>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>>> were supposed >>>>>>> >>> to be >>>>>>> >>> > >>>>>> documented in the release notes - but as far as I >>>>>>> can see >>>>>>> that >>>>>>> >>> never >>>>>>> >>> > >>>>>> happened. :( >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> My position on this remains that if it is desirable >>>>>>> for >>>>>>> the main >>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native >>>>>>> names >>>>>>> then the >>>>>>> >>> > >>>>>> launcher needs to be setting them using the available >>>>>>> platform >>>>>>> >>> APIs. >>>>>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by >>>>>>> the VM >>>>>>> >>> code for >>>>>>> >>> > >>>>>> this - due to the need to verify API availability. >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>> Thread.setName would >>>>>>> >>> have to go >>>>>>> >>> > >>>>>> through our CCC process I think. But a change in >>>>>>> the launcher >>>>>>> >>> would >>>>>>> >>> > >>>>>> not. >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> Sorry. >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>> David >>>>>>> >>> > >>>>>> ----- >>>>>>> >>> > >>>>>> >>>>>>> >>> > >>>>>>> --------------- >>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 >>>>>>> 13:31:11 >>>>>>> >>> 2016 +0200 >>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 >>>>>>> 17:50:10 >>>>>>> >>> 2016 +0900 >>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>> java_lang_Thread::thread(java_thread); >>>>>>> >>> > >>>>>>> // Thread naming only supported for the current >>>>>>> thread, >>>>>>> >>> doesn't >>>>>>> >>> > >>>>>>> work >>>>>>> >>> > >>>>>>> for >>>>>>> >>> > >>>>>>> // target threads. >>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>> thread to avoid >>>>>>> >>> stepping >>>>>>> >>> > >>>>>>> // on other programs >>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>> >>> > >>>>>>> >>>>>>> >>> >>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>> >>>>>>> >>> > >>>>>>> --------------- >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> Thanks, >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> Yasumasa >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> >>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>> >>> > >>>>>>>> >>>>>>> >>> > >>>>>>>> >>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>> >>> > >>>>>>>>> Roger, >>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>> >>> > >>>>>>>>> >>>>>>> >>> > >>>>>>>>> David, >>>>>>> >>> > >>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>> this. I >>>>>>> don't like >>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>> >>> > >>>>>>>>> >>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>> initializing VM >>>>>>> (before >>>>>>> >>> > >>>>>>>>> calling >>>>>>> >>> > >>>>>>>>> main method), >>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>> AttachCurrentThread(). >>>>>>> So we >>>>>>> >>> can't >>>>>>> >>> > >>>>>>>>> set >>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>> >>> > >>>>>>>> >>>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier this >>>>>>> morning. >>>>>>> >>> Which, >>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise >>>>>>> here that >>>>>>> >>> we don't >>>>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>>>>> The fact >>>>>>> >>> that the >>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >>>>>>> thread seems >>>>>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is >>>>>>> only >>>>>>> working by >>>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>>> used for the >>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>>> inconsistently >>>>>>> >>> named at >>>>>>> >>> > >>>>>>>> the native level. >>>>>>> >>> > >>>>>>>> >>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has >>>>>>> to be >>>>>>> >>> treated like >>>>>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>>>>> wants to >>>>>>> name its >>>>>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>>>>> would not be >>>>>>> >>> exporting >>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>>> have to >>>>>>> use the OS >>>>>>> >>> > >>>>>>>> specific API's for that on a platform-by-platform >>>>>>> basis. >>>>>>> >>> > >>>>>>>> >>>>>>> >>> > >>>>>>>> Sorry. >>>>>>> >>> > >>>>>>>> >>>>>>> >>> > >>>>>>>> David >>>>>>> >>> > >>>>>>>> ----- >>>>>>> >>> > >>>>>>>> >>>>>>> >>> > >>>>>>>> >>>>>>> >>> > >>>>>>>>> >>>>>>> >>> > >>>>>>>>> >>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>> >>> > >>>>>>>>> >>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>> >>> > >>>>>>>>> >>>>>>> >>> > >>>>>>>>> >>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>>>>>> perform >>>>>>> >>> different >>>>>>> >>> > >>>>>>>>>> functions: >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>> JVM_SetNativeThreadName >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> - The first function applies to the current >>>>>>> thread, the >>>>>>> >>> second >>>>>>> >>> > >>>>>>>>>> one a >>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>>>>>> somewhere >>>>>>> >>> about >>>>>>> >>> > >>>>>>>>>> what >>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>> casts to >>>>>>> (void*) >>>>>>> >>> > >>>>>>>>>> instead of >>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>> >>> used at >>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>>>>>> the cast >>>>>>> >>> on the >>>>>>> >>> > >>>>>>>>>> same >>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>> haven't had >>>>>>> time to >>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>> JNI-attached >>>>>>> >>> thread >>>>>>> >>> > >>>>>>>>>>>> then >>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>>> suggestion >>>>>>> >>> should >>>>>>> >>> > >>>>>>>>>>>> work >>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>>> treatment of >>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >>>>>>> confirmed >>>>>>> >>> native >>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>>>>> Exception{ >>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>> >>> > >>>>>>>>>>> } >>>>>>> >>> > >>>>>>>>>>> } >>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>> this. I >>>>>>> don't like >>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>>> comment. >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>>> wrote: >>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>>>>>> thread >>>>>>> >>> name, and JLI >>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>>>>>> >>> core-libs will >>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>>> Kumar) - >>>>>>> now cc'd. >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>>>> >>> Thread.setName >>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>>>>> hotspot changes >>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>> Thread#setName() in >>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>>>> >>> > >>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>>>>>> which is >>>>>>> >>> why the >>>>>>> >>> > >>>>>>>>>>>> native >>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>> >>> > >>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>> attached thread. >>>>>>> >>> > >>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>> haven't had >>>>>>> time to >>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>> JNI-attached >>>>>>> >>> thread >>>>>>> >>> > >>>>>>>>>>>> then >>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>>> suggestion >>>>>>> >>> should >>>>>>> >>> > >>>>>>>>>>>> work >>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>>> treatment of >>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>> >>> > >>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>> this. I >>>>>>> don't like >>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>> >>> > >>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>> >>> > >>>>>>>>>>>> David >>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>> >>> > >>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>> function to set >>>>>>> >>> native >>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>> >>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>>>>> well ... >>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry >>>>>>> have >>>>>>> been on >>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>>>>> correct >>>>>>> as we >>>>>>> >>> do not >>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >>>>>>> includes the >>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>>>>> wrote: >>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer >>>>>>> :-) >>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>> >>>>>>> >>> >>: >>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>> Suenaga wrote: >>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>>> Suenaga >>>>>>> wrote: >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>> >>> >>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>> >>> >>>>>> >>>: >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>>>>> Suenaga wrote: >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>> >>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>> >>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>> >>>>>>> >>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>> >>>>>>> >>> >>>>>> >>>>: >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't >>>>>>> set it: >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = >>>>>>> new >>>>>>> >>> JavaThread(); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>> >>> set_active_handles >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> main_thread->record_stack_base_and_size(); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> >>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>>>>> something? >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same >>>>>>> to thread >>>>>>> >>> name in >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>>>>> setName(). >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java >>>>>>> app, >>>>>>> native >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is >>>>>>> already >>>>>>> >>> starte >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >>>>>>> thrrad name >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>>>> something like >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>> Tue >>>>>>> >>> Mar 29 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>> Wed >>>>>>> >>> Mar 30 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>> create_initial_thread(Handle >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>> initial_thread_name = >>>>>>> >>> "main"; >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> >>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>>> (THREAD, k); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>> >>> thread); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> thread->set_threadObj(thread_oop()); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> java_lang_String::create_from_str("main", >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>>>>> thread_oop, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>>> itself >>>>>>> 'java' and >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>>>>> process >>>>>>> (and >>>>>>> >>> thus >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>>>>> process >>>>>>> is not >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread >>>>>>> with >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>>>>> >>> JavaThread. So I >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>>>>>> thread. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>>> anyhow, since >>>>>>> >>> we want >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread >>>>>>> name >>>>>>> might >>>>>>> >>> have >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' >>>>>>> | head -4 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something >>>>>>> like >>>>>>> 'Java Main >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a >>>>>>> Java >>>>>>> >>> launcher - e.g. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>>>>> thread >>>>>>> name, >>>>>>> >>> I think >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>> Yasumasa >>>>>>> >>> Suenaga wrote: >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>>>>>> thread >>>>>>> >>> name via >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >>>>>>> have it. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native >>>>>>> name, >>>>>>> and main >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >>>>>>> should have >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could >>>>>>> you >>>>>>> review it? >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> > >>>>>>>>>> >>>>>>> >>> > >>>>>>> >>> >>>>>>> >>>> >>> From yasuenag at gmail.com Tue Apr 26 03:11:52 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Apr 2016 12:11:52 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571ECF60.4060703@oracle.com> References: <56F3F90D.9010408@gmail.com> <570E42D2.4060609@oracle.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> Message-ID: <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> Hi David, Kumar, I think that we should evacuate original exception before DestroyJavaVM thread name is set. http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ I added it to LEAVE macro in new webrev. I tested it with following code. It works fine. ------------- public void main(String[] args){ throw new RuntimeException("test"); } ------------- What do you think about it? Thanks, Yasumasa On 2016/04/26 11:16, David Holmes wrote: > Hi Yasumasa, Kumar, > > Turns out this change breaks the behaviour of the launcher in the case that main() completes by throwing an exception. > > What we have in the launcher is: > > (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); > ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; > LEAVE(); > > where LEAVE would have expanded to: > > if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ > JLI_ReportErrorMessage(JVM_ERROR2); \ > ret = 1; \ > } \ > if (JNI_TRUE) { \ > (*vm)->DestroyJavaVM(vm); \ > return ret; \ > } \ > > so note that we are potentially calling DetachCurrentThread with an exception pending - which is prohibited by JNI**, but which we actually rely on for desired operation as DetachCurrentThread calls thread->exit() which performs uncaught exception handling (ie it prints the exception message and stacktrace) and then clears the exception! (Hence DestroyJavaVM is not called with any pending exceptions.) > > **JNI spec needs to be modified here. > > With the current change we have now inserted the following at the start of LEAVE: > > SetNativeThreadName(env, "DestroyJavaVM"); \ > if ((*env)->ExceptionOccurred(env)) { \ > (*env)->ExceptionClear(env); \ > } \ > > this has two unintended consequences: > > 1. SetNativeThreadName itself calls a number of JNI methods, with the exception pending - which is not permitted. So straight away where we have: > > NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); > > FindBootStrapClass calls JVM_FindClassFromBootLoader, which make calls using the VM's CHECK_NULL macro - which checks for a pending exception (which it finds) and returns NULL. So the jli NULL_CHECK macro then reports a JNI error: > > Error: A JNI error has occurred, please check your installation and try again > > > 2. There is no longer an exception from main() for DetachCurrentThread to report, so we exit with a return code of 1 as required, but don't report the exception message/stacktrace. > > I don't see a reasonable solution for this other than abandoning the attempt to change the name from "main" to "DestroyJavaVM" - which if we can't do, I question the utility of setting the name in the first place (while it might be useful in some circumstances [when main() is running] it will cause confusion in others [when main() has exited]). > > David > ----- > > On 25/04/2016 3:47 PM, David Holmes wrote: >> Looks good to me. >> >> I'll sponsor this "tomorrow". >> >> Thanks, >> David >> >> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>> Hi Kumar, >>> >>> Thank you for your comment! >>> I've fixed them and uploaded new webrev. Could you review again? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>> >>>> Also a couple of minor suggestions: >>>> >>>> - * Set native thread name as possible. >>>> + * Set native thread name if possible. >>>> >>>> >>>> + /* >>>> - * We can clear pending exception because exception at this point >>>> - * is not critical. >>>> + */ >>>> >>>> + /* >>>> + * Clear non critical pending exceptions at this point. >>>> + */ >>>> >>>> Thanks >>>> Kumar >>>> >>>>> Hi, >>>>> >>>>> This is in the wrong place: >>>>> >>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>> 1716 /* >>>>> 1717 * We can clear pending exception because exception at >>>>> this point >>>>> 1718 * is not critical. >>>>> 1719 */ >>>>> 1720 (*env)->ExceptionClear(env); >>>>> 1721 } >>>>> >>>>> This above needs to be after >>>>> 391 SetNativeThreadName(env, "main"); >>>>> 392 >>>>> >>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>> but have also encountered an exception. In which case >>>>> the method SetNativeThreadName will return to the caller, as >>>>> if nothing has happened, because NULL_CHECK simply checks for NULL >>>>> and returns to the caller. This will cause the caller to enter >>>>> the VM with exceptions. >>>>> >>>>> Kumar >>>>> >>>>> >>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> I don't think we need to report the exception, but can just ignore >>>>>>> it. Either way we have to clear the exception before continuing. >>>>>> >>>>>> I've fixed it in new webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I have uploaded webrev.04 as below. >>>>>>>> Could you review again? >>>>>>>> >>>>>>>> > - hotspot: >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>> >>>>>>> Looks fine. >>>>>>> >>>>>>>> > >>>>>>>> > - jdk: >>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>> >>>>>>> As per private email (but repeated here on the record) in java.c: >>>>>>> >>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>> 1717 } >>>>>>> >>>>>>> I don't think we need to report the exception, but can just ignore >>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>> >: >>>>>>>> > >>>>>>>> > Hi David, >>>>>>>> > >>>>>>>> > Thank you for your comment. >>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>> > >>>>>>>> > - hotspot: >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>> > >>>>>>>> > - jdk: >>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>> > >>>>>>>> > >>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>> process, I >>>>>>>> would have done it immediately after here: >>>>>>>> > >>>>>>>> > >>>>>>>> > I think that native thread name ("main") should be set just >>>>>>>> before >>>>>>>> > main method call. >>>>>>>> > However, main thread is already started, so I moved it as you >>>>>>>> suggested. >>>>>>>> > >>>>>>>> > >>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>> have to >>>>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>>>> calls >>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>> char* ! >>>>>>>> > >>>>>>>> > >>>>>>>> > SoI proposed to export new JVM function to set native thread >>>>>>>> name with >>>>>>>> > const char *. >>>>>>>> > >>>>>>>> > >>>>>>>> > Thanks, >>>>>>>> > >>>>>>>> > Yasumasa >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>> >> >>>>>>>> >> Hi Yasumasa, >>>>>>>> >> >>>>>>>> >> Thanks for persevering with this to get it into the current >>>>>>>> form. >>>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>>> >> >>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>> >>> >>>>>>>> >>> Hi Gerard, >>>>>>>> >>> >>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>> >>>>>>>> >>> >>>>>>> >>: >>>>>>>> >>> > >>>>>>>> >>> > hi Yasumasa, >>>>>>>> >>> > >>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>> >>> > >>>>>>>> >>> > ======== >>>>>>>> >>> > File: java.c >>>>>>>> >>> > >>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>> >>> after every single JNI call? In this example instead of >>>>>>>> NULL_CHECK, >>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>> >>> >>>>>>>> >>> It is not critical if we encounter error at JNI function call >>>>>>>> because >>>>>>>> >>> we cannot set native thread name only. >>>>>>>> >>> So I think that we do not need to leave from launcher process. >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> I agree we do not need to abort if an exception occurs (and in >>>>>>>> fact >>>>>>>> I don't think an exception is even possible from this code), but we >>>>>>>> should ensure any pending exception is cleared before any futher JNI >>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>> extensively >>>>>>>> throughout the launcher code - so if this usage is wrong then it >>>>>>>> is all >>>>>>>> wrong! More on this code below ... >>>>>>>> >> >>>>>>>> >> Other comments: >>>>>>>> >> >>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>> >> >>>>>>>> >> Please add a comment to the method now that you removed the >>>>>>>> internal >>>>>>>> comment: >>>>>>>> >> >>>>>>>> >> // Sets the native thread name for a JavaThread. If specifically >>>>>>>> >> // requested JNI-attached threads can also have their native >>>>>>>> name set; >>>>>>>> >> // otherwise we do not modify JNI-attached threads as it may >>>>>>>> interfere >>>>>>>> >> // with the application that created them. >>>>>>>> >> >>>>>>>> >> --- >>>>>>>> >> >>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>> >> >>>>>>>> >> Please add the following comments: >>>>>>>> >> >>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>> >> setNativeName(name, false); >>>>>>>> >> >>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>> permitted) to >>>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>>> >> private native void setNativeName(String name, boolean >>>>>>>> allowAttachedThread); >>>>>>>> >> >>>>>>>> >> --- >>>>>>>> >> >>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>> >> >>>>>>>> >> 328 #define LEAVE() \ >>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>> >> >>>>>>>> >> I was going to suggest this be set later, but realized we have >>>>>>>> to be >>>>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>>>> >> >>>>>>>> >> + /* Set native thread name. */ >>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>> >> >>>>>>>> >> The comment is redundant given the name of the method. That >>>>>>>> aside >>>>>>>> I'm not sure why you do this so late in the process, I would have >>>>>>>> done >>>>>>>> it immediately after here: >>>>>>>> >> >>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>> >> 388 exit(1); >>>>>>>> >> 389 } >>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> + /** >>>>>>>> >> + * Set native thread name as possible. >>>>>>>> >> + */ >>>>>>>> >> >>>>>>>> >> Other than the as->if change I'm unclear where the "possible" >>>>>>>> bit >>>>>>>> comes into play - why would it not be possible? >>>>>>>> >> >>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>> "java/lang/Thread")); >>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>> cls, >>>>>>>> >> 1707 "currentThread", >>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>> >> 1709 currentThreadID)); >>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, >>>>>>>> cls, >>>>>>>> >> 1711 "setNativeName", >>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>> name)); >>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>> setNativeNameID, >>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>> >> >>>>>>>> >> As above NULL_CHECK is fine here, but we should check for and >>>>>>>> clear >>>>>>>> any pending exception after CallVoidMethod. >>>>>>>> >> >>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>> have to >>>>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>>>> calls >>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>> char* ! >>>>>>>> Overall I wonder about the affect on startup cost. But if there >>>>>>>> is an >>>>>>>> issue we can revisit this. >>>>>>>> >> >>>>>>>> >> Thanks, >>>>>>>> >> David >>>>>>>> >> ----- >>>>>>>> >> >>>>>>>> >> >>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set >>>>>>>> native >>>>>>>> thread >>>>>>>> >>> name if possible.? not "Set native thread name as possible.?? >>>>>>>> >>> >>>>>>>> >>> Sorry for my bad English :-) >>>>>>>> >>> >>>>>>>> >>> Thanks, >>>>>>>> >>> >>>>>>>> >>> Yasumasa >>>>>>>> >>> >>>>>>>> >>> > cheers >>>>>>>> >>> > >>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>> >>>>>>>> >>> >> wrote: >>>>>>>> >>> > > >>>>>>>> >>> > > Hi David, >>>>>>>> >>> > > >>>>>>>> >>> > > I uploaded new webrev: >>>>>>>> >>> > > >>>>>>>> >>> > > - hotspot: >>>>>>>> >>> > > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>> >>> > > >>>>>>>> >>> > > - jdk: >>>>>>>> >>> > > >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>> >>> > > >>>>>>>> >>> > > >>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>> setName so I'm >>>>>>>> >>> not sure what you were thinking here. To take advantage of an >>>>>>>> arg >>>>>>>> taking >>>>>>>> >>> JVM_SetNativThreadName you would need to call it directly as >>>>>>>> no Java >>>>>>>> >>> code will call it . ??? >>>>>>>> >>> > > >>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>> JNI-attached >>>>>>>> thread. >>>>>>>> >>> > > This change can set native thread name if main thread >>>>>>>> changes to >>>>>>>> >>> JNI-attached thread. >>>>>>>> >>> > > >>>>>>>> >>> > > >>>>>>>> >>> > > Thanks, >>>>>>>> >>> > > >>>>>>>> >>> > > Yasumasa >>>>>>>> >>> > > >>>>>>>> >>> > > >>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>> >>> > >>> Hi David, >>>>>>>> >>> > >>> >>>>>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>>>>> considered a >>>>>>>> >>> > >>>> regression that setName stops setting the native thread >>>>>>>> main, even >>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>> first place. >>>>>>>> >>> :( Such >>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> I understood. >>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>>>>> >>> > >> >>>>>>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>>>>>> sponsor for >>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>> proposed change >>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>> restore the >>>>>>>> >>> "broken" behaviour. >>>>>>>> >>> > >> >>>>>>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 >>>>>>>> [1]. >>>>>>>> >>> > >> >>>>>>>> >>> > >> Okay we can do that. >>>>>>>> >>> > >> >>>>>>>> >>> > >>> >>>>>>>> >>> > >>>> Further, we expect the launcher to use the supported >>>>>>>> JNI >>>>>>>> >>> interface (as >>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>> interface that >>>>>>>> >>> exists for >>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> I think that we do not use JVM interface if we add new >>>>>>>> method in >>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>> >>> > >>> ---------------- >>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>> >>> > >>> >>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>> >>> > >>> --- >>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>> >>> > >>> +++ >>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>> >>> > >>> else >>>>>>>> >>> > >>> return md.toNameAndVersion() + " (" + loc >>>>>>>> + ")"; >>>>>>>> >>> > >>> } >>>>>>>> >>> > >>> + >>>>>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>> >>> > >>> + } >>>>>>>> >>> > >> >>>>>>>> >>> > >> You could also make that call via JNI directly, so not >>>>>>>> sure the >>>>>>>> >>> helper adds much here. But it won't work unless you change the >>>>>>>> semantics >>>>>>>> >>> of setName so I'm not sure what you were thinking here. To take >>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>>>>>> need to >>>>>>>> call >>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>> >>> > >> >>>>>>>> >>> > >> David >>>>>>>> >>> > >> ----- >>>>>>>> >>> > >> >>>>>>>> >>> > >>> } >>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>>>>>>> Apr 13 >>>>>>>> 14:19:30 >>>>>>>> >>> > >>> 2016 +0000 >>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>>>>>>> Apr 16 >>>>>>>> 11:25:53 >>>>>>>> >>> > >>> 2016 +0900 >>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean doXUsage); >>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char *optString); >>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char *optString); >>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>>>> *name); >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>> >>> > >>> */ >>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>> >>> > >>> do { \ >>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) >>>>>>>> { \ >>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, argc); >>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>> >>> > >>> + >>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>>> mainArgs); >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>> >>> > >>> joptString); >>>>>>>> >>> > >>> } >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> +/** >>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>> >>> > >>> + */ >>>>>>>> >>> > >>> +static void >>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>> >>> > >>> +{ >>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>> >>> > >>> + jstring nameString; >>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>> name)); >>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>> setNativeThreadNameID, >>>>>>>> >>> > >>> nameString); >>>>>>>> >>> > >>> +} >>>>>>>> >>> > >>> + >>>>>>>> >>> > >>> /* >>>>>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>> >>> > >>> */ >>>>>>>> >>> > >>> ---------------- >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>>>> >>> > >>> >>>>>>>> >>> > >>>> However this is still a change to the exported JVM >>>>>>>> interface and so >>>>>>>> >>> > >>>> has to be approved. >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> Thanks, >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> Yasumasa >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> [1] >>>>>>>> >>> > >>> >>>>>>>> >>> >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>> >>>>>>>> >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> >>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>> >>> > >>>>> Hi David, >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>> for main >>>>>>>> >>> thread and >>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>>>> itself as >>>>>>>> >>> setName >>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>> thread. >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> I know. >>>>>>>> >>> > >>>> >>>>>>>> >>> > >>>> That change in behaviour may be a problem, it could be >>>>>>>> considered a >>>>>>>> >>> > >>>> regression that setName stops setting the native thread >>>>>>>> main, even >>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>> first place. >>>>>>>> >>> :( Such >>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>> >>> > >>>> >>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>> JDK-7098194, >>>>>>>> and it is >>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>> >>> > >>>> >>>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>>>>>> >>> > >>>> >>>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>>> >>> Thread#setNativeName() >>>>>>>> >>> > >>>>> only. >>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private method. >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>> >>> > >>>>> for force setting. >>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>> >>> > >>>>> However, this function is NOT public, so I think we >>>>>>>> can >>>>>>>> add one >>>>>>>> >>> more >>>>>>>> >>> > >>>>> argument. >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>>>> from Java >>>>>>>> >>> launcher. >>>>>>>> >>> > >>>> >>>>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>>>> really at >>>>>>>> >>> issue. Yes >>>>>>>> >>> > >>>> we would add another arg to the JVM function to allow >>>>>>>> it to >>>>>>>> apply to >>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>>>> reflect that >>>>>>>> >>> not just >>>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>>> exported JVM >>>>>>>> >>> interface >>>>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>>>> launcher to >>>>>>>> >>> use the >>>>>>>> >>> > >>>> supported JNI interface (as other processes would), >>>>>>>> not the >>>>>>>> internal >>>>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>>>> communicate >>>>>>>> >>> with the >>>>>>>> >>> > >>>> JVM. >>>>>>>> >>> > >>>> >>>>>>>> >>> > >>>> David >>>>>>>> >>> > >>>> ----- >>>>>>>> >>> > >>>> >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> Thanks, >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> Yasumasa >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> >>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>>>>>>> being a >>>>>>>> >>> JNI-attached >>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>> for main >>>>>>>> >>> thread and >>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>>>> itself as >>>>>>>> >>> setName >>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>> thread. >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>> >>> > >>>>>>> --------------- >>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 src/share/vm/runtime/thread.cpp >>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 >>>>>>>> 13:31:11 >>>>>>>> >>> 2016 +0200 >>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 >>>>>>>> 17:50:10 >>>>>>>> >>> 2016 +0900 >>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization >>>>>>>> is complete >>>>>>>> >>> - nop if >>>>>>>> >>> > >>>>>>> no agents. >>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>> >>> > >>>>>>> + >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> I think we can do this straight after the JavaThread >>>>>>>> constructor. >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>>>> tracing >>>>>>>> >>> > >>>>>>> backend."); >>>>>>>> >>> > >>>>>>> } >>>>>>>> >>> > >>>>>>> --------------- >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>>> If it wants to name its native threads then it is >>>>>>>> free >>>>>>>> to do so, >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change >>>>>>>> native >>>>>>>> >>> thread name >>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>>>> >>> > >>>>>>> However, I think that it should be changed if Java >>>>>>>> developer >>>>>>>> >>> calls >>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>> >>> > >>>>>>> It is not the same of changing native thread name at >>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>> SetNativeThreadName() as >>>>>>>> below. >>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>>>>>> threads was a >>>>>>>> >>> > >>>>>> deliberate one** - this functionality originated >>>>>>>> with the OSX >>>>>>>> >>> port and >>>>>>>> >>> > >>>>>> it was reported that the initial feedback with this >>>>>>>> feature was to >>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>>>>>> been set by >>>>>>>> >>> the host >>>>>>>> >>> > >>>>>> process. If we do as you propose then we will just >>>>>>>> have an >>>>>>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>>>>>> does my >>>>>>>> >>> native thread >>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> ** If you follow the bugs and related discussions on >>>>>>>> this, the >>>>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>>>> thread only, >>>>>>>> >>> non-JNI >>>>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>>>> were supposed >>>>>>>> >>> to be >>>>>>>> >>> > >>>>>> documented in the release notes - but as far as I >>>>>>>> can see >>>>>>>> that >>>>>>>> >>> never >>>>>>>> >>> > >>>>>> happened. :( >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> My position on this remains that if it is desirable >>>>>>>> for >>>>>>>> the main >>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native >>>>>>>> names >>>>>>>> then the >>>>>>>> >>> > >>>>>> launcher needs to be setting them using the available >>>>>>>> platform >>>>>>>> >>> APIs. >>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by >>>>>>>> the VM >>>>>>>> >>> code for >>>>>>>> >>> > >>>>>> this - due to the need to verify API availability. >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>> Thread.setName would >>>>>>>> >>> have to go >>>>>>>> >>> > >>>>>> through our CCC process I think. But a change in >>>>>>>> the launcher >>>>>>>> >>> would >>>>>>>> >>> > >>>>>> not. >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> Sorry. >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>> David >>>>>>>> >>> > >>>>>> ----- >>>>>>>> >>> > >>>>>> >>>>>>>> >>> > >>>>>>> --------------- >>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 >>>>>>>> 13:31:11 >>>>>>>> >>> 2016 +0200 >>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 >>>>>>>> 17:50:10 >>>>>>>> >>> 2016 +0900 >>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>> >>> > >>>>>>> // Thread naming only supported for the current >>>>>>>> thread, >>>>>>>> >>> doesn't >>>>>>>> >>> > >>>>>>> work >>>>>>>> >>> > >>>>>>> for >>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>>> thread to avoid >>>>>>>> >>> stepping >>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> >>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>> >>>>>>>> >>> > >>>>>>> --------------- >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> >>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>> >>> > >>>>>>>> >>>>>>>> >>> > >>>>>>>> >>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>> >>> > >>>>>>>>> >>>>>>>> >>> > >>>>>>>>> David, >>>>>>>> >>> > >>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>> this. I >>>>>>>> don't like >>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>> >>> > >>>>>>>>> >>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>> initializing VM >>>>>>>> (before >>>>>>>> >>> > >>>>>>>>> calling >>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>> AttachCurrentThread(). >>>>>>>> So we >>>>>>>> >>> can't >>>>>>>> >>> > >>>>>>>>> set >>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>> >>> > >>>>>>>> >>>>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier this >>>>>>>> morning. >>>>>>>> >>> Which, >>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise >>>>>>>> here that >>>>>>>> >>> we don't >>>>>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>>>>>> The fact >>>>>>>> >>> that the >>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a JNI-attached >>>>>>>> thread seems >>>>>>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is >>>>>>>> only >>>>>>>> working by >>>>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>>>> used for the >>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>>>> inconsistently >>>>>>>> >>> named at >>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>> >>> > >>>>>>>> >>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has >>>>>>>> to be >>>>>>>> >>> treated like >>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>>>>>> wants to >>>>>>>> name its >>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>>>>>> would not be >>>>>>>> >>> exporting >>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>>>> have to >>>>>>>> use the OS >>>>>>>> >>> > >>>>>>>> specific API's for that on a platform-by-platform >>>>>>>> basis. >>>>>>>> >>> > >>>>>>>> >>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>> >>> > >>>>>>>> >>>>>>>> >>> > >>>>>>>> David >>>>>>>> >>> > >>>>>>>> ----- >>>>>>>> >>> > >>>>>>>> >>>>>>>> >>> > >>>>>>>> >>>>>>>> >>> > >>>>>>>>> >>>>>>>> >>> > >>>>>>>>> >>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>> >>> > >>>>>>>>> >>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>> >>> > >>>>>>>>> >>>>>>>> >>> > >>>>>>>>> >>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>>>>>>> perform >>>>>>>> >>> different >>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>> JVM_SetNativeThreadName >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> - The first function applies to the current >>>>>>>> thread, the >>>>>>>> >>> second >>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>>>>>>> somewhere >>>>>>>> >>> about >>>>>>>> >>> > >>>>>>>>>> what >>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>>> casts to >>>>>>>> (void*) >>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>> >>> used at >>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>>>>>>> the cast >>>>>>>> >>> on the >>>>>>>> >>> > >>>>>>>>>> same >>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>> haven't had >>>>>>>> time to >>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>> JNI-attached >>>>>>>> >>> thread >>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>>>> suggestion >>>>>>>> >>> should >>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>>>> treatment of >>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, and I >>>>>>>> confirmed >>>>>>>> >>> native >>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>>>>>> Exception{ >>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>> this. I >>>>>>>> don't like >>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>>>> comment. >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga wrote: >>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>>>> wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>>>>>>> thread >>>>>>>> >>> name, and JLI >>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another team so >>>>>>>> >>> core-libs will >>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>>>> Kumar) - >>>>>>>> now cc'd. >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java upcall to >>>>>>>> >>> Thread.setName >>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>>>>>> hotspot changes >>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>>> Thread#setName() in >>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>>>>>>> which is >>>>>>>> >>> why the >>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>> attached thread. >>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>> haven't had >>>>>>>> time to >>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>> JNI-attached >>>>>>>> >>> thread >>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>>>> suggestion >>>>>>>> >>> should >>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>>>> treatment of >>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>> this. I >>>>>>>> don't like >>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>>> function to set >>>>>>>> >>> native >>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>> >>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>>>>>> well ... >>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry >>>>>>>> have >>>>>>>> been on >>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>>>>>> correct >>>>>>>> as we >>>>>>>> >>> do not >>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, which >>>>>>>> includes the >>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>>>>>> wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer >>>>>>>> :-) >>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>> >>>>>>>> >>> >>: >>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>>> Suenaga wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>>>> Suenaga >>>>>>>> wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>> >>> >>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>> >>> >>>>>>> >>>: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>>>>>> Suenaga wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>> >>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>> >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>> >>> >>>>>>> >>>>: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't >>>>>>>> set it: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = >>>>>>>> new >>>>>>>> >>> JavaThread(); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> main_thread->initialize_thread_current(); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>> >>> set_active_handles >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> >>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>>>>>> something? >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same >>>>>>>> to thread >>>>>>>> >>> name in >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>>>>>> setName(). >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java >>>>>>>> app, >>>>>>>> native >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is >>>>>>>> already >>>>>>>> >>> starte >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of setting >>>>>>>> thrrad name >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>>>>> something like >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>> Tue >>>>>>>> >>> Mar 29 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>> Wed >>>>>>>> >>> Mar 30 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>> create_initial_thread(Handle >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>> initial_thread_name = >>>>>>>> >>> "main"; >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> >>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>>>> (THREAD, k); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>> >>> thread); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> java_lang_String::create_from_str("main", >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>>>>>> thread_oop, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev later. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>>>> itself >>>>>>>> 'java' and >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>>>>>> process >>>>>>>> (and >>>>>>>> >>> thus >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>>>>>> process >>>>>>>> is not >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread >>>>>>>> with >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>>>>>> >>> JavaThread. So I >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>>>>>>> thread. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>>>> anyhow, since >>>>>>>> >>> we want >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread >>>>>>>> name >>>>>>>> might >>>>>>>> >>> have >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. /proc. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' >>>>>>>> | head -4 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something >>>>>>>> like >>>>>>>> 'Java Main >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a >>>>>>>> Java >>>>>>>> >>> launcher - e.g. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, etc. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>>>>>> thread >>>>>>>> name, >>>>>>>> >>> I think >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>>> Yasumasa >>>>>>>> >>> Suenaga wrote: >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>>>>>>> thread >>>>>>>> >>> name via >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread does not >>>>>>>> have it. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native >>>>>>>> name, >>>>>>>> and main >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main thread >>>>>>>> should have >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could >>>>>>>> you >>>>>>>> review it? >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>> > >>>>>>>>>> >>>>>>>> >>> > >>>>>>>> >>> >>>>>>>> >>>>> >>>> From david.holmes at oracle.com Tue Apr 26 04:35:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Apr 2016 14:35:46 +1000 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571E1929.8040608@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> <571DAD2E.1000200@oracle.com> <571E1929.8040608@oracle.com> Message-ID: <571EF022.30103@oracle.com> On 25/04/2016 11:18 PM, Rachel Protacio wrote: > Hi, > > No, that's fine. Here's the updated webrev: > http://cr.openjdk.java.net/~rprotacio/8152844.01/ Thanks - looks good. David > Rachel > > On 4/25/2016 1:37 AM, David Holmes wrote: >> Hi Rachel, >> >> Maybe too late, but despite comments to the contrary from the other >> reviewers I think there are enough suggested changes being suggested >> that I would want to see another webrev. >> >> Thanks, >> David >> >> On 23/04/2016 1:22 AM, Rachel Protacio wrote: >>> Hi, Coleen, >>> >>> Thanks for the review! I'll remove the arrayKlass entries and, seeing no >>> other objections, will commit. >>> >>> Rachel >>> >>> On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >>>> >>>> Hi, >>>> >>>> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >>>> >>>> >>>> >>>> I don't think you need module or package declared in arrayKlass.hpp >>>> since it should be abstract also, ie. there should be no instances of >>>> ArrayKlass. >>>> >>>> Otherwise, looks great. I love seeing those InstanceKlass::casts go >>>> away. >>>> >>>> Coleen >>>> >>>> >>>> On 4/21/16 10:26 PM, David Holmes wrote: >>>>> Hi Rachel, >>>>> >>>>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this fix for the package() and module() functions, >>>>>> making >>>>>> them pure virtual functions of Klass and implementing them in the >>>>>> relevant child classes. This cleans up some verbose and repetitive >>>>>> code >>>>>> that was casting and checking klass types. Also added test cases to >>>>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>>>> module() functions work as expected. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>>>> >>>>> The refactoring all looks good to me (though C++ annoys me in needing >>>>> to re-declare the functions in each subclass :) ). >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Tested with jtreg tests in jdk/test (java/lang, java/io, >>>>>> java/security, >>>>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and RBT >>>>>> hotspot and non-colo tests. >>>>>> >>>>>> Thanks! >>>>>> Rachel >>>> >>> > From shafi.s.ahmad at oracle.com Tue Apr 26 04:50:26 2016 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 25 Apr 2016 21:50:26 -0700 (PDT) Subject: RFR: JDK-8147026- Convert an assert in ClassLoaderData to a guarantee In-Reply-To: <06968f25-51c0-bdbb-ab26-0a4ace796990@oracle.com> References: <56C2F10B.3080104@oracle.com> <56C579B4.8000807@oracle.com> <56C5D336.5000804@oracle.com> <06968f25-51c0-bdbb-ab26-0a4ace796990@oracle.com> Message-ID: <95bec03c-b310-421d-b608-5f727b1aeffd@default> Thanks for review Coleen. Regards, Shafi -----Original Message----- From: Coleen Phillimore Sent: Tuesday, April 26, 2016 7:34 AM To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR: JDK-8147026- Convert an assert in ClassLoaderData to a guarantee I should add that this is Reviewed by me. Thanks, Coleen On 4/25/16 3:09 PM, Coleen Phillimore wrote: > > I updated the bug and think there's no harm turning this assert into a > guarantee. If a class_loader is incorrectly unloaded, this might be a > useful place to check this. > > Coleen > > On 2/18/16 9:20 AM, Coleen Phillimore wrote: >> >> Hi Shafi, >> >> I agree with Ioi, I don't see how this guarantee would have helped >> you. From reading the bug, having some verification in jvm.cpp may >> have been more likely to have found your bug, because it's closer to >> the source of where you suspected the bug came from. For the record, >> I don't think this would hurt performance, which is another concern >> with turning some asserts into guarantees. >> >> I don't know if I like the idea of turning some asserts into >> guarantees with another switch like the -Xlog switches (which I find >> so complicated now I need wrapper scripts), >> https://bugs.openjdk.java.net/browse/JDK-8149478 but we should >> discuss on another thread. >> >> Coleen >> >> >> On 2/18/16 2:58 AM, Ioi Lam wrote: >>> Hi Shafi, >>> >>> I read the bug report, and it says, " the JVM was crashing during GC >>> because the object it was looking at had a pointer to a bad klass. >>> The core file analysis showed that the classloader object in the >>> klass was not a valid Oop". Are you sure that >>> ClassLoaderDataGraph::find_or_create was indeed called with an >>> invalid loader? There are many reason for this to happen. E.g., >>> there could have been strayed memory writes that corrupts the >>> pointer to the classloader object. >>> >>> In fact, if you have a invalid loader here, the call will return >>> junk >>> >>> inline ClassLoaderData *ClassLoaderDataGraph::find_or_create(Handle >>> loader, TRAPS) { >>> guarantee(loader() != NULL && loader()->is_oop(), "Loader must be >>> oop"); >>> // Gets the class loader data out of the java/lang/ClassLoader >>> object, if non-null >>> // it's already in the loader_data, so no need to add >>> ClassLoaderData* loader_data= >>> java_lang_ClassLoader::loader_data(loader()); >>> if (loader_data) { >>> return loader_data; <<<<<< junk >>> } >>> >>> The callers of this code (systemDicrionary.cpp) will deference the >>> returned value to do various operations related to class loading, >>> and will crash quickly with a bad pointer. It's highly unlikely that >>> your original test scenario would have been healthy enough to get to >>> the next GC. >>> >>> So, I don't think changing the assert to guarantee will >>> significantly affect how the product JVM would behave with bad input >>> to find_or_create. >>> >>> - Ioi >>> >>> On 2/16/16 1:51 AM, David Holmes wrote: >>>> Hi Shafi, >>>> >>>> On 16/02/2016 7:41 PM, Shafi Ahmad wrote: >>>>> Hi All, >>>>> >>>>> >>>>> >>>>> Please review the trivial change of replacing 'assert' by 'guarantee' >>>>> >>>>> >>>>> >>>>> Summary: Having a guarantee in method >>>>> "ClassLoaderDataGraph::find_or_create" ensuring that the >>>>> classloader is a valid oop will help catch the errors at an early >>>>> stage during the run rather than crashing the JVM later on in the GC. >>>> >>>> I'm not sure I agree with this change on principle. The assert says >>>> "we never expect this to fail and we expect to weed out any >>>> problems during testing". I could see the need to expand the assert >>>> to also check for it being an oop though. >>>> >>>> I'll defer approval of this to Coleen and Ioi as they have the >>>> expertise in this code area. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Open webrev: http://cr.openjdk.java.net/~csahu/8147026/webrev.00 >>>>> >>>>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8147026 >>>>> >>>>> Testing: JPRT >>>>> >>>>> >>>>> >>>>> Since we are changing 'assert' by 'guarantee' which will add few >>>>> instruction into code in product build and I am not sure about the >>>>> *hotness* of this method. >>>>> >>>>> So I run the performance test [refworkload] to make sure the >>>>> impact of this change in the product build. >>>>> >>>>> I am attaching the performance run report for your reference. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Shafi >>>>> >>>>> >>>>> >>> >> > From david.holmes at oracle.com Tue Apr 26 05:16:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Apr 2016 15:16:05 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> References: <56F3F90D.9010408@gmail.com> <570E65B6.2010809@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> Message-ID: <571EF995.3000109@oracle.com> On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: > Hi David, Kumar, > > I think that we should evacuate original exception before DestroyJavaVM > thread name is set. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ > > I added it to LEAVE macro in new webrev. BTW: in the LEAVE macro, stylistically all the code should be in the do { } while(false); loop. I overlooked that initially. > I tested it with following code. It works fine. > > ------------- > public void main(String[] args){ > throw new RuntimeException("test"); > } > ------------- > > What do you think about it? I thought about being able to save/restore the original pending exception but could not see a simple way to restore it - ie just by poking it back into the thread's pending exception field. The problem with using env->Throw is that it acts like the initial throwing of the exception and will have a number of side-effects that then get doubled up: - logging statements (UL and Event logging) - OOM counting I'm not sure whether that is acceptable or not That aside you should check if orig_throwable is non-null before clearing to avoid an unnecessary JNI call. Also "Resume original exception" -> "Restore any original exception" Thanks, David ----- > > Thanks, > > Yasumasa > > > On 2016/04/26 11:16, David Holmes wrote: >> Hi Yasumasa, Kumar, >> >> Turns out this change breaks the behaviour of the launcher in the case >> that main() completes by throwing an exception. >> >> What we have in the launcher is: >> >> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; >> LEAVE(); >> >> where LEAVE would have expanded to: >> >> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >> JLI_ReportErrorMessage(JVM_ERROR2); \ >> ret = 1; \ >> } \ >> if (JNI_TRUE) { \ >> (*vm)->DestroyJavaVM(vm); \ >> return ret; \ >> } \ >> >> so note that we are potentially calling DetachCurrentThread with an >> exception pending - which is prohibited by JNI**, but which we >> actually rely on for desired operation as DetachCurrentThread calls >> thread->exit() which performs uncaught exception handling (ie it >> prints the exception message and stacktrace) and then clears the >> exception! (Hence DestroyJavaVM is not called with any pending >> exceptions.) >> >> **JNI spec needs to be modified here. >> >> With the current change we have now inserted the following at the >> start of LEAVE: >> >> SetNativeThreadName(env, "DestroyJavaVM"); \ >> if ((*env)->ExceptionOccurred(env)) { \ >> (*env)->ExceptionClear(env); \ >> } \ >> >> this has two unintended consequences: >> >> 1. SetNativeThreadName itself calls a number of JNI methods, with the >> exception pending - which is not permitted. So straight away where we >> have: >> >> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >> >> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make calls >> using the VM's CHECK_NULL macro - which checks for a pending exception >> (which it finds) and returns NULL. So the jli NULL_CHECK macro then >> reports a JNI error: >> >> Error: A JNI error has occurred, please check your installation and >> try again >> >> >> 2. There is no longer an exception from main() for DetachCurrentThread >> to report, so we exit with a return code of 1 as required, but don't >> report the exception message/stacktrace. >> >> I don't see a reasonable solution for this other than abandoning the >> attempt to change the name from "main" to "DestroyJavaVM" - which if >> we can't do, I question the utility of setting the name in the first >> place (while it might be useful in some circumstances [when main() is >> running] it will cause confusion in others [when main() has exited]). >> >> David >> ----- >> >> On 25/04/2016 3:47 PM, David Holmes wrote: >>> Looks good to me. >>> >>> I'll sponsor this "tomorrow". >>> >>> Thanks, >>> David >>> >>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>>> Hi Kumar, >>>> >>>> Thank you for your comment! >>>> I've fixed them and uploaded new webrev. Could you review again? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>>> >>>>> Also a couple of minor suggestions: >>>>> >>>>> - * Set native thread name as possible. >>>>> + * Set native thread name if possible. >>>>> >>>>> >>>>> + /* >>>>> - * We can clear pending exception because exception at this >>>>> point >>>>> - * is not critical. >>>>> + */ >>>>> >>>>> + /* >>>>> + * Clear non critical pending exceptions at this point. >>>>> + */ >>>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>>> Hi, >>>>>> >>>>>> This is in the wrong place: >>>>>> >>>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>>> 1716 /* >>>>>> 1717 * We can clear pending exception because exception at >>>>>> this point >>>>>> 1718 * is not critical. >>>>>> 1719 */ >>>>>> 1720 (*env)->ExceptionClear(env); >>>>>> 1721 } >>>>>> >>>>>> This above needs to be after >>>>>> 391 SetNativeThreadName(env, "main"); >>>>>> 392 >>>>>> >>>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>>> but have also encountered an exception. In which case >>>>>> the method SetNativeThreadName will return to the caller, as >>>>>> if nothing has happened, because NULL_CHECK simply checks for NULL >>>>>> and returns to the caller. This will cause the caller to enter >>>>>> the VM with exceptions. >>>>>> >>>>>> Kumar >>>>>> >>>>>> >>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>>> Hi David, >>>>>>> >>>>>>>> I don't think we need to report the exception, but can just ignore >>>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>> >>>>>>> I've fixed it in new webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I have uploaded webrev.04 as below. >>>>>>>>> Could you review again? >>>>>>>>> >>>>>>>>> > - hotspot: >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>> >>>>>>>> >>>>>>>> Looks fine. >>>>>>>> >>>>>>>>> > >>>>>>>>> > - jdk: >>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>> >>>>>>>> As per private email (but repeated here on the record) in java.c: >>>>>>>> >>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>>> 1717 } >>>>>>>> >>>>>>>> I don't think we need to report the exception, but can just ignore >>>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>>> >: >>>>>>>>> > >>>>>>>>> > Hi David, >>>>>>>>> > >>>>>>>>> > Thank you for your comment. >>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>> > >>>>>>>>> > - hotspot: >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>> >>>>>>>>> > >>>>>>>>> > - jdk: >>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>>> process, I >>>>>>>>> would have done it immediately after here: >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > I think that native thread name ("main") should be set just >>>>>>>>> before >>>>>>>>> > main method call. >>>>>>>>> > However, main thread is already started, so I moved it as you >>>>>>>>> suggested. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>> have to >>>>>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>>>>> calls >>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>>> char* ! >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > SoI proposed to export new JVM function to set native thread >>>>>>>>> name with >>>>>>>>> > const char *. >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > Thanks, >>>>>>>>> > >>>>>>>>> > Yasumasa >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>>> >> >>>>>>>>> >> Hi Yasumasa, >>>>>>>>> >> >>>>>>>>> >> Thanks for persevering with this to get it into the current >>>>>>>>> form. >>>>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>>>> >> >>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>> >>> >>>>>>>>> >>> Hi Gerard, >>>>>>>>> >>> >>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>> >>>>>>>>> >>> >>>>>>>> >>: >>>>>>>>> >>> > >>>>>>>>> >>> > hi Yasumasa, >>>>>>>>> >>> > >>>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>>> >>> > >>>>>>>>> >>> > ======== >>>>>>>>> >>> > File: java.c >>>>>>>>> >>> > >>>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>> >>> after every single JNI call? In this example instead of >>>>>>>>> NULL_CHECK, >>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>> >>> >>>>>>>>> >>> It is not critical if we encounter error at JNI function call >>>>>>>>> because >>>>>>>>> >>> we cannot set native thread name only. >>>>>>>>> >>> So I think that we do not need to leave from launcher >>>>>>>>> process. >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> I agree we do not need to abort if an exception occurs (and in >>>>>>>>> fact >>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>> but we >>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>> futher JNI >>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>> extensively >>>>>>>>> throughout the launcher code - so if this usage is wrong then it >>>>>>>>> is all >>>>>>>>> wrong! More on this code below ... >>>>>>>>> >> >>>>>>>>> >> Other comments: >>>>>>>>> >> >>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>>> >> >>>>>>>>> >> Please add a comment to the method now that you removed the >>>>>>>>> internal >>>>>>>>> comment: >>>>>>>>> >> >>>>>>>>> >> // Sets the native thread name for a JavaThread. If >>>>>>>>> specifically >>>>>>>>> >> // requested JNI-attached threads can also have their native >>>>>>>>> name set; >>>>>>>>> >> // otherwise we do not modify JNI-attached threads as it may >>>>>>>>> interfere >>>>>>>>> >> // with the application that created them. >>>>>>>>> >> >>>>>>>>> >> --- >>>>>>>>> >> >>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>>> >> >>>>>>>>> >> Please add the following comments: >>>>>>>>> >> >>>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>>> >> setNativeName(name, false); >>>>>>>>> >> >>>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>>> permitted) to >>>>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>>>> >> private native void setNativeName(String name, boolean >>>>>>>>> allowAttachedThread); >>>>>>>>> >> >>>>>>>>> >> --- >>>>>>>>> >> >>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>>> >> >>>>>>>>> >> 328 #define LEAVE() \ >>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>> >> >>>>>>>>> >> I was going to suggest this be set later, but realized we have >>>>>>>>> to be >>>>>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>>>>> >> >>>>>>>>> >> + /* Set native thread name. */ >>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>> >> >>>>>>>>> >> The comment is redundant given the name of the method. That >>>>>>>>> aside >>>>>>>>> I'm not sure why you do this so late in the process, I would have >>>>>>>>> done >>>>>>>>> it immediately after here: >>>>>>>>> >> >>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>>> >> 388 exit(1); >>>>>>>>> >> 389 } >>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> + /** >>>>>>>>> >> + * Set native thread name as possible. >>>>>>>>> >> + */ >>>>>>>>> >> >>>>>>>>> >> Other than the as->if change I'm unclear where the "possible" >>>>>>>>> bit >>>>>>>>> comes into play - why would it not be possible? >>>>>>>>> >> >>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>>> "java/lang/Thread")); >>>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>>> cls, >>>>>>>>> >> 1707 "currentThread", >>>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>>> >> 1709 currentThreadID)); >>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, >>>>>>>>> cls, >>>>>>>>> >> 1711 "setNativeName", >>>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>>> name)); >>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>>> setNativeNameID, >>>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>>> >> >>>>>>>>> >> As above NULL_CHECK is fine here, but we should check for and >>>>>>>>> clear >>>>>>>>> any pending exception after CallVoidMethod. >>>>>>>>> >> >>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>> have to >>>>>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>>>>> calls >>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>>> char* ! >>>>>>>>> Overall I wonder about the affect on startup cost. But if there >>>>>>>>> is an >>>>>>>>> issue we can revisit this. >>>>>>>>> >> >>>>>>>>> >> Thanks, >>>>>>>>> >> David >>>>>>>>> >> ----- >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set >>>>>>>>> native >>>>>>>>> thread >>>>>>>>> >>> name if possible.? not "Set native thread name as possible.?? >>>>>>>>> >>> >>>>>>>>> >>> Sorry for my bad English :-) >>>>>>>>> >>> >>>>>>>>> >>> Thanks, >>>>>>>>> >>> >>>>>>>>> >>> Yasumasa >>>>>>>>> >>> >>>>>>>>> >>> > cheers >>>>>>>>> >>> > >>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>>> >>>>>>>>> >>> >> >>>>>>>>> wrote: >>>>>>>>> >>> > > >>>>>>>>> >>> > > Hi David, >>>>>>>>> >>> > > >>>>>>>>> >>> > > I uploaded new webrev: >>>>>>>>> >>> > > >>>>>>>>> >>> > > - hotspot: >>>>>>>>> >>> > > >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>>> >>>>>>>>> >>> > > >>>>>>>>> >>> > > - jdk: >>>>>>>>> >>> > > >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>>> >>> > > >>>>>>>>> >>> > > >>>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>>> setName so I'm >>>>>>>>> >>> not sure what you were thinking here. To take advantage of an >>>>>>>>> arg >>>>>>>>> taking >>>>>>>>> >>> JVM_SetNativThreadName you would need to call it directly as >>>>>>>>> no Java >>>>>>>>> >>> code will call it . ??? >>>>>>>>> >>> > > >>>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>>> JNI-attached >>>>>>>>> thread. >>>>>>>>> >>> > > This change can set native thread name if main thread >>>>>>>>> changes to >>>>>>>>> >>> JNI-attached thread. >>>>>>>>> >>> > > >>>>>>>>> >>> > > >>>>>>>>> >>> > > Thanks, >>>>>>>>> >>> > > >>>>>>>>> >>> > > Yasumasa >>>>>>>>> >>> > > >>>>>>>>> >>> > > >>>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>>> >>> > >>> Hi David, >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>> could be >>>>>>>>> considered a >>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>> thread >>>>>>>>> main, even >>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>> first place. >>>>>>>>> >>> :( Such >>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> I understood. >>>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>>>>>> >>> > >> >>>>>>>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>>>>>>> sponsor for >>>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>>> proposed change >>>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>>> restore the >>>>>>>>> >>> "broken" behaviour. >>>>>>>>> >>> > >> >>>>>>>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 >>>>>>>>> [1]. >>>>>>>>> >>> > >> >>>>>>>>> >>> > >> Okay we can do that. >>>>>>>>> >>> > >> >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>>> Further, we expect the launcher to use the supported >>>>>>>>> JNI >>>>>>>>> >>> interface (as >>>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>>> interface that >>>>>>>>> >>> exists for >>>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> I think that we do not use JVM interface if we add new >>>>>>>>> method in >>>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>>> >>> > >>> ---------------- >>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>> >>> > >>> >>>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>> >>> > >>> --- >>>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>>> >>> > >>> +++ >>>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>>> >>> > >>> else >>>>>>>>> >>> > >>> return md.toNameAndVersion() + " (" + loc >>>>>>>>> + ")"; >>>>>>>>> >>> > >>> } >>>>>>>>> >>> > >>> + >>>>>>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>>> >>> > >>> + } >>>>>>>>> >>> > >> >>>>>>>>> >>> > >> You could also make that call via JNI directly, so not >>>>>>>>> sure the >>>>>>>>> >>> helper adds much here. But it won't work unless you change >>>>>>>>> the >>>>>>>>> semantics >>>>>>>>> >>> of setName so I'm not sure what you were thinking here. To >>>>>>>>> take >>>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>>>>>>> need to >>>>>>>>> call >>>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>>> >>> > >> >>>>>>>>> >>> > >> David >>>>>>>>> >>> > >> ----- >>>>>>>>> >>> > >> >>>>>>>>> >>> > >>> } >>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>>>>>>>> Apr 13 >>>>>>>>> 14:19:30 >>>>>>>>> >>> > >>> 2016 +0000 >>>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>>>>>>>> Apr 16 >>>>>>>>> 11:25:53 >>>>>>>>> >>> > >>> 2016 +0900 >>>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean >>>>>>>>> doXUsage); >>>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char >>>>>>>>> *optString); >>>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char >>>>>>>>> *optString); >>>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>>>>> *name); >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>>> >>> > >>> */ >>>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>> >>> > >>> do { \ >>>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) >>>>>>>>> { \ >>>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, >>>>>>>>> argc); >>>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>>> >>> > >>> + >>>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>>>> mainArgs); >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>>> >>> > >>> joptString); >>>>>>>>> >>> > >>> } >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> +/** >>>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>>> >>> > >>> + */ >>>>>>>>> >>> > >>> +static void >>>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>>> >>> > >>> +{ >>>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>>> >>> > >>> + jstring nameString; >>>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>>>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>>> name)); >>>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>>> setNativeThreadNameID, >>>>>>>>> >>> > >>> nameString); >>>>>>>>> >>> > >>> +} >>>>>>>>> >>> > >>> + >>>>>>>>> >>> > >>> /* >>>>>>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>>> >>> > >>> */ >>>>>>>>> >>> > >>> ---------------- >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>>> However this is still a change to the exported JVM >>>>>>>>> interface and so >>>>>>>>> >>> > >>>> has to be approved. >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> Thanks, >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> Yasumasa >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> [1] >>>>>>>>> >>> > >>> >>>>>>>>> >>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> >>>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>> >>> > >>>>> Hi David, >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>>> for main >>>>>>>>> >>> thread and >>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>>>>> itself as >>>>>>>>> >>> setName >>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>> thread. >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> I know. >>>>>>>>> >>> > >>>> >>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>> could be >>>>>>>>> considered a >>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>> thread >>>>>>>>> main, even >>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>> first place. >>>>>>>>> >>> :( Such >>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>> >>> > >>>> >>>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>>> JDK-7098194, >>>>>>>>> and it is >>>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>>> >>> > >>>> >>>>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>>>>>>> >>> > >>>> >>>>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>>>> >>> Thread#setNativeName() >>>>>>>>> >>> > >>>>> only. >>>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private >>>>>>>>> method. >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>>> >>> > >>>>> for force setting. >>>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>>> >>> > >>>>> However, this function is NOT public, so I think we >>>>>>>>> can >>>>>>>>> add one >>>>>>>>> >>> more >>>>>>>>> >>> > >>>>> argument. >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>>>>> from Java >>>>>>>>> >>> launcher. >>>>>>>>> >>> > >>>> >>>>>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>>>>> really at >>>>>>>>> >>> issue. Yes >>>>>>>>> >>> > >>>> we would add another arg to the JVM function to allow >>>>>>>>> it to >>>>>>>>> apply to >>>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>>>>> reflect that >>>>>>>>> >>> not just >>>>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>>>> exported JVM >>>>>>>>> >>> interface >>>>>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>>>>> launcher to >>>>>>>>> >>> use the >>>>>>>>> >>> > >>>> supported JNI interface (as other processes would), >>>>>>>>> not the >>>>>>>>> internal >>>>>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>>>>> communicate >>>>>>>>> >>> with the >>>>>>>>> >>> > >>>> JVM. >>>>>>>>> >>> > >>>> >>>>>>>>> >>> > >>>> David >>>>>>>>> >>> > >>>> ----- >>>>>>>>> >>> > >>>> >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> Thanks, >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> Yasumasa >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> >>>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>>>>>>>> being a >>>>>>>>> >>> JNI-attached >>>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>>> for main >>>>>>>>> >>> thread and >>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>>>>> itself as >>>>>>>>> >>> setName >>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>> thread. >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 >>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 >>>>>>>>> 13:31:11 >>>>>>>>> >>> 2016 +0200 >>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 >>>>>>>>> 17:50:10 >>>>>>>>> >>> 2016 +0900 >>>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization >>>>>>>>> is complete >>>>>>>>> >>> - nop if >>>>>>>>> >>> > >>>>>>> no agents. >>>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>> >>> > >>>>>>> + >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> I think we can do this straight after the >>>>>>>>> JavaThread >>>>>>>>> constructor. >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>>>>> tracing >>>>>>>>> >>> > >>>>>>> backend."); >>>>>>>>> >>> > >>>>>>> } >>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>>> If it wants to name its native threads then it is >>>>>>>>> free >>>>>>>>> to do so, >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change >>>>>>>>> native >>>>>>>>> >>> thread name >>>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>> >>> > >>>>>>> However, I think that it should be changed if Java >>>>>>>>> developer >>>>>>>>> >>> calls >>>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>>> >>> > >>>>>>> It is not the same of changing native thread >>>>>>>>> name at >>>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>>> SetNativeThreadName() as >>>>>>>>> below. >>>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>>>>>>> threads was a >>>>>>>>> >>> > >>>>>> deliberate one** - this functionality originated >>>>>>>>> with the OSX >>>>>>>>> >>> port and >>>>>>>>> >>> > >>>>>> it was reported that the initial feedback with this >>>>>>>>> feature was to >>>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>>>>>>> been set by >>>>>>>>> >>> the host >>>>>>>>> >>> > >>>>>> process. If we do as you propose then we will just >>>>>>>>> have an >>>>>>>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>>>>>>> does my >>>>>>>>> >>> native thread >>>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> ** If you follow the bugs and related >>>>>>>>> discussions on >>>>>>>>> this, the >>>>>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>>>>> thread only, >>>>>>>>> >>> non-JNI >>>>>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>>>>> were supposed >>>>>>>>> >>> to be >>>>>>>>> >>> > >>>>>> documented in the release notes - but as far as I >>>>>>>>> can see >>>>>>>>> that >>>>>>>>> >>> never >>>>>>>>> >>> > >>>>>> happened. :( >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> My position on this remains that if it is desirable >>>>>>>>> for >>>>>>>>> the main >>>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native >>>>>>>>> names >>>>>>>>> then the >>>>>>>>> >>> > >>>>>> launcher needs to be setting them using the >>>>>>>>> available >>>>>>>>> platform >>>>>>>>> >>> APIs. >>>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by >>>>>>>>> the VM >>>>>>>>> >>> code for >>>>>>>>> >>> > >>>>>> this - due to the need to verify API availability. >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>>> Thread.setName would >>>>>>>>> >>> have to go >>>>>>>>> >>> > >>>>>> through our CCC process I think. But a change in >>>>>>>>> the launcher >>>>>>>>> >>> would >>>>>>>>> >>> > >>>>>> not. >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> Sorry. >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>> David >>>>>>>>> >>> > >>>>>> ----- >>>>>>>>> >>> > >>>>>> >>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 >>>>>>>>> 13:31:11 >>>>>>>>> >>> 2016 +0200 >>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 >>>>>>>>> 17:50:10 >>>>>>>>> >>> 2016 +0900 >>>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>>> >>> > >>>>>>> // Thread naming only supported for the current >>>>>>>>> thread, >>>>>>>>> >>> doesn't >>>>>>>>> >>> > >>>>>>> work >>>>>>>>> >>> > >>>>>>> for >>>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>>>> thread to avoid >>>>>>>>> >>> stepping >>>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> >>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> >>>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>> >>> > >>>>>>>> >>>>>>>>> >>> > >>>>>>>> >>>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>>> >>> > >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>> David, >>>>>>>>> >>> > >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>> this. I >>>>>>>>> don't like >>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>> >>> > >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>>> initializing VM >>>>>>>>> (before >>>>>>>>> >>> > >>>>>>>>> calling >>>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>>> AttachCurrentThread(). >>>>>>>>> So we >>>>>>>>> >>> can't >>>>>>>>> >>> > >>>>>>>>> set >>>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>> >>> > >>>>>>>> >>>>>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier >>>>>>>>> this >>>>>>>>> morning. >>>>>>>>> >>> Which, >>>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise >>>>>>>>> here that >>>>>>>>> >>> we don't >>>>>>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>>>>>>> The fact >>>>>>>>> >>> that the >>>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a >>>>>>>>> JNI-attached >>>>>>>>> thread seems >>>>>>>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is >>>>>>>>> only >>>>>>>>> working by >>>>>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>>>>> used for the >>>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>>>>> inconsistently >>>>>>>>> >>> named at >>>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>>> >>> > >>>>>>>> >>>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has >>>>>>>>> to be >>>>>>>>> >>> treated like >>>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>>>>>>> wants to >>>>>>>>> name its >>>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>>>>>>> would not be >>>>>>>>> >>> exporting >>>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>>>>> have to >>>>>>>>> use the OS >>>>>>>>> >>> > >>>>>>>> specific API's for that on a platform-by-platform >>>>>>>>> basis. >>>>>>>>> >>> > >>>>>>>> >>>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>>> >>> > >>>>>>>> >>>>>>>>> >>> > >>>>>>>> David >>>>>>>>> >>> > >>>>>>>> ----- >>>>>>>>> >>> > >>>>>>>> >>>>>>>>> >>> > >>>>>>>> >>>>>>>>> >>> > >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>>> >>> > >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>>>>>>>> perform >>>>>>>>> >>> different >>>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>>> JVM_SetNativeThreadName >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the current >>>>>>>>> thread, the >>>>>>>>> >>> second >>>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>>>>>>>> somewhere >>>>>>>>> >>> about >>>>>>>>> >>> > >>>>>>>>>> what >>>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>>>> casts to >>>>>>>>> (void*) >>>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>>> >>> used at >>>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>>>>>>>> the cast >>>>>>>>> >>> on the >>>>>>>>> >>> > >>>>>>>>>> same >>>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>> haven't had >>>>>>>>> time to >>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>> JNI-attached >>>>>>>>> >>> thread >>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>>>>> suggestion >>>>>>>>> >>> should >>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>>>>> treatment of >>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, >>>>>>>>> and I >>>>>>>>> confirmed >>>>>>>>> >>> native >>>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>>>>>>> Exception{ >>>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>> this. I >>>>>>>>> don't like >>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>>>>> comment. >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>>>>>>>> thread >>>>>>>>> >>> name, and JLI >>>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another >>>>>>>>> team so >>>>>>>>> >>> core-libs will >>>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>>>>> Kumar) - >>>>>>>>> now cc'd. >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java >>>>>>>>> upcall to >>>>>>>>> >>> Thread.setName >>>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>>>>>>> hotspot changes >>>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>>>> Thread#setName() in >>>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>>>>>>>> which is >>>>>>>>> >>> why the >>>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>>> attached thread. >>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>> haven't had >>>>>>>>> time to >>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>> JNI-attached >>>>>>>>> >>> thread >>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>>>>> suggestion >>>>>>>>> >>> should >>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>>>>> treatment of >>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>> this. I >>>>>>>>> don't like >>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>>>> function to set >>>>>>>>> >>> native >>>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>>>>>>> well ... >>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry >>>>>>>>> have >>>>>>>>> been on >>>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>>>>>>> correct >>>>>>>>> as we >>>>>>>>> >>> do not >>>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, >>>>>>>>> which >>>>>>>>> includes the >>>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer >>>>>>>>> :-) >>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>>> >>>>>>>>> >>> >>>>>>>> >>: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn >>>>>>>>> wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>>>> Suenaga wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn >>>>>>>>> wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>>>>> Suenaga >>>>>>>>> wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>> >>> >>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>> >>> >>>>>>>> >>>: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>>>>>>> Suenaga wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>> >>> >>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>> >>>>>>>>> >>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>>>> >>> >>>>>>>> >>>>: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't >>>>>>>>> set it: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = >>>>>>>>> new >>>>>>>>> >>> JavaThread(); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>> >>> set_active_handles >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> >>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>>>>>>> something? >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same >>>>>>>>> to thread >>>>>>>>> >>> name in >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>>>>>>> setName(). >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java >>>>>>>>> app, >>>>>>>>> native >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is >>>>>>>>> already >>>>>>>>> >>> starte >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of >>>>>>>>> setting >>>>>>>>> thrrad name >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>>>>>> something like >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>>> Tue >>>>>>>>> >>> Mar 29 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>>> Wed >>>>>>>>> >>> Mar 30 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>>> create_initial_thread(Handle >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>>> initial_thread_name = >>>>>>>>> >>> "main"; >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> >>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>>>>> (THREAD, k); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>>> >>> thread); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>>>>>>> thread_oop, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev >>>>>>>>> later. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>>>>> itself >>>>>>>>> 'java' and >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>>>>>>> process >>>>>>>>> (and >>>>>>>>> >>> thus >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>>>>>>> process >>>>>>>>> is not >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread >>>>>>>>> with >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>>>>>>> >>> JavaThread. So I >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>>>>>>>> thread. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>>>>> anyhow, since >>>>>>>>> >>> we want >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread >>>>>>>>> name >>>>>>>>> might >>>>>>>>> >>> have >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. >>>>>>>>> /proc. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' >>>>>>>>> | head -4 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something >>>>>>>>> like >>>>>>>>> 'Java Main >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a >>>>>>>>> Java >>>>>>>>> >>> launcher - e.g. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, >>>>>>>>> etc. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>>>>>>> thread >>>>>>>>> name, >>>>>>>>> >>> I think >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>>>> Yasumasa >>>>>>>>> >>> Suenaga wrote: >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>>>>>>>> thread >>>>>>>>> >>> name via >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread >>>>>>>>> does not >>>>>>>>> have it. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native >>>>>>>>> name, >>>>>>>>> and main >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main >>>>>>>>> thread >>>>>>>>> should have >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could >>>>>>>>> you >>>>>>>>> review it? >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>> >>> > >>>>>>>>> >>> >>>>>>>>> >>>>>> >>>>> From rickard.backman at oracle.com Tue Apr 26 06:33:32 2016 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Tue, 26 Apr 2016 08:33:32 +0200 Subject: RFR (XXS): 8149442 : MonitorInUseLists should be on by default, deflate idle monitors taking too long In-Reply-To: <56FE35E3.8070001@oracle.com> References: <56FE35E3.8070001@oracle.com> Message-ID: <20160426063332.GL19871@rbackman> Looks good. On 04/01, David Simms wrote: > > Greetings, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149442 > Webrev: http://cr.openjdk.java.net/~dsimms/8149442/ > > Safe-point's "deflate_idle_monitors" (clean up task during > Safepoint::begin()), constantly scans all monitors, the entire > population. Setting MonitorInUseLists to true by default would seem > prudent, as the it reduces the scan to "InUse" thread lists. > Reduction in "deflate idle monitor" execution time of up to a > magnitude. > > There are certain applications (notably SPECjbb2013 use of ForkJoin) > whose Java lock monitor total populations are quite high, but the > actual number of in use monitors is low. > > Why these total populations grow so large, further work to reduce > "deflate idle monitor" operations, is beyond the scope of this bug > (see JDK-7021979 & JDK-8153224). > > Testing: no regressions spotted on the following benchmarks: > > * SpecJbb2005 > * SpecJbb2008 > * SpecJbb2013 > * Volano > > > > Cheers > / David Simms /R From staffan.larsen at oracle.com Tue Apr 26 08:18:25 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 26 Apr 2016 10:18:25 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <57176C38.3000109@oracle.com> References: <57176C38.3000109@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 20 apr. 2016, at 13:47, Robbin Ehn wrote: > > Hi all, please review! > > print() method was changed in 8154041 to have outputStream argument, this renames print to print_on. > Since JvmtiBreakpoint extends GrowableElement print_on already exists as a virtual const method, hence the const changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 > Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ > > Tested with: > > #define TraceJVMTICalls false > in hotspot/src/share/vm/prims/jvmtiEnv.cpp > set to true with test-set nsk.jvmti.SetBreakpoint > > Thanks! > > /Robbin From robbin.ehn at oracle.com Tue Apr 26 08:19:35 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 26 Apr 2016 10:19:35 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: References: <57176C38.3000109@oracle.com> Message-ID: Thanks Staffan! /Robbin On 04/26/2016 10:18 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 20 apr. 2016, at 13:47, Robbin Ehn wrote: >> >> Hi all, please review! >> >> print() method was changed in 8154041 to have outputStream argument, this renames print to print_on. >> Since JvmtiBreakpoint extends GrowableElement print_on already exists as a virtual const method, hence the const changes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 >> Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ >> >> Tested with: >> >> #define TraceJVMTICalls false >> in hotspot/src/share/vm/prims/jvmtiEnv.cpp >> set to true with test-set nsk.jvmti.SetBreakpoint >> >> Thanks! >> >> /Robbin > From serguei.spitsyn at oracle.com Tue Apr 26 08:48:40 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 26 Apr 2016 01:48:40 -0700 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <57176C38.3000109@oracle.com> References: <57176C38.3000109@oracle.com> Message-ID: <571F2B68.90803@oracle.com> Hi Robin, Looks good. Thanks, Serguei On 4/20/16 04:47, Robbin Ehn wrote: > Hi all, please review! > > print() method was changed in 8154041 to have outputStream argument, > this renames print to print_on. > Since JvmtiBreakpoint extends GrowableElement print_on already exists > as a virtual const method, hence the const changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 > Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ > > Tested with: > > #define TraceJVMTICalls false > in hotspot/src/share/vm/prims/jvmtiEnv.cpp > set to true with test-set nsk.jvmti.SetBreakpoint > > Thanks! > > /Robbin From robbin.ehn at oracle.com Tue Apr 26 08:49:35 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 26 Apr 2016 10:49:35 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <571F2B68.90803@oracle.com> References: <57176C38.3000109@oracle.com> <571F2B68.90803@oracle.com> Message-ID: <19009225-ff51-912d-ed98-3a86ddb7bfbb@oracle.com> Hi Serguei, Thanks! /Robbin On 04/26/2016 10:48 AM, serguei.spitsyn at oracle.com wrote: > Hi Robin, > > Looks good. > > Thanks, > Serguei > > > On 4/20/16 04:47, Robbin Ehn wrote: >> Hi all, please review! >> >> print() method was changed in 8154041 to have outputStream argument, >> this renames print to print_on. >> Since JvmtiBreakpoint extends GrowableElement print_on already exists >> as a virtual const method, hence the const changes. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 >> Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ >> >> Tested with: >> >> #define TraceJVMTICalls false >> in hotspot/src/share/vm/prims/jvmtiEnv.cpp >> set to true with test-set nsk.jvmti.SetBreakpoint >> >> Thanks! >> >> /Robbin > From goetz.lindenmaier at sap.com Tue Apr 26 09:10:36 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Apr 2016 09:10:36 +0000 Subject: RFR(XXS): 8155085: [ppc] Fix Type-O in "8154580: Save mirror in interpreter frame..." Message-ID: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> Hi, I please need a review for this tiny fix of a Type-O. A single letter is missing: http://cr.openjdk.java.net/~goetz/wr16/8155085-TypeO/webrev.00/ Best regards, Goetz. From yasuenag at gmail.com Tue Apr 26 09:22:52 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Apr 2016 18:22:52 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571EF995.3000109@oracle.com> References: <56F3F90D.9010408@gmail.com> <570EE58F.4060809@oracle.com> <570F13E3.6000802@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> <571EF995.3000109@oracle.com> Message-ID: Hi David, > I thought about being able to save/restore the original pending exception but could not see a simple way to restore it - ie just by poking it back into the thread's pending exception field. The problem with using env->Throw is that it acts like the initial throwing of the exception and will have a number of side-effects that then get doubled up: > - logging statements (UL and Event logging) > - OOM counting Thanks, I understood. >>> so note that we are potentially calling DetachCurrentThread with an >>> exception pending - which is prohibited by JNI**, but which we >>> actually rely on for desired operation as DetachCurrentThread calls >>> thread->exit() which performs uncaught exception handling (ie it >>> prints the exception message and stacktrace) and then clears the >>> exception! (Hence DestroyJavaVM is not called with any pending >>> exceptions.) I think we can call uncaught exception handler before calling DestroyJavaVM(). I added it in new webrev for jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/jdk/ DispatchUncaughtException() in java.c emulates uncaught exception handler call in JavaThread::exit(). I think this patch can provide the solution for our issue. Could you check it? Thanks, Yasumasa On 2016/04/26 14:16, David Holmes wrote: > On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: >> Hi David, Kumar, >> >> I think that we should evacuate original exception before DestroyJavaVM >> thread name is set. >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ >> >> I added it to LEAVE macro in new webrev. > > BTW: in the LEAVE macro, stylistically all the code should be in the do { } while(false); loop. I overlooked that initially. > >> I tested it with following code. It works fine. >> >> ------------- >> public void main(String[] args){ >> throw new RuntimeException("test"); >> } >> ------------- >> >> What do you think about it? > > I thought about being able to save/restore the original pending exception but could not see a simple way to restore it - ie just by poking it back into the thread's pending exception field. The problem with using env->Throw is that it acts like the initial throwing of the exception and will have a number of side-effects that then get doubled up: > - logging statements (UL and Event logging) > - OOM counting > > I'm not sure whether that is acceptable or not > > That aside you should check if orig_throwable is non-null before clearing to avoid an unnecessary JNI call. > > Also "Resume original exception" -> "Restore any original exception" > > Thanks, > David > ----- > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/26 11:16, David Holmes wrote: >>> Hi Yasumasa, Kumar, >>> >>> Turns out this change breaks the behaviour of the launcher in the case >>> that main() completes by throwing an exception. >>> >>> What we have in the launcher is: >>> >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; >>> LEAVE(); >>> >>> where LEAVE would have expanded to: >>> >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>> ret = 1; \ >>> } \ >>> if (JNI_TRUE) { \ >>> (*vm)->DestroyJavaVM(vm); \ >>> return ret; \ >>> } \ >>> >>> so note that we are potentially calling DetachCurrentThread with an >>> exception pending - which is prohibited by JNI**, but which we >>> actually rely on for desired operation as DetachCurrentThread calls >>> thread->exit() which performs uncaught exception handling (ie it >>> prints the exception message and stacktrace) and then clears the >>> exception! (Hence DestroyJavaVM is not called with any pending >>> exceptions.) >>> >>> **JNI spec needs to be modified here. >>> >>> With the current change we have now inserted the following at the >>> start of LEAVE: >>> >>> SetNativeThreadName(env, "DestroyJavaVM"); \ >>> if ((*env)->ExceptionOccurred(env)) { \ >>> (*env)->ExceptionClear(env); \ >>> } \ >>> >>> this has two unintended consequences: >>> >>> 1. SetNativeThreadName itself calls a number of JNI methods, with the >>> exception pending - which is not permitted. So straight away where we >>> have: >>> >>> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >>> >>> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make calls >>> using the VM's CHECK_NULL macro - which checks for a pending exception >>> (which it finds) and returns NULL. So the jli NULL_CHECK macro then >>> reports a JNI error: >>> >>> Error: A JNI error has occurred, please check your installation and >>> try again >>> >>> >>> 2. There is no longer an exception from main() for DetachCurrentThread >>> to report, so we exit with a return code of 1 as required, but don't >>> report the exception message/stacktrace. >>> >>> I don't see a reasonable solution for this other than abandoning the >>> attempt to change the name from "main" to "DestroyJavaVM" - which if >>> we can't do, I question the utility of setting the name in the first >>> place (while it might be useful in some circumstances [when main() is >>> running] it will cause confusion in others [when main() has exited]). >>> >>> David >>> ----- >>> >>> On 25/04/2016 3:47 PM, David Holmes wrote: >>>> Looks good to me. >>>> >>>> I'll sponsor this "tomorrow". >>>> >>>> Thanks, >>>> David >>>> >>>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>>>> Hi Kumar, >>>>> >>>>> Thank you for your comment! >>>>> I've fixed them and uploaded new webrev. Could you review again? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>>>> >>>>>> Also a couple of minor suggestions: >>>>>> >>>>>> - * Set native thread name as possible. >>>>>> + * Set native thread name if possible. >>>>>> >>>>>> >>>>>> + /* >>>>>> - * We can clear pending exception because exception at this >>>>>> point >>>>>> - * is not critical. >>>>>> + */ >>>>>> >>>>>> + /* >>>>>> + * Clear non critical pending exceptions at this point. >>>>>> + */ >>>>>> >>>>>> Thanks >>>>>> Kumar >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is in the wrong place: >>>>>>> >>>>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>>>> 1716 /* >>>>>>> 1717 * We can clear pending exception because exception at >>>>>>> this point >>>>>>> 1718 * is not critical. >>>>>>> 1719 */ >>>>>>> 1720 (*env)->ExceptionClear(env); >>>>>>> 1721 } >>>>>>> >>>>>>> This above needs to be after >>>>>>> 391 SetNativeThreadName(env, "main"); >>>>>>> 392 >>>>>>> >>>>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>>>> but have also encountered an exception. In which case >>>>>>> the method SetNativeThreadName will return to the caller, as >>>>>>> if nothing has happened, because NULL_CHECK simply checks for NULL >>>>>>> and returns to the caller. This will cause the caller to enter >>>>>>> the VM with exceptions. >>>>>>> >>>>>>> Kumar >>>>>>> >>>>>>> >>>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>>> I don't think we need to report the exception, but can just ignore >>>>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>>> >>>>>>>> I've fixed it in new webrev: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I have uploaded webrev.04 as below. >>>>>>>>>> Could you review again? >>>>>>>>>> >>>>>>>>>> > - hotspot: >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> Looks fine. >>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > - jdk: >>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>> >>>>>>>>> As per private email (but repeated here on the record) in java.c: >>>>>>>>> >>>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>>>> 1717 } >>>>>>>>> >>>>>>>>> I don't think we need to report the exception, but can just ignore >>>>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>>>> >: >>>>>>>>>> > >>>>>>>>>> > Hi David, >>>>>>>>>> > >>>>>>>>>> > Thank you for your comment. >>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>> > >>>>>>>>>> > - hotspot: >>>>>>>>>> > >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > - jdk: >>>>>>>>>> > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>>>> process, I >>>>>>>>>> would have done it immediately after here: >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > I think that native thread name ("main") should be set just >>>>>>>>>> before >>>>>>>>>> > main method call. >>>>>>>>>> > However, main thread is already started, so I moved it as you >>>>>>>>>> suggested. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>> have to >>>>>>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>>>>>> calls >>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>>>> char* ! >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > SoI proposed to export new JVM function to set native thread >>>>>>>>>> name with >>>>>>>>>> > const char *. >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > Thanks, >>>>>>>>>> > >>>>>>>>>> > Yasumasa >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>>>> >> >>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>> >> >>>>>>>>>> >> Thanks for persevering with this to get it into the current >>>>>>>>>> form. >>>>>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>>>>> >> >>>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>> >>> >>>>>>>>>> >>> Hi Gerard, >>>>>>>>>> >>> >>>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>> >>>>>>>>>> >>> >>>>>>>>> >>: >>>>>>>>>> >>> > >>>>>>>>>> >>> > hi Yasumasa, >>>>>>>>>> >>> > >>>>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>>>> >>> > >>>>>>>>>> >>> > ======== >>>>>>>>>> >>> > File: java.c >>>>>>>>>> >>> > >>>>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>> >>> after every single JNI call? In this example instead of >>>>>>>>>> NULL_CHECK, >>>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>> >>> >>>>>>>>>> >>> It is not critical if we encounter error at JNI function call >>>>>>>>>> because >>>>>>>>>> >>> we cannot set native thread name only. >>>>>>>>>> >>> So I think that we do not need to leave from launcher >>>>>>>>>> process. >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> I agree we do not need to abort if an exception occurs (and in >>>>>>>>>> fact >>>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>>> but we >>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>> futher JNI >>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>> extensively >>>>>>>>>> throughout the launcher code - so if this usage is wrong then it >>>>>>>>>> is all >>>>>>>>>> wrong! More on this code below ... >>>>>>>>>> >> >>>>>>>>>> >> Other comments: >>>>>>>>>> >> >>>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>>>> >> >>>>>>>>>> >> Please add a comment to the method now that you removed the >>>>>>>>>> internal >>>>>>>>>> comment: >>>>>>>>>> >> >>>>>>>>>> >> // Sets the native thread name for a JavaThread. If >>>>>>>>>> specifically >>>>>>>>>> >> // requested JNI-attached threads can also have their native >>>>>>>>>> name set; >>>>>>>>>> >> // otherwise we do not modify JNI-attached threads as it may >>>>>>>>>> interfere >>>>>>>>>> >> // with the application that created them. >>>>>>>>>> >> >>>>>>>>>> >> --- >>>>>>>>>> >> >>>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>>>> >> >>>>>>>>>> >> Please add the following comments: >>>>>>>>>> >> >>>>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>>>> >> setNativeName(name, false); >>>>>>>>>> >> >>>>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>>>> permitted) to >>>>>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>>>>> >> private native void setNativeName(String name, boolean >>>>>>>>>> allowAttachedThread); >>>>>>>>>> >> >>>>>>>>>> >> --- >>>>>>>>>> >> >>>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>>>> >> >>>>>>>>>> >> 328 #define LEAVE() \ >>>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>> >> >>>>>>>>>> >> I was going to suggest this be set later, but realized we have >>>>>>>>>> to be >>>>>>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>>>>>> >> >>>>>>>>>> >> + /* Set native thread name. */ >>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>> >> >>>>>>>>>> >> The comment is redundant given the name of the method. That >>>>>>>>>> aside >>>>>>>>>> I'm not sure why you do this so late in the process, I would have >>>>>>>>>> done >>>>>>>>>> it immediately after here: >>>>>>>>>> >> >>>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>>>> >> 388 exit(1); >>>>>>>>>> >> 389 } >>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >> + /** >>>>>>>>>> >> + * Set native thread name as possible. >>>>>>>>>> >> + */ >>>>>>>>>> >> >>>>>>>>>> >> Other than the as->if change I'm unclear where the "possible" >>>>>>>>>> bit >>>>>>>>>> comes into play - why would it not be possible? >>>>>>>>>> >> >>>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>>>> "java/lang/Thread")); >>>>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>>>> cls, >>>>>>>>>> >> 1707 "currentThread", >>>>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>>>> >> 1709 currentThreadID)); >>>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = (*env)->GetMethodID(env, >>>>>>>>>> cls, >>>>>>>>>> >> 1711 "setNativeName", >>>>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>>>> name)); >>>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>>>> setNativeNameID, >>>>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>>>> >> >>>>>>>>>> >> As above NULL_CHECK is fine here, but we should check for and >>>>>>>>>> clear >>>>>>>>>> any pending exception after CallVoidMethod. >>>>>>>>>> >> >>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>> have to >>>>>>>>>> go from char* to java.lang.String to call setNativeName which then >>>>>>>>>> calls >>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>>>> char* ! >>>>>>>>>> Overall I wonder about the affect on startup cost. But if there >>>>>>>>>> is an >>>>>>>>>> issue we can revisit this. >>>>>>>>>> >> >>>>>>>>>> >> Thanks, >>>>>>>>>> >> David >>>>>>>>>> >> ----- >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set >>>>>>>>>> native >>>>>>>>>> thread >>>>>>>>>> >>> name if possible.? not "Set native thread name as possible.?? >>>>>>>>>> >>> >>>>>>>>>> >>> Sorry for my bad English :-) >>>>>>>>>> >>> >>>>>>>>>> >>> Thanks, >>>>>>>>>> >>> >>>>>>>>>> >>> Yasumasa >>>>>>>>>> >>> >>>>>>>>>> >>> > cheers >>>>>>>>>> >>> > >>>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>>>> >>>>>>>>>> >>> >> >>>>>>>>>> wrote: >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > Hi David, >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > I uploaded new webrev: >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > - hotspot: >>>>>>>>>> >>> > > >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>>>> >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > - jdk: >>>>>>>>>> >>> > > >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > >>>>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>>>> setName so I'm >>>>>>>>>> >>> not sure what you were thinking here. To take advantage of an >>>>>>>>>> arg >>>>>>>>>> taking >>>>>>>>>> >>> JVM_SetNativThreadName you would need to call it directly as >>>>>>>>>> no Java >>>>>>>>>> >>> code will call it . ??? >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>>>> JNI-attached >>>>>>>>>> thread. >>>>>>>>>> >>> > > This change can set native thread name if main thread >>>>>>>>>> changes to >>>>>>>>>> >>> JNI-attached thread. >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > Thanks, >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > Yasumasa >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > >>>>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>>>> >>> > >>> Hi David, >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>> could be >>>>>>>>>> considered a >>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>> thread >>>>>>>>>> main, even >>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>> first place. >>>>>>>>>> >>> :( Such >>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> I understood. >>>>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at Oracle.) >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>>>>>>>> sponsor for >>>>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>>>> proposed change >>>>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>>>> restore the >>>>>>>>>> >>> "broken" behaviour. >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >>> I want to continue to discuss about it on JDK-8154331 >>>>>>>>>> [1]. >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> Okay we can do that. >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>>> Further, we expect the launcher to use the supported >>>>>>>>>> JNI >>>>>>>>>> >>> interface (as >>>>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>>>> interface that >>>>>>>>>> >>> exists for >>>>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> I think that we do not use JVM interface if we add new >>>>>>>>>> method in >>>>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>> >>> > >>> >>>>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>> >>> > >>> --- >>>>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>>>> >>> > >>> +++ >>>>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>>>> >>> > >>> else >>>>>>>>>> >>> > >>> return md.toNameAndVersion() + " (" + loc >>>>>>>>>> + ")"; >>>>>>>>>> >>> > >>> } >>>>>>>>>> >>> > >>> + >>>>>>>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>>>> >>> > >>> + } >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> You could also make that call via JNI directly, so not >>>>>>>>>> sure the >>>>>>>>>> >>> helper adds much here. But it won't work unless you change >>>>>>>>>> the >>>>>>>>>> semantics >>>>>>>>>> >>> of setName so I'm not sure what you were thinking here. To >>>>>>>>>> take >>>>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>>>>>>>> need to >>>>>>>>>> call >>>>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >> David >>>>>>>>>> >>> > >> ----- >>>>>>>>>> >>> > >> >>>>>>>>>> >>> > >>> } >>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c Wed >>>>>>>>>> Apr 13 >>>>>>>>>> 14:19:30 >>>>>>>>>> >>> > >>> 2016 +0000 >>>>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c Sat >>>>>>>>>> Apr 16 >>>>>>>>>> 11:25:53 >>>>>>>>>> >>> > >>> 2016 +0900 >>>>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean >>>>>>>>>> doXUsage); >>>>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char >>>>>>>>>> *optString); >>>>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char >>>>>>>>>> *optString); >>>>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>>>>>> *name); >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>>>> >>> > >>> */ >>>>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>> >>> > >>> do { \ >>>>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) >>>>>>>>>> { \ >>>>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, >>>>>>>>>> argc); >>>>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>>>> >>> > >>> + >>>>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>>>>> mainArgs); >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>>>> >>> > >>> joptString); >>>>>>>>>> >>> > >>> } >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> +/** >>>>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>>>> >>> > >>> + */ >>>>>>>>>> >>> > >>> +static void >>>>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>>>> >>> > >>> +{ >>>>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>>>> >>> > >>> + jstring nameString; >>>>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>>>>>> >>> > >>> + NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>>>> name)); >>>>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>>>> setNativeThreadNameID, >>>>>>>>>> >>> > >>> nameString); >>>>>>>>>> >>> > >>> +} >>>>>>>>>> >>> > >>> + >>>>>>>>>> >>> > >>> /* >>>>>>>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>>>> >>> > >>> */ >>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> So I want to add new arg to JVM_SetNativeThreadName(). >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>>> However this is still a change to the exported JVM >>>>>>>>>> interface and so >>>>>>>>>> >>> > >>>> has to be approved. >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> Thanks, >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> Yasumasa >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> [1] >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> >>>>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>>> >>> > >>>>> Hi David, >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>>>> for main >>>>>>>>>> >>> thread and >>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>>>>>> itself as >>>>>>>>>> >>> setName >>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>> thread. >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> I know. >>>>>>>>>> >>> > >>>> >>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>> could be >>>>>>>>>> considered a >>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>> thread >>>>>>>>>> main, even >>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>> first place. >>>>>>>>>> >>> :( Such >>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>> >>> > >>>> >>>>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>>>> JDK-7098194, >>>>>>>>>> and it is >>>>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>>>> >>> > >>>> >>>>>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in 7u2. >>>>>>>>>> >>> > >>>> >>>>>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>>>>> >>> Thread#setNativeName() >>>>>>>>>> >>> > >>>>> only. >>>>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private >>>>>>>>>> method. >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>>>> >>> > >>>>> for force setting. >>>>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>>>> >>> > >>>>> However, this function is NOT public, so I think we >>>>>>>>>> can >>>>>>>>>> add one >>>>>>>>>> >>> more >>>>>>>>>> >>> > >>>>> argument. >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>>>>>> from Java >>>>>>>>>> >>> launcher. >>>>>>>>>> >>> > >>>> >>>>>>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>>>>>> really at >>>>>>>>>> >>> issue. Yes >>>>>>>>>> >>> > >>>> we would add another arg to the JVM function to allow >>>>>>>>>> it to >>>>>>>>>> apply to >>>>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>>>>>> reflect that >>>>>>>>>> >>> not just >>>>>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>>>>> exported JVM >>>>>>>>>> >>> interface >>>>>>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>>>>>> launcher to >>>>>>>>>> >>> use the >>>>>>>>>> >>> > >>>> supported JNI interface (as other processes would), >>>>>>>>>> not the >>>>>>>>>> internal >>>>>>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>>>>>> communicate >>>>>>>>>> >>> with the >>>>>>>>>> >>> > >>>> JVM. >>>>>>>>>> >>> > >>>> >>>>>>>>>> >>> > >>>> David >>>>>>>>>> >>> > >>>> ----- >>>>>>>>>> >>> > >>>> >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> Thanks, >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> Yasumasa >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> >>>>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not tagged as >>>>>>>>>> being a >>>>>>>>>> >>> JNI-attached >>>>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>>>> for main >>>>>>>>>> >>> thread and >>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> Though that will introduce a change in behaviour by >>>>>>>>>> itself as >>>>>>>>>> >>> setName >>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>> thread. >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 >>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu Apr 14 >>>>>>>>>> 13:31:11 >>>>>>>>>> >>> 2016 +0200 >>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri Apr 15 >>>>>>>>>> 17:50:10 >>>>>>>>>> >>> 2016 +0900 >>>>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new JavaThread(true); >>>>>>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization >>>>>>>>>> is complete >>>>>>>>>> >>> - nop if >>>>>>>>>> >>> > >>>>>>> no agents. >>>>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>> >>> > >>>>>>> + >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> I think we can do this straight after the >>>>>>>>>> JavaThread >>>>>>>>>> constructor. >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>>>>>> tracing >>>>>>>>>> >>> > >>>>>>> backend."); >>>>>>>>>> >>> > >>>>>>> } >>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>>> If it wants to name its native threads then it is >>>>>>>>>> free >>>>>>>>>> to do so, >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot change >>>>>>>>>> native >>>>>>>>>> >>> thread name >>>>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>>> >>> > >>>>>>> However, I think that it should be changed if Java >>>>>>>>>> developer >>>>>>>>>> >>> calls >>>>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>>>> >>> > >>>>>>> It is not the same of changing native thread >>>>>>>>>> name at >>>>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>>>> SetNativeThreadName() as >>>>>>>>>> below. >>>>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> The decision to not change the name of JNI-attached >>>>>>>>>> threads was a >>>>>>>>>> >>> > >>>>>> deliberate one** - this functionality originated >>>>>>>>>> with the OSX >>>>>>>>>> >>> port and >>>>>>>>>> >>> > >>>>>> it was reported that the initial feedback with this >>>>>>>>>> feature was to >>>>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>>>>>>>> been set by >>>>>>>>>> >>> the host >>>>>>>>>> >>> > >>>>>> process. If we do as you propose then we will just >>>>>>>>>> have an >>>>>>>>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>>>>>>>> does my >>>>>>>>>> >>> native thread >>>>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> ** If you follow the bugs and related >>>>>>>>>> discussions on >>>>>>>>>> this, the >>>>>>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>>>>>> thread only, >>>>>>>>>> >>> non-JNI >>>>>>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>>>>>> were supposed >>>>>>>>>> >>> to be >>>>>>>>>> >>> > >>>>>> documented in the release notes - but as far as I >>>>>>>>>> can see >>>>>>>>>> that >>>>>>>>>> >>> never >>>>>>>>>> >>> > >>>>>> happened. :( >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> My position on this remains that if it is desirable >>>>>>>>>> for >>>>>>>>>> the main >>>>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native >>>>>>>>>> names >>>>>>>>>> then the >>>>>>>>>> >>> > >>>>>> launcher needs to be setting them using the >>>>>>>>>> available >>>>>>>>>> platform >>>>>>>>>> >>> APIs. >>>>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as evidenced by >>>>>>>>>> the VM >>>>>>>>>> >>> code for >>>>>>>>>> >>> > >>>>>> this - due to the need to verify API availability. >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>>>> Thread.setName would >>>>>>>>>> >>> have to go >>>>>>>>>> >>> > >>>>>> through our CCC process I think. But a change in >>>>>>>>>> the launcher >>>>>>>>>> >>> would >>>>>>>>>> >>> > >>>>>> not. >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> Sorry. >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>> David >>>>>>>>>> >>> > >>>>>> ----- >>>>>>>>>> >>> > >>>>>> >>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu Apr 14 >>>>>>>>>> 13:31:11 >>>>>>>>>> >>> 2016 +0200 >>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri Apr 15 >>>>>>>>>> 17:50:10 >>>>>>>>>> >>> 2016 +0900 >>>>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>>>> >>> > >>>>>>> // Thread naming only supported for the current >>>>>>>>>> thread, >>>>>>>>>> >>> doesn't >>>>>>>>>> >>> > >>>>>>> work >>>>>>>>>> >>> > >>>>>>> for >>>>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>>>>> thread to avoid >>>>>>>>>> >>> stepping >>>>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> >>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> >>>>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>> David, >>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>> this. I >>>>>>>>>> don't like >>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>>>> initializing VM >>>>>>>>>> (before >>>>>>>>>> >>> > >>>>>>>>> calling >>>>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>>>> AttachCurrentThread(). >>>>>>>>>> So we >>>>>>>>>> >>> can't >>>>>>>>>> >>> > >>>>>>>>> set >>>>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier >>>>>>>>>> this >>>>>>>>>> morning. >>>>>>>>>> >>> Which, >>>>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic premise >>>>>>>>>> here that >>>>>>>>>> >>> we don't >>>>>>>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>>>>>>>> The fact >>>>>>>>>> >>> that the >>>>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a >>>>>>>>>> JNI-attached >>>>>>>>>> thread seems >>>>>>>>>> >>> > >>>>>>>> accidental to me - so JVM_SetNativeThreadName is >>>>>>>>>> only >>>>>>>>>> working by >>>>>>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>>>>>> used for the >>>>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>>>>>> inconsistently >>>>>>>>>> >>> named at >>>>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher has >>>>>>>>>> to be >>>>>>>>>> >>> treated like >>>>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>>>>>>>> wants to >>>>>>>>>> name its >>>>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>>>>>>>> would not be >>>>>>>>>> >>> exporting >>>>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>>>>>> have to >>>>>>>>>> use the OS >>>>>>>>>> >>> > >>>>>>>> specific API's for that on a platform-by-platform >>>>>>>>>> basis. >>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>> >>> > >>>>>>>> David >>>>>>>>>> >>> > >>>>>>>> ----- >>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar but >>>>>>>>>> perform >>>>>>>>>> >>> different >>>>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>>>> JVM_SetNativeThreadName >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the current >>>>>>>>>> thread, the >>>>>>>>>> >>> second >>>>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a comment >>>>>>>>>> somewhere >>>>>>>>>> >>> about >>>>>>>>>> >>> > >>>>>>>>>> what >>>>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>>>>> casts to >>>>>>>>>> (void*) >>>>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>>>> >>> used at >>>>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible keep >>>>>>>>>> the cast >>>>>>>>>> >>> on the >>>>>>>>>> >>> > >>>>>>>>>> same >>>>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>> haven't had >>>>>>>>>> time to >>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>> JNI-attached >>>>>>>>>> >>> thread >>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>>>>>> suggestion >>>>>>>>>> >>> should >>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>>>>>> treatment of >>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, >>>>>>>>>> and I >>>>>>>>>> confirmed >>>>>>>>>> >>> native >>>>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) throws >>>>>>>>>> Exception{ >>>>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>> this. I >>>>>>>>>> don't like >>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>>>>>> comment. >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga >>>>>>>>>> wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>>>>>> wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set native >>>>>>>>>> thread >>>>>>>>>> >>> name, and JLI >>>>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another >>>>>>>>>> team so >>>>>>>>>> >>> core-libs will >>>>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>>>>>> Kumar) - >>>>>>>>>> now cc'd. >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java >>>>>>>>>> upcall to >>>>>>>>>> >>> Thread.setName >>>>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>>>> >>> > >>>>>>>>>>>>>> than exporting JVM_SetNativeThreadName. No >>>>>>>>>> hotspot changes >>>>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>>>>> Thread#setName() in >>>>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not alive, >>>>>>>>>> which is >>>>>>>>>> >>> why the >>>>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>>>> attached thread. >>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>> haven't had >>>>>>>>>> time to >>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>> JNI-attached >>>>>>>>>> >>> thread >>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't then my >>>>>>>>>> suggestion >>>>>>>>>> >>> should >>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency in our >>>>>>>>>> treatment of >>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>> this. I >>>>>>>>>> don't like >>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>>>>> function to set >>>>>>>>>> >>> native >>>>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>>>>>>>> well ... >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry >>>>>>>>>> have >>>>>>>>>> been on >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>>>>>>>> correct >>>>>>>>>> as we >>>>>>>>>> >>> do not >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, >>>>>>>>>> which >>>>>>>>>> includes the >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>>>>>>>> wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more reviewer >>>>>>>>>> :-) >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>> >>: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn >>>>>>>>>> wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>>>>> Suenaga wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn >>>>>>>>>> wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>>>>>> Suenaga >>>>>>>>>> wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>> >>> >>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>> >>>>>>>>> >>>: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, Yasumasa >>>>>>>>>> Suenaga wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>> >>>>>>>>> >>>>: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't >>>>>>>>>> set it: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* main_thread = >>>>>>>>>> new >>>>>>>>>> >>> JavaThread(); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>> >>> set_active_handles >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>>>>>>>> something? >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same >>>>>>>>>> to thread >>>>>>>>>> >>> name in >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in Thread or >>>>>>>>>> setName(). >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in Java >>>>>>>>>> app, >>>>>>>>>> native >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main thread is >>>>>>>>>> already >>>>>>>>>> >>> starte >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is set in >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of >>>>>>>>>> setting >>>>>>>>>> thrrad name >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>>>>>>> something like >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>>>> Tue >>>>>>>>>> >>> Mar 29 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>>>> Wed >>>>>>>>>> >>> Mar 30 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>>>> create_initial_thread(Handle >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>>>> initial_thread_name = >>>>>>>>>> >>> "main"; >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> >>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>>>>>> (THREAD, k); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>> >>> thread); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaCalls::call_special(&result, >>>>>>>>>> thread_oop, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev >>>>>>>>>> later. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>>>>>> itself >>>>>>>>>> 'java' and >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>>>>>>>> process >>>>>>>>>> (and >>>>>>>>>> >>> thus >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>>>>>>>> process >>>>>>>>>> is not >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread >>>>>>>>>> with >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is for >>>>>>>>>> >>> JavaThread. So I >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native main >>>>>>>>>> thread. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>>>>>> anyhow, since >>>>>>>>>> >>> we want >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java thread >>>>>>>>>> name >>>>>>>>>> might >>>>>>>>>> >>> have >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. >>>>>>>>>> /proc. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid comm' >>>>>>>>>> | head -4 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something >>>>>>>>>> like >>>>>>>>>> 'Java Main >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a >>>>>>>>>> Java >>>>>>>>>> >>> launcher - e.g. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, >>>>>>>>>> etc. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>>>>>>>> thread >>>>>>>>>> name, >>>>>>>>>> >>> I think >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new webrev? >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>>>>> Yasumasa >>>>>>>>>> >>> Suenaga wrote: >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will set >>>>>>>>>> thread >>>>>>>>>> >>> name via >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread >>>>>>>>>> does not >>>>>>>>>> have it. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have native >>>>>>>>>> name, >>>>>>>>>> and main >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main >>>>>>>>>> thread >>>>>>>>>> should have >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. Could >>>>>>>>>> you >>>>>>>>>> review it? >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>> >>> > >>>>>>>>>> >>> >>>>>>>>>> >>>>>>> >>>>>> From david.holmes at oracle.com Tue Apr 26 09:35:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Apr 2016 19:35:55 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <570F8DDE.5000002@oracle.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> <571EF995.3000109@oracle.com> Message-ID: <571F367B.3010200@oracle.com> On 26/04/2016 7:22 PM, Yasumasa Suenaga wrote: > Hi David, > >> I thought about being able to save/restore the original pending >> exception but could not see a simple way to restore it - ie just by >> poking it back into the thread's pending exception field. The problem >> with using env->Throw is that it acts like the initial throwing of the >> exception and will have a number of side-effects that then get doubled >> up: >> - logging statements (UL and Event logging) >> - OOM counting > > Thanks, I understood. > >>>> so note that we are potentially calling DetachCurrentThread with an >>>> exception pending - which is prohibited by JNI**, but which we >>>> actually rely on for desired operation as DetachCurrentThread calls >>>> thread->exit() which performs uncaught exception handling (ie it >>>> prints the exception message and stacktrace) and then clears the >>>> exception! (Hence DestroyJavaVM is not called with any pending >>>> exceptions.) > > I think we can call uncaught exception handler before calling > DestroyJavaVM(). > I added it in new webrev for jdk: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/hotspot/ > http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/jdk/ > > DispatchUncaughtException() in java.c emulates uncaught exception handler > call in JavaThread::exit(). > I think this patch can provide the solution for our issue. > > Could you check it? Sorry - this is getting far too disruptive. I do not support changing the way the main thread behaves upon completion, just because we want to set a native thread name. David ----- > > Thanks, > > Yasumasa > > > On 2016/04/26 14:16, David Holmes wrote: >> On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: >>> Hi David, Kumar, >>> >>> I think that we should evacuate original exception before DestroyJavaVM >>> thread name is set. >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ >>> >>> I added it to LEAVE macro in new webrev. >> >> BTW: in the LEAVE macro, stylistically all the code should be in the >> do { } while(false); loop. I overlooked that initially. >> >>> I tested it with following code. It works fine. >>> >>> ------------- >>> public void main(String[] args){ >>> throw new RuntimeException("test"); >>> } >>> ------------- >>> >>> What do you think about it? >> >> I thought about being able to save/restore the original pending >> exception but could not see a simple way to restore it - ie just by >> poking it back into the thread's pending exception field. The problem >> with using env->Throw is that it acts like the initial throwing of the >> exception and will have a number of side-effects that then get doubled >> up: >> - logging statements (UL and Event logging) >> - OOM counting >> >> I'm not sure whether that is acceptable or not >> >> That aside you should check if orig_throwable is non-null before >> clearing to avoid an unnecessary JNI call. >> >> Also "Resume original exception" -> "Restore any original exception" >> >> Thanks, >> David >> ----- >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/26 11:16, David Holmes wrote: >>>> Hi Yasumasa, Kumar, >>>> >>>> Turns out this change breaks the behaviour of the launcher in the case >>>> that main() completes by throwing an exception. >>>> >>>> What we have in the launcher is: >>>> >>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; >>>> LEAVE(); >>>> >>>> where LEAVE would have expanded to: >>>> >>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>> ret = 1; \ >>>> } \ >>>> if (JNI_TRUE) { \ >>>> (*vm)->DestroyJavaVM(vm); \ >>>> return ret; \ >>>> } \ >>>> >>>> so note that we are potentially calling DetachCurrentThread with an >>>> exception pending - which is prohibited by JNI**, but which we >>>> actually rely on for desired operation as DetachCurrentThread calls >>>> thread->exit() which performs uncaught exception handling (ie it >>>> prints the exception message and stacktrace) and then clears the >>>> exception! (Hence DestroyJavaVM is not called with any pending >>>> exceptions.) >>>> >>>> **JNI spec needs to be modified here. >>>> >>>> With the current change we have now inserted the following at the >>>> start of LEAVE: >>>> >>>> SetNativeThreadName(env, "DestroyJavaVM"); \ >>>> if ((*env)->ExceptionOccurred(env)) { \ >>>> (*env)->ExceptionClear(env); \ >>>> } \ >>>> >>>> this has two unintended consequences: >>>> >>>> 1. SetNativeThreadName itself calls a number of JNI methods, with the >>>> exception pending - which is not permitted. So straight away where we >>>> have: >>>> >>>> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >>>> >>>> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make calls >>>> using the VM's CHECK_NULL macro - which checks for a pending exception >>>> (which it finds) and returns NULL. So the jli NULL_CHECK macro then >>>> reports a JNI error: >>>> >>>> Error: A JNI error has occurred, please check your installation and >>>> try again >>>> >>>> >>>> 2. There is no longer an exception from main() for DetachCurrentThread >>>> to report, so we exit with a return code of 1 as required, but don't >>>> report the exception message/stacktrace. >>>> >>>> I don't see a reasonable solution for this other than abandoning the >>>> attempt to change the name from "main" to "DestroyJavaVM" - which if >>>> we can't do, I question the utility of setting the name in the first >>>> place (while it might be useful in some circumstances [when main() is >>>> running] it will cause confusion in others [when main() has exited]). >>>> >>>> David >>>> ----- >>>> >>>> On 25/04/2016 3:47 PM, David Holmes wrote: >>>>> Looks good to me. >>>>> >>>>> I'll sponsor this "tomorrow". >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>>>>> Hi Kumar, >>>>>> >>>>>> Thank you for your comment! >>>>>> I've fixed them and uploaded new webrev. Could you review again? >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>>>>> >>>>>>> Also a couple of minor suggestions: >>>>>>> >>>>>>> - * Set native thread name as possible. >>>>>>> + * Set native thread name if possible. >>>>>>> >>>>>>> >>>>>>> + /* >>>>>>> - * We can clear pending exception because exception at this >>>>>>> point >>>>>>> - * is not critical. >>>>>>> + */ >>>>>>> >>>>>>> + /* >>>>>>> + * Clear non critical pending exceptions at this point. >>>>>>> + */ >>>>>>> >>>>>>> Thanks >>>>>>> Kumar >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is in the wrong place: >>>>>>>> >>>>>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>> 1716 /* >>>>>>>> 1717 * We can clear pending exception because exception at >>>>>>>> this point >>>>>>>> 1718 * is not critical. >>>>>>>> 1719 */ >>>>>>>> 1720 (*env)->ExceptionClear(env); >>>>>>>> 1721 } >>>>>>>> >>>>>>>> This above needs to be after >>>>>>>> 391 SetNativeThreadName(env, "main"); >>>>>>>> 392 >>>>>>>> >>>>>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>>>>> but have also encountered an exception. In which case >>>>>>>> the method SetNativeThreadName will return to the caller, as >>>>>>>> if nothing has happened, because NULL_CHECK simply checks for NULL >>>>>>>> and returns to the caller. This will cause the caller to enter >>>>>>>> the VM with exceptions. >>>>>>>> >>>>>>>> Kumar >>>>>>>> >>>>>>>> >>>>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>> ignore >>>>>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>>>> >>>>>>>>> I've fixed it in new webrev: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I have uploaded webrev.04 as below. >>>>>>>>>>> Could you review again? >>>>>>>>>>> >>>>>>>>>>> > - hotspot: >>>>>>>>>>> > >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Looks fine. >>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> > - jdk: >>>>>>>>>>> > >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>> >>>>>>>>>> As per private email (but repeated here on the record) in java.c: >>>>>>>>>> >>>>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>>>>> 1717 } >>>>>>>>>> >>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>> ignore >>>>>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>>>>> >: >>>>>>>>>>> > >>>>>>>>>>> > Hi David, >>>>>>>>>>> > >>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>> > >>>>>>>>>>> > - hotspot: >>>>>>>>>>> > >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> > - jdk: >>>>>>>>>>> > >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>>>>> process, I >>>>>>>>>>> would have done it immediately after here: >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > I think that native thread name ("main") should be set just >>>>>>>>>>> before >>>>>>>>>>> > main method call. >>>>>>>>>>> > However, main thread is already started, so I moved it as you >>>>>>>>>>> suggested. >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>>> have to >>>>>>>>>>> go from char* to java.lang.String to call setNativeName which >>>>>>>>>>> then >>>>>>>>>>> calls >>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>>>>> char* ! >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > SoI proposed to export new JVM function to set native thread >>>>>>>>>>> name with >>>>>>>>>>> > const char *. >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > Thanks, >>>>>>>>>>> > >>>>>>>>>>> > Yasumasa >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>>>>> >> >>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>> >> >>>>>>>>>>> >> Thanks for persevering with this to get it into the current >>>>>>>>>>> form. >>>>>>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>>>>>> >> >>>>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>> >>>>>>>>>>> >>> Hi Gerard, >>>>>>>>>>> >>> >>>>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>> >>: >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > hi Yasumasa, >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > ======== >>>>>>>>>>> >>> > File: java.c >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>>> >>> after every single JNI call? In this example instead of >>>>>>>>>>> NULL_CHECK, >>>>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>>> >>> >>>>>>>>>>> >>> It is not critical if we encounter error at JNI function >>>>>>>>>>> call >>>>>>>>>>> because >>>>>>>>>>> >>> we cannot set native thread name only. >>>>>>>>>>> >>> So I think that we do not need to leave from launcher >>>>>>>>>>> process. >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> I agree we do not need to abort if an exception occurs >>>>>>>>>>> (and in >>>>>>>>>>> fact >>>>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>>>> but we >>>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>>> futher JNI >>>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>>> extensively >>>>>>>>>>> throughout the launcher code - so if this usage is wrong then it >>>>>>>>>>> is all >>>>>>>>>>> wrong! More on this code below ... >>>>>>>>>>> >> >>>>>>>>>>> >> Other comments: >>>>>>>>>>> >> >>>>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>>>>> >> >>>>>>>>>>> >> Please add a comment to the method now that you removed the >>>>>>>>>>> internal >>>>>>>>>>> comment: >>>>>>>>>>> >> >>>>>>>>>>> >> // Sets the native thread name for a JavaThread. If >>>>>>>>>>> specifically >>>>>>>>>>> >> // requested JNI-attached threads can also have their native >>>>>>>>>>> name set; >>>>>>>>>>> >> // otherwise we do not modify JNI-attached threads as it may >>>>>>>>>>> interfere >>>>>>>>>>> >> // with the application that created them. >>>>>>>>>>> >> >>>>>>>>>>> >> --- >>>>>>>>>>> >> >>>>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>>>>> >> >>>>>>>>>>> >> Please add the following comments: >>>>>>>>>>> >> >>>>>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>>>>> >> setNativeName(name, false); >>>>>>>>>>> >> >>>>>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>>>>> permitted) to >>>>>>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>>>>>> >> private native void setNativeName(String name, boolean >>>>>>>>>>> allowAttachedThread); >>>>>>>>>>> >> >>>>>>>>>>> >> --- >>>>>>>>>>> >> >>>>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>>>>> >> >>>>>>>>>>> >> 328 #define LEAVE() \ >>>>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>> >> >>>>>>>>>>> >> I was going to suggest this be set later, but realized we >>>>>>>>>>> have >>>>>>>>>>> to be >>>>>>>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>>>>>>> >> >>>>>>>>>>> >> + /* Set native thread name. */ >>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>> >> >>>>>>>>>>> >> The comment is redundant given the name of the method. That >>>>>>>>>>> aside >>>>>>>>>>> I'm not sure why you do this so late in the process, I would >>>>>>>>>>> have >>>>>>>>>>> done >>>>>>>>>>> it immediately after here: >>>>>>>>>>> >> >>>>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>>>>> >> 388 exit(1); >>>>>>>>>>> >> 389 } >>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> + /** >>>>>>>>>>> >> + * Set native thread name as possible. >>>>>>>>>>> >> + */ >>>>>>>>>>> >> >>>>>>>>>>> >> Other than the as->if change I'm unclear where the >>>>>>>>>>> "possible" >>>>>>>>>>> bit >>>>>>>>>>> comes into play - why would it not be possible? >>>>>>>>>>> >> >>>>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>>>>> "java/lang/Thread")); >>>>>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>>>>> cls, >>>>>>>>>>> >> 1707 "currentThread", >>>>>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>>>>> >> 1709 currentThreadID)); >>>>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = >>>>>>>>>>> (*env)->GetMethodID(env, >>>>>>>>>>> cls, >>>>>>>>>>> >> 1711 "setNativeName", >>>>>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>>>>> name)); >>>>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>>>>> setNativeNameID, >>>>>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>>>>> >> >>>>>>>>>>> >> As above NULL_CHECK is fine here, but we should check for >>>>>>>>>>> and >>>>>>>>>>> clear >>>>>>>>>>> any pending exception after CallVoidMethod. >>>>>>>>>>> >> >>>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>>> have to >>>>>>>>>>> go from char* to java.lang.String to call setNativeName which >>>>>>>>>>> then >>>>>>>>>>> calls >>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>>>>> char* ! >>>>>>>>>>> Overall I wonder about the affect on startup cost. But if there >>>>>>>>>>> is an >>>>>>>>>>> issue we can revisit this. >>>>>>>>>>> >> >>>>>>>>>>> >> Thanks, >>>>>>>>>>> >> David >>>>>>>>>>> >> ----- >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set >>>>>>>>>>> native >>>>>>>>>>> thread >>>>>>>>>>> >>> name if possible.? not "Set native thread name as >>>>>>>>>>> possible.?? >>>>>>>>>>> >>> >>>>>>>>>>> >>> Sorry for my bad English :-) >>>>>>>>>>> >>> >>>>>>>>>>> >>> Thanks, >>>>>>>>>>> >>> >>>>>>>>>>> >>> Yasumasa >>>>>>>>>>> >>> >>>>>>>>>>> >>> > cheers >>>>>>>>>>> >>> > >>>>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>>>>> >>>>>>>>>>> >>> >> >>>>>>>>>>> wrote: >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > Hi David, >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > I uploaded new webrev: >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > - hotspot: >>>>>>>>>>> >>> > > >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > - jdk: >>>>>>>>>>> >>> > > >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>>>>> setName so I'm >>>>>>>>>>> >>> not sure what you were thinking here. To take advantage >>>>>>>>>>> of an >>>>>>>>>>> arg >>>>>>>>>>> taking >>>>>>>>>>> >>> JVM_SetNativThreadName you would need to call it >>>>>>>>>>> directly as >>>>>>>>>>> no Java >>>>>>>>>>> >>> code will call it . ??? >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>>>>> JNI-attached >>>>>>>>>>> thread. >>>>>>>>>>> >>> > > This change can set native thread name if main thread >>>>>>>>>>> changes to >>>>>>>>>>> >>> JNI-attached thread. >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > Thanks, >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > Yasumasa >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > >>>>>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>> > >>> Hi David, >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>> could be >>>>>>>>>>> considered a >>>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>>> thread >>>>>>>>>>> main, even >>>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>>> first place. >>>>>>>>>>> >>> :( Such >>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> I understood. >>>>>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at >>>>>>>>>>> Oracle.) >>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>>>>>>>>> sponsor for >>>>>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>>>>> proposed change >>>>>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>>>>> restore the >>>>>>>>>>> >>> "broken" behaviour. >>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >>> I want to continue to discuss about it on >>>>>>>>>>> JDK-8154331 >>>>>>>>>>> [1]. >>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >> Okay we can do that. >>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>>> Further, we expect the launcher to use the >>>>>>>>>>> supported >>>>>>>>>>> JNI >>>>>>>>>>> >>> interface (as >>>>>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>>>>> interface that >>>>>>>>>>> >>> exists for >>>>>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> I think that we do not use JVM interface if we >>>>>>>>>>> add new >>>>>>>>>>> method in >>>>>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>> >>> > >>> >>>>>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>> >>> > >>> --- >>>>>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>>>>> >>> > >>> +++ >>>>>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>>>>> >>> > >>> else >>>>>>>>>>> >>> > >>> return md.toNameAndVersion() + " (" >>>>>>>>>>> + loc >>>>>>>>>>> + ")"; >>>>>>>>>>> >>> > >>> } >>>>>>>>>>> >>> > >>> + >>>>>>>>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>>>>> >>> > >>> + } >>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >> You could also make that call via JNI directly, so >>>>>>>>>>> not >>>>>>>>>>> sure the >>>>>>>>>>> >>> helper adds much here. But it won't work unless you change >>>>>>>>>>> the >>>>>>>>>>> semantics >>>>>>>>>>> >>> of setName so I'm not sure what you were thinking here. To >>>>>>>>>>> take >>>>>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>>>>>>>>> need to >>>>>>>>>>> call >>>>>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >> David >>>>>>>>>>> >>> > >> ----- >>>>>>>>>>> >>> > >> >>>>>>>>>>> >>> > >>> } >>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c >>>>>>>>>>> Wed >>>>>>>>>>> Apr 13 >>>>>>>>>>> 14:19:30 >>>>>>>>>>> >>> > >>> 2016 +0000 >>>>>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c >>>>>>>>>>> Sat >>>>>>>>>>> Apr 16 >>>>>>>>>>> 11:25:53 >>>>>>>>>>> >>> > >>> 2016 +0900 >>>>>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean >>>>>>>>>>> doXUsage); >>>>>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char >>>>>>>>>>> *optString); >>>>>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char >>>>>>>>>>> *optString); >>>>>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>>>>>>> *name); >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>>>>> >>> > >>> */ >>>>>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>> >>> > >>> do { \ >>>>>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != >>>>>>>>>>> JNI_OK) >>>>>>>>>>> { \ >>>>>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, >>>>>>>>>>> argc); >>>>>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>>>>> >>> > >>> + >>>>>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>>>>>> mainArgs); >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>>>>> >>> > >>> joptString); >>>>>>>>>>> >>> > >>> } >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> +/** >>>>>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>>>>> >>> > >>> + */ >>>>>>>>>>> >>> > >>> +static void >>>>>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>>>>> >>> > >>> +{ >>>>>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>>>>> >>> > >>> + jstring nameString; >>>>>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>>>>>>> >>> > >>> + NULL_CHECK(nameString = >>>>>>>>>>> (*env)->NewStringUTF(env, >>>>>>>>>>> name)); >>>>>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>>>>> setNativeThreadNameID, >>>>>>>>>>> >>> > >>> nameString); >>>>>>>>>>> >>> > >>> +} >>>>>>>>>>> >>> > >>> + >>>>>>>>>>> >>> > >>> /* >>>>>>>>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>>>>> >>> > >>> */ >>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> So I want to add new arg to >>>>>>>>>>> JVM_SetNativeThreadName(). >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>>> However this is still a change to the exported JVM >>>>>>>>>>> interface and so >>>>>>>>>>> >>> > >>>> has to be approved. >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> Thanks, >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> Yasumasa >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> [1] >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> >>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> >>>>>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>> > >>>>> Hi David, >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>>>>> for main >>>>>>>>>>> >>> thread and >>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>> behaviour by >>>>>>>>>>> itself as >>>>>>>>>>> >>> setName >>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>>> thread. >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> I know. >>>>>>>>>>> >>> > >>>> >>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>> could be >>>>>>>>>>> considered a >>>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>>> thread >>>>>>>>>>> main, even >>>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>>> first place. >>>>>>>>>>> >>> :( Such >>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>> >>> > >>>> >>>>>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>>>>> JDK-7098194, >>>>>>>>>>> and it is >>>>>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>>>>> >>> > >>>> >>>>>>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in >>>>>>>>>>> 7u2. >>>>>>>>>>> >>> > >>>> >>>>>>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>>>>>> >>> Thread#setNativeName() >>>>>>>>>>> >>> > >>>>> only. >>>>>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private >>>>>>>>>>> method. >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>>>>> >>> > >>>>> for force setting. >>>>>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>>>>> >>> > >>>>> However, this function is NOT public, so I >>>>>>>>>>> think we >>>>>>>>>>> can >>>>>>>>>>> add one >>>>>>>>>>> >>> more >>>>>>>>>>> >>> > >>>>> argument. >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>>>>>>> from Java >>>>>>>>>>> >>> launcher. >>>>>>>>>>> >>> > >>>> >>>>>>>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>>>>>>> really at >>>>>>>>>>> >>> issue. Yes >>>>>>>>>>> >>> > >>>> we would add another arg to the JVM function to >>>>>>>>>>> allow >>>>>>>>>>> it to >>>>>>>>>>> apply to >>>>>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>>>>>>> reflect that >>>>>>>>>>> >>> not just >>>>>>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>>>>>> exported JVM >>>>>>>>>>> >>> interface >>>>>>>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>>>>>>> launcher to >>>>>>>>>>> >>> use the >>>>>>>>>>> >>> > >>>> supported JNI interface (as other processes would), >>>>>>>>>>> not the >>>>>>>>>>> internal >>>>>>>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>>>>>>> communicate >>>>>>>>>>> >>> with the >>>>>>>>>>> >>> > >>>> JVM. >>>>>>>>>>> >>> > >>>> >>>>>>>>>>> >>> > >>>> David >>>>>>>>>>> >>> > >>>> ----- >>>>>>>>>>> >>> > >>>> >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> Thanks, >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> Yasumasa >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> >>>>>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not >>>>>>>>>>> tagged as >>>>>>>>>>> being a >>>>>>>>>>> >>> JNI-attached >>>>>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>>>>> for main >>>>>>>>>>> >>> thread and >>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>> behaviour by >>>>>>>>>>> itself as >>>>>>>>>>> >>> setName >>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>>> thread. >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 >>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>> Apr 14 >>>>>>>>>>> 13:31:11 >>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri >>>>>>>>>>> Apr 15 >>>>>>>>>>> 17:50:10 >>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new >>>>>>>>>>> JavaThread(true); >>>>>>>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization >>>>>>>>>>> is complete >>>>>>>>>>> >>> - nop if >>>>>>>>>>> >>> > >>>>>>> no agents. >>>>>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>>> >>> > >>>>>>> + >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> I think we can do this straight after the >>>>>>>>>>> JavaThread >>>>>>>>>>> constructor. >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>>>>>>> tracing >>>>>>>>>>> >>> > >>>>>>> backend."); >>>>>>>>>>> >>> > >>>>>>> } >>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>>> If it wants to name its native threads then >>>>>>>>>>> it is >>>>>>>>>>> free >>>>>>>>>>> to do so, >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot >>>>>>>>>>> change >>>>>>>>>>> native >>>>>>>>>>> >>> thread name >>>>>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>>>> >>> > >>>>>>> However, I think that it should be changed if >>>>>>>>>>> Java >>>>>>>>>>> developer >>>>>>>>>>> >>> calls >>>>>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>>>>> >>> > >>>>>>> It is not the same of changing native thread >>>>>>>>>>> name at >>>>>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>>>>> SetNativeThreadName() as >>>>>>>>>>> below. >>>>>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> The decision to not change the name of >>>>>>>>>>> JNI-attached >>>>>>>>>>> threads was a >>>>>>>>>>> >>> > >>>>>> deliberate one** - this functionality originated >>>>>>>>>>> with the OSX >>>>>>>>>>> >>> port and >>>>>>>>>>> >>> > >>>>>> it was reported that the initial feedback with >>>>>>>>>>> this >>>>>>>>>>> feature was to >>>>>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>>>>>>>>> been set by >>>>>>>>>>> >>> the host >>>>>>>>>>> >>> > >>>>>> process. If we do as you propose then we will >>>>>>>>>>> just >>>>>>>>>>> have an >>>>>>>>>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>>>>>>>>> does my >>>>>>>>>>> >>> native thread >>>>>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> ** If you follow the bugs and related >>>>>>>>>>> discussions on >>>>>>>>>>> this, the >>>>>>>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>>>>>>> thread only, >>>>>>>>>>> >>> non-JNI >>>>>>>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>>>>>>> were supposed >>>>>>>>>>> >>> to be >>>>>>>>>>> >>> > >>>>>> documented in the release notes - but as far as I >>>>>>>>>>> can see >>>>>>>>>>> that >>>>>>>>>>> >>> never >>>>>>>>>>> >>> > >>>>>> happened. :( >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> My position on this remains that if it is >>>>>>>>>>> desirable >>>>>>>>>>> for >>>>>>>>>>> the main >>>>>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native >>>>>>>>>>> names >>>>>>>>>>> then the >>>>>>>>>>> >>> > >>>>>> launcher needs to be setting them using the >>>>>>>>>>> available >>>>>>>>>>> platform >>>>>>>>>>> >>> APIs. >>>>>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as >>>>>>>>>>> evidenced by >>>>>>>>>>> the VM >>>>>>>>>>> >>> code for >>>>>>>>>>> >>> > >>>>>> this - due to the need to verify API >>>>>>>>>>> availability. >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>>>>> Thread.setName would >>>>>>>>>>> >>> have to go >>>>>>>>>>> >>> > >>>>>> through our CCC process I think. But a change in >>>>>>>>>>> the launcher >>>>>>>>>>> >>> would >>>>>>>>>>> >>> > >>>>>> not. >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> Sorry. >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>> David >>>>>>>>>>> >>> > >>>>>> ----- >>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu >>>>>>>>>>> Apr 14 >>>>>>>>>>> 13:31:11 >>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri >>>>>>>>>>> Apr 15 >>>>>>>>>>> 17:50:10 >>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>>>>> >>> > >>>>>>> // Thread naming only supported for the >>>>>>>>>>> current >>>>>>>>>>> thread, >>>>>>>>>>> >>> doesn't >>>>>>>>>>> >>> > >>>>>>> work >>>>>>>>>>> >>> > >>>>>>> for >>>>>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>>>>>> thread to avoid >>>>>>>>>>> >>> stepping >>>>>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> >>>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>> David, >>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>> this. I >>>>>>>>>>> don't like >>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>>>>> initializing VM >>>>>>>>>>> (before >>>>>>>>>>> >>> > >>>>>>>>> calling >>>>>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>>>>> AttachCurrentThread(). >>>>>>>>>>> So we >>>>>>>>>>> >>> can't >>>>>>>>>>> >>> > >>>>>>>>> set >>>>>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier >>>>>>>>>>> this >>>>>>>>>>> morning. >>>>>>>>>>> >>> Which, >>>>>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic >>>>>>>>>>> premise >>>>>>>>>>> here that >>>>>>>>>>> >>> we don't >>>>>>>>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>>>>>>>>> The fact >>>>>>>>>>> >>> that the >>>>>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a >>>>>>>>>>> JNI-attached >>>>>>>>>>> thread seems >>>>>>>>>>> >>> > >>>>>>>> accidental to me - so >>>>>>>>>>> JVM_SetNativeThreadName is >>>>>>>>>>> only >>>>>>>>>>> working by >>>>>>>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>>>>>>> used for the >>>>>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>>>>>>> inconsistently >>>>>>>>>>> >>> named at >>>>>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher >>>>>>>>>>> has >>>>>>>>>>> to be >>>>>>>>>>> >>> treated like >>>>>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>>>>>>>>> wants to >>>>>>>>>>> name its >>>>>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>>>>>>>>> would not be >>>>>>>>>>> >>> exporting >>>>>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>>>>>>> have to >>>>>>>>>>> use the OS >>>>>>>>>>> >>> > >>>>>>>> specific API's for that on a >>>>>>>>>>> platform-by-platform >>>>>>>>>>> basis. >>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>> >>> > >>>>>>>> David >>>>>>>>>>> >>> > >>>>>>>> ----- >>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar >>>>>>>>>>> but >>>>>>>>>>> perform >>>>>>>>>>> >>> different >>>>>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>>>>> JVM_SetNativeThreadName >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the current >>>>>>>>>>> thread, the >>>>>>>>>>> >>> second >>>>>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a >>>>>>>>>>> comment >>>>>>>>>>> somewhere >>>>>>>>>>> >>> about >>>>>>>>>>> >>> > >>>>>>>>>> what >>>>>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>>>>>> casts to >>>>>>>>>>> (void*) >>>>>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>>>>> >>> used at >>>>>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible >>>>>>>>>>> keep >>>>>>>>>>> the cast >>>>>>>>>>> >>> on the >>>>>>>>>>> >>> > >>>>>>>>>> same >>>>>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>> haven't had >>>>>>>>>>> time to >>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>>> JNI-attached >>>>>>>>>>> >>> thread >>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>> then my >>>>>>>>>>> suggestion >>>>>>>>>>> >>> should >>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>> in our >>>>>>>>>>> treatment of >>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, >>>>>>>>>>> and I >>>>>>>>>>> confirmed >>>>>>>>>>> >>> native >>>>>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) >>>>>>>>>>> throws >>>>>>>>>>> Exception{ >>>>>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>> this. I >>>>>>>>>>> don't like >>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>>>>>>> comment. >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga >>>>>>>>>>> wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>>>>>>> wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set >>>>>>>>>>> native >>>>>>>>>>> thread >>>>>>>>>>> >>> name, and JLI >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another >>>>>>>>>>> team so >>>>>>>>>>> >>> core-libs will >>>>>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>>>>>>> Kumar) - >>>>>>>>>>> now cc'd. >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java >>>>>>>>>>> upcall to >>>>>>>>>>> >>> Thread.setName >>>>>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>>>>> >>> > >>>>>>>>>>>>>> than exporting >>>>>>>>>>> JVM_SetNativeThreadName. No >>>>>>>>>>> hotspot changes >>>>>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>>>>>> Thread#setName() in >>>>>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not >>>>>>>>>>> alive, >>>>>>>>>>> which is >>>>>>>>>>> >>> why the >>>>>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>>>>> attached thread. >>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>> haven't had >>>>>>>>>>> time to >>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>>> JNI-attached >>>>>>>>>>> >>> thread >>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>> then my >>>>>>>>>>> suggestion >>>>>>>>>>> >>> should >>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>> in our >>>>>>>>>>> treatment of >>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>> this. I >>>>>>>>>>> don't like >>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>>>>>> function to set >>>>>>>>>>> >>> native >>>>>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>>>>>>>>> well ... >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry >>>>>>>>>>> have >>>>>>>>>>> been on >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>>>>>>>>> correct >>>>>>>>>>> as we >>>>>>>>>>> >>> do not >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, >>>>>>>>>>> which >>>>>>>>>>> includes the >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>>>>>>>>> wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more >>>>>>>>>>> reviewer >>>>>>>>>>> :-) >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>> >>: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn >>>>>>>>>>> wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>>>>>> Suenaga wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn >>>>>>>>>>> wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>>>>>>> Suenaga >>>>>>>>>>> wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>> >>> >>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>> >>>: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, >>>>>>>>>>> Yasumasa >>>>>>>>>>> Suenaga wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>> >>>>: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't >>>>>>>>>>> set it: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* >>>>>>>>>>> main_thread = >>>>>>>>>>> new >>>>>>>>>>> >>> JavaThread(); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>>> >>> set_active_handles >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>>>>>>>>> something? >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same >>>>>>>>>>> to thread >>>>>>>>>>> >>> name in >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in >>>>>>>>>>> Thread or >>>>>>>>>>> setName(). >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in >>>>>>>>>>> Java >>>>>>>>>>> app, >>>>>>>>>>> native >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main >>>>>>>>>>> thread is >>>>>>>>>>> already >>>>>>>>>>> >>> starte >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is >>>>>>>>>>> set in >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of >>>>>>>>>>> setting >>>>>>>>>>> thrrad name >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>>>>>>>> something like >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>>>>> Tue >>>>>>>>>>> >>> Mar 29 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>>>>> Wed >>>>>>>>>>> >>> Mar 30 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>>>>> create_initial_thread(Handle >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>>>>> initial_thread_name = >>>>>>>>>>> >>> "main"; >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> >>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>>>>>>> (THREAD, k); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>> >>> thread); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>> thread_oop, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev >>>>>>>>>>> later. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>>>>>>> itself >>>>>>>>>>> 'java' and >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>>>>>>>>> process >>>>>>>>>>> (and >>>>>>>>>>> >>> thus >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>>>>>>>>> process >>>>>>>>>>> is not >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread >>>>>>>>>>> with >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is >>>>>>>>>>> for >>>>>>>>>>> >>> JavaThread. So I >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native >>>>>>>>>>> main >>>>>>>>>>> thread. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>>>>>>> anyhow, since >>>>>>>>>>> >>> we want >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java >>>>>>>>>>> thread >>>>>>>>>>> name >>>>>>>>>>> might >>>>>>>>>>> >>> have >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. >>>>>>>>>>> /proc. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid >>>>>>>>>>> comm' >>>>>>>>>>> | head -4 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something >>>>>>>>>>> like >>>>>>>>>>> 'Java Main >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a >>>>>>>>>>> Java >>>>>>>>>>> >>> launcher - e.g. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, >>>>>>>>>>> etc. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>>>>>>>>> thread >>>>>>>>>>> name, >>>>>>>>>>> >>> I think >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new >>>>>>>>>>> webrev? >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>> Suenaga wrote: >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will >>>>>>>>>>> set >>>>>>>>>>> thread >>>>>>>>>>> >>> name via >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread >>>>>>>>>>> does not >>>>>>>>>>> have it. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have >>>>>>>>>>> native >>>>>>>>>>> name, >>>>>>>>>>> and main >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main >>>>>>>>>>> thread >>>>>>>>>>> should have >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. >>>>>>>>>>> Could >>>>>>>>>>> you >>>>>>>>>>> review it? >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>> >>> > >>>>>>>>>>> >>> >>>>>>>>>>> >>>>>>>> >>>>>>> From david.holmes at oracle.com Tue Apr 26 09:36:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Apr 2016 19:36:51 +1000 Subject: RFR(XXS): 8155085: [ppc] Fix Type-O in "8154580: Save mirror in interpreter frame..." In-Reply-To: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> References: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> Message-ID: <571F36B3.6070007@oracle.com> Reviewed! Thanks, David On 26/04/2016 7:10 PM, Lindenmaier, Goetz wrote: > Hi, > > I please need a review for this tiny fix of a Type-O. A single letter is missing: > http://cr.openjdk.java.net/~goetz/wr16/8155085-TypeO/webrev.00/ > > Best regards, > Goetz. > From mikael.gerdin at oracle.com Tue Apr 26 09:57:43 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 26 Apr 2016 11:57:43 +0200 Subject: RFR(XXS): 8155085: [ppc] Fix Type-O in "8154580: Save mirror in interpreter frame..." In-Reply-To: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> References: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> Message-ID: <571F3B97.8050503@oracle.com> Hi Goetz, On 2016-04-26 11:10, Lindenmaier, Goetz wrote: > Hi, > > I please need a review for this tiny fix of a Type-O. A single letter is missing: > http://cr.openjdk.java.net/~goetz/wr16/8155085-TypeO/webrev.00/ Looks good. /Mikael > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Tue Apr 26 10:07:16 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Apr 2016 10:07:16 +0000 Subject: RFR(XXS): 8155085: [ppc] Fix Type-O in "8154580: Save mirror in interpreter frame..." In-Reply-To: <571F36B3.6070007@oracle.com> References: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> <571F36B3.6070007@oracle.com> Message-ID: <5c8058f49e5249f399e70ac0a6ac7179@DEWDFE13DE09.global.corp.sap> Thanks David! > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 26. April 2016 11:37 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(XXS): 8155085: [ppc] Fix Type-O in "8154580: Save mirror in > interpreter frame..." > > Reviewed! > > Thanks, > David > > On 26/04/2016 7:10 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > I please need a review for this tiny fix of a Type-O. A single letter is missing: > > http://cr.openjdk.java.net/~goetz/wr16/8155085-TypeO/webrev.00/ > > > > Best regards, > > Goetz. > > From goetz.lindenmaier at sap.com Tue Apr 26 10:07:32 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Apr 2016 10:07:32 +0000 Subject: RFR(XXS): 8155085: [ppc] Fix Type-O in "8154580: Save mirror in interpreter frame..." In-Reply-To: <571F3B97.8050503@oracle.com> References: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> <571F3B97.8050503@oracle.com> Message-ID: <1e5ac733a6ca42bc8a69dcdfe2bffaa3@DEWDFE13DE09.global.corp.sap> Thanks Mikael! > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Mikael Gerdin > Sent: Dienstag, 26. April 2016 11:58 > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(XXS): 8155085: [ppc] Fix Type-O in "8154580: Save mirror in > interpreter frame..." > > Hi Goetz, > > > On 2016-04-26 11:10, Lindenmaier, Goetz wrote: > > Hi, > > > > I please need a review for this tiny fix of a Type-O. A single letter is missing: > > http://cr.openjdk.java.net/~goetz/wr16/8155085-TypeO/webrev.00/ > > Looks good. > > /Mikael > > > > > Best regards, > > Goetz. > > From marcus.larsson at oracle.com Tue Apr 26 10:41:49 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 26 Apr 2016 12:41:49 +0200 Subject: RFR (XXS): 8149442 : MonitorInUseLists should be on by default, deflate idle monitors taking too long In-Reply-To: <56FE35E3.8070001@oracle.com> References: <56FE35E3.8070001@oracle.com> Message-ID: <571F45ED.5030508@oracle.com> Hi, On 2016-04-01 10:48, David Simms wrote: > > Greetings, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149442 > Webrev: http://cr.openjdk.java.net/~dsimms/8149442/ Looks good to me! Thanks, Marcus > > Safe-point's "deflate_idle_monitors" (clean up task during > Safepoint::begin()), constantly scans all monitors, the entire > population. Setting MonitorInUseLists to true by default would seem > prudent, as the it reduces the scan to "InUse" thread lists. Reduction > in "deflate idle monitor" execution time of up to a magnitude. > > There are certain applications (notably SPECjbb2013 use of ForkJoin) > whose Java lock monitor total populations are quite high, but the > actual number of in use monitors is low. > > Why these total populations grow so large, further work to reduce > "deflate idle monitor" operations, is beyond the scope of this bug > (see JDK-7021979 & JDK-8153224). > > Testing: no regressions spotted on the following benchmarks: > > * SpecJbb2005 > * SpecJbb2008 > * SpecJbb2013 > * Volano > > > > Cheers > / David Simms From yasuenag at gmail.com Tue Apr 26 12:54:54 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Apr 2016 21:54:54 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571F367B.3010200@oracle.com> References: <56F3F90D.9010408@gmail.com> <570F9BFE.8010400@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> <571EF995.3000109@oracle.com> <571F367B.3010200@oracle.com> Message-ID: Hi David, For this issue, I think we can approach as following: 1. Export new JVM function to set native thread name It can avoid JNI call and can handle char* value. However this plan has been rejected. 2. Call uncaught exception handler from Launcher We have to clear (process) any pending exception before DetachCurrentThread() call. (not documented?) ------ > so note that we are potentially calling DetachCurrentThread with an > exception pending - which is prohibited by JNI** > **JNI spec needs to be modified here. ------ So we can process pending exception through uncaught exception handler. However, this plan has been rejected. 3. Do not set DestroyJavaVM name when exception is occurred It disrupts consistency for native thread name. 4. Attach to JVM to set native thread name for DestroyJavaVM It does not look good. If all of them are not accepted, I guess that it is difficult. Do you have any other idea? Thanks, Yasumasa On 2016/04/26 18:35, David Holmes wrote: > On 26/04/2016 7:22 PM, Yasumasa Suenaga wrote: >> Hi David, >> >>> I thought about being able to save/restore the original pending >>> exception but could not see a simple way to restore it - ie just by >>> poking it back into the thread's pending exception field. The problem >>> with using env->Throw is that it acts like the initial throwing of the >>> exception and will have a number of side-effects that then get doubled >>> up: >>> - logging statements (UL and Event logging) >>> - OOM counting >> >> Thanks, I understood. >> >>>>> so note that we are potentially calling DetachCurrentThread with an >>>>> exception pending - which is prohibited by JNI**, but which we >>>>> actually rely on for desired operation as DetachCurrentThread calls >>>>> thread->exit() which performs uncaught exception handling (ie it >>>>> prints the exception message and stacktrace) and then clears the >>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>> exceptions.) >> >> I think we can call uncaught exception handler before calling >> DestroyJavaVM(). >> I added it in new webrev for jdk: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/hotspot/ >> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/jdk/ >> >> DispatchUncaughtException() in java.c emulates uncaught exception handler >> call in JavaThread::exit(). >> I think this patch can provide the solution for our issue. >> >> Could you check it? > > Sorry - this is getting far too disruptive. I do not support changing the way the main thread behaves upon completion, just because we want to set a native thread name. > > David > ----- > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/26 14:16, David Holmes wrote: >>> On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: >>>> Hi David, Kumar, >>>> >>>> I think that we should evacuate original exception before DestroyJavaVM >>>> thread name is set. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ >>>> >>>> I added it to LEAVE macro in new webrev. >>> >>> BTW: in the LEAVE macro, stylistically all the code should be in the >>> do { } while(false); loop. I overlooked that initially. >>> >>>> I tested it with following code. It works fine. >>>> >>>> ------------- >>>> public void main(String[] args){ >>>> throw new RuntimeException("test"); >>>> } >>>> ------------- >>>> >>>> What do you think about it? >>> >>> I thought about being able to save/restore the original pending >>> exception but could not see a simple way to restore it - ie just by >>> poking it back into the thread's pending exception field. The problem >>> with using env->Throw is that it acts like the initial throwing of the >>> exception and will have a number of side-effects that then get doubled >>> up: >>> - logging statements (UL and Event logging) >>> - OOM counting >>> >>> I'm not sure whether that is acceptable or not >>> >>> That aside you should check if orig_throwable is non-null before >>> clearing to avoid an unnecessary JNI call. >>> >>> Also "Resume original exception" -> "Restore any original exception" >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/26 11:16, David Holmes wrote: >>>>> Hi Yasumasa, Kumar, >>>>> >>>>> Turns out this change breaks the behaviour of the launcher in the case >>>>> that main() completes by throwing an exception. >>>>> >>>>> What we have in the launcher is: >>>>> >>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>>> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; >>>>> LEAVE(); >>>>> >>>>> where LEAVE would have expanded to: >>>>> >>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>> ret = 1; \ >>>>> } \ >>>>> if (JNI_TRUE) { \ >>>>> (*vm)->DestroyJavaVM(vm); \ >>>>> return ret; \ >>>>> } \ >>>>> >>>>> so note that we are potentially calling DetachCurrentThread with an >>>>> exception pending - which is prohibited by JNI**, but which we >>>>> actually rely on for desired operation as DetachCurrentThread calls >>>>> thread->exit() which performs uncaught exception handling (ie it >>>>> prints the exception message and stacktrace) and then clears the >>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>> exceptions.) >>>>> >>>>> **JNI spec needs to be modified here. >>>>> >>>>> With the current change we have now inserted the following at the >>>>> start of LEAVE: >>>>> >>>>> SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>> if ((*env)->ExceptionOccurred(env)) { \ >>>>> (*env)->ExceptionClear(env); \ >>>>> } \ >>>>> >>>>> this has two unintended consequences: >>>>> >>>>> 1. SetNativeThreadName itself calls a number of JNI methods, with the >>>>> exception pending - which is not permitted. So straight away where we >>>>> have: >>>>> >>>>> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >>>>> >>>>> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make calls >>>>> using the VM's CHECK_NULL macro - which checks for a pending exception >>>>> (which it finds) and returns NULL. So the jli NULL_CHECK macro then >>>>> reports a JNI error: >>>>> >>>>> Error: A JNI error has occurred, please check your installation and >>>>> try again >>>>> >>>>> >>>>> 2. There is no longer an exception from main() for DetachCurrentThread >>>>> to report, so we exit with a return code of 1 as required, but don't >>>>> report the exception message/stacktrace. >>>>> >>>>> I don't see a reasonable solution for this other than abandoning the >>>>> attempt to change the name from "main" to "DestroyJavaVM" - which if >>>>> we can't do, I question the utility of setting the name in the first >>>>> place (while it might be useful in some circumstances [when main() is >>>>> running] it will cause confusion in others [when main() has exited]). >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 25/04/2016 3:47 PM, David Holmes wrote: >>>>>> Looks good to me. >>>>>> >>>>>> I'll sponsor this "tomorrow". >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>>>>>> Hi Kumar, >>>>>>> >>>>>>> Thank you for your comment! >>>>>>> I've fixed them and uploaded new webrev. Could you review again? >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>>>>>> >>>>>>>> Also a couple of minor suggestions: >>>>>>>> >>>>>>>> - * Set native thread name as possible. >>>>>>>> + * Set native thread name if possible. >>>>>>>> >>>>>>>> >>>>>>>> + /* >>>>>>>> - * We can clear pending exception because exception at this >>>>>>>> point >>>>>>>> - * is not critical. >>>>>>>> + */ >>>>>>>> >>>>>>>> + /* >>>>>>>> + * Clear non critical pending exceptions at this point. >>>>>>>> + */ >>>>>>>> >>>>>>>> Thanks >>>>>>>> Kumar >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is in the wrong place: >>>>>>>>> >>>>>>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>> 1716 /* >>>>>>>>> 1717 * We can clear pending exception because exception at >>>>>>>>> this point >>>>>>>>> 1718 * is not critical. >>>>>>>>> 1719 */ >>>>>>>>> 1720 (*env)->ExceptionClear(env); >>>>>>>>> 1721 } >>>>>>>>> >>>>>>>>> This above needs to be after >>>>>>>>> 391 SetNativeThreadName(env, "main"); >>>>>>>>> 392 >>>>>>>>> >>>>>>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>>>>>> but have also encountered an exception. In which case >>>>>>>>> the method SetNativeThreadName will return to the caller, as >>>>>>>>> if nothing has happened, because NULL_CHECK simply checks for NULL >>>>>>>>> and returns to the caller. This will cause the caller to enter >>>>>>>>> the VM with exceptions. >>>>>>>>> >>>>>>>>> Kumar >>>>>>>>> >>>>>>>>> >>>>>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>> ignore >>>>>>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>>>>> >>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I have uploaded webrev.04 as below. >>>>>>>>>>>> Could you review again? >>>>>>>>>>>> >>>>>>>>>>>> > - hotspot: >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Looks fine. >>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> > - jdk: >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>> >>>>>>>>>>> As per private email (but repeated here on the record) in java.c: >>>>>>>>>>> >>>>>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>>>>>> 1717 } >>>>>>>>>>> >>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>> ignore >>>>>>>>>>> it. Either way we have to clear the exception before continuing. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>>>>>> >: >>>>>>>>>>>> > >>>>>>>>>>>> > Hi David, >>>>>>>>>>>> > >>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>> > >>>>>>>>>>>> > - hotspot: >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> > - jdk: >>>>>>>>>>>> > >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>>>>>> process, I >>>>>>>>>>>> would have done it immediately after here: >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > I think that native thread name ("main") should be set just >>>>>>>>>>>> before >>>>>>>>>>>> > main method call. >>>>>>>>>>>> > However, main thread is already started, so I moved it as you >>>>>>>>>>>> suggested. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>>>> have to >>>>>>>>>>>> go from char* to java.lang.String to call setNativeName which >>>>>>>>>>>> then >>>>>>>>>>>> calls >>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>>>>>> char* ! >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > SoI proposed to export new JVM function to set native thread >>>>>>>>>>>> name with >>>>>>>>>>>> > const char *. >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Thanks, >>>>>>>>>>>> > >>>>>>>>>>>> > Yasumasa >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>>>>>> >> >>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>> >> >>>>>>>>>>>> >> Thanks for persevering with this to get it into the current >>>>>>>>>>>> form. >>>>>>>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>>>>>>> >> >>>>>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Hi Gerard, >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>> >>: >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > hi Yasumasa, >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > ======== >>>>>>>>>>>> >>> > File: java.c >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>>>> >>> after every single JNI call? In this example instead of >>>>>>>>>>>> NULL_CHECK, >>>>>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> It is not critical if we encounter error at JNI function >>>>>>>>>>>> call >>>>>>>>>>>> because >>>>>>>>>>>> >>> we cannot set native thread name only. >>>>>>>>>>>> >>> So I think that we do not need to leave from launcher >>>>>>>>>>>> process. >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> I agree we do not need to abort if an exception occurs >>>>>>>>>>>> (and in >>>>>>>>>>>> fact >>>>>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>>>>> but we >>>>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>>>> futher JNI >>>>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>>>> extensively >>>>>>>>>>>> throughout the launcher code - so if this usage is wrong then it >>>>>>>>>>>> is all >>>>>>>>>>>> wrong! More on this code below ... >>>>>>>>>>>> >> >>>>>>>>>>>> >> Other comments: >>>>>>>>>>>> >> >>>>>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>>>>>> >> >>>>>>>>>>>> >> Please add a comment to the method now that you removed the >>>>>>>>>>>> internal >>>>>>>>>>>> comment: >>>>>>>>>>>> >> >>>>>>>>>>>> >> // Sets the native thread name for a JavaThread. If >>>>>>>>>>>> specifically >>>>>>>>>>>> >> // requested JNI-attached threads can also have their native >>>>>>>>>>>> name set; >>>>>>>>>>>> >> // otherwise we do not modify JNI-attached threads as it may >>>>>>>>>>>> interfere >>>>>>>>>>>> >> // with the application that created them. >>>>>>>>>>>> >> >>>>>>>>>>>> >> --- >>>>>>>>>>>> >> >>>>>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>>>>>> >> >>>>>>>>>>>> >> Please add the following comments: >>>>>>>>>>>> >> >>>>>>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>>>>>> >> setNativeName(name, false); >>>>>>>>>>>> >> >>>>>>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>>>>>> permitted) to >>>>>>>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>>>>>>> >> private native void setNativeName(String name, boolean >>>>>>>>>>>> allowAttachedThread); >>>>>>>>>>>> >> >>>>>>>>>>>> >> --- >>>>>>>>>>>> >> >>>>>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>>>>>> >> >>>>>>>>>>>> >> 328 #define LEAVE() \ >>>>>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>> >> >>>>>>>>>>>> >> I was going to suggest this be set later, but realized we >>>>>>>>>>>> have >>>>>>>>>>>> to be >>>>>>>>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>>>>>>>> >> >>>>>>>>>>>> >> + /* Set native thread name. */ >>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>> >> >>>>>>>>>>>> >> The comment is redundant given the name of the method. That >>>>>>>>>>>> aside >>>>>>>>>>>> I'm not sure why you do this so late in the process, I would >>>>>>>>>>>> have >>>>>>>>>>>> done >>>>>>>>>>>> it immediately after here: >>>>>>>>>>>> >> >>>>>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>>>>>> >> 388 exit(1); >>>>>>>>>>>> >> 389 } >>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> + /** >>>>>>>>>>>> >> + * Set native thread name as possible. >>>>>>>>>>>> >> + */ >>>>>>>>>>>> >> >>>>>>>>>>>> >> Other than the as->if change I'm unclear where the >>>>>>>>>>>> "possible" >>>>>>>>>>>> bit >>>>>>>>>>>> comes into play - why would it not be possible? >>>>>>>>>>>> >> >>>>>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>>>>>> "java/lang/Thread")); >>>>>>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>>>>>> cls, >>>>>>>>>>>> >> 1707 "currentThread", >>>>>>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>>>>>> >> 1709 currentThreadID)); >>>>>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = >>>>>>>>>>>> (*env)->GetMethodID(env, >>>>>>>>>>>> cls, >>>>>>>>>>>> >> 1711 "setNativeName", >>>>>>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>>>>>> name)); >>>>>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>>>>>> setNativeNameID, >>>>>>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>>>>>> >> >>>>>>>>>>>> >> As above NULL_CHECK is fine here, but we should check for >>>>>>>>>>>> and >>>>>>>>>>>> clear >>>>>>>>>>>> any pending exception after CallVoidMethod. >>>>>>>>>>>> >> >>>>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>>>> have to >>>>>>>>>>>> go from char* to java.lang.String to call setNativeName which >>>>>>>>>>>> then >>>>>>>>>>>> calls >>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back to a >>>>>>>>>>>> char* ! >>>>>>>>>>>> Overall I wonder about the affect on startup cost. But if there >>>>>>>>>>>> is an >>>>>>>>>>>> issue we can revisit this. >>>>>>>>>>>> >> >>>>>>>>>>>> >> Thanks, >>>>>>>>>>>> >> David >>>>>>>>>>>> >> ----- >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be ?Set >>>>>>>>>>>> native >>>>>>>>>>>> thread >>>>>>>>>>>> >>> name if possible.? not "Set native thread name as >>>>>>>>>>>> possible.?? >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Sorry for my bad English :-) >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>> >>> >>>>>>>>>>>> >>> > cheers >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>>>>>> >>>>>>>>>>>> >>> >> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > Hi David, >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > I uploaded new webrev: >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > - hotspot: >>>>>>>>>>>> >>> > > >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > - jdk: >>>>>>>>>>>> >>> > > >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>>>>>> setName so I'm >>>>>>>>>>>> >>> not sure what you were thinking here. To take advantage >>>>>>>>>>>> of an >>>>>>>>>>>> arg >>>>>>>>>>>> taking >>>>>>>>>>>> >>> JVM_SetNativThreadName you would need to call it >>>>>>>>>>>> directly as >>>>>>>>>>>> no Java >>>>>>>>>>>> >>> code will call it . ??? >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>>>>>> JNI-attached >>>>>>>>>>>> thread. >>>>>>>>>>>> >>> > > This change can set native thread name if main thread >>>>>>>>>>>> changes to >>>>>>>>>>>> >>> JNI-attached thread. >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > Thanks, >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > Yasumasa >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > >>>>>>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>> > >>> Hi David, >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>> could be >>>>>>>>>>>> considered a >>>>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>>>> thread >>>>>>>>>>>> main, even >>>>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>>>> first place. >>>>>>>>>>>> >>> :( Such >>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> I understood. >>>>>>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at >>>>>>>>>>>> Oracle.) >>>>>>>>>>>> >>> > >> >>>>>>>>>>>> >>> > >> Sorry you can't file a CCC request, you would need a >>>>>>>>>>>> sponsor for >>>>>>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>>>>>> proposed change >>>>>>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>>>>>> restore the >>>>>>>>>>>> >>> "broken" behaviour. >>>>>>>>>>>> >>> > >> >>>>>>>>>>>> >>> > >>> I want to continue to discuss about it on >>>>>>>>>>>> JDK-8154331 >>>>>>>>>>>> [1]. >>>>>>>>>>>> >>> > >> >>>>>>>>>>>> >>> > >> Okay we can do that. >>>>>>>>>>>> >>> > >> >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>>> Further, we expect the launcher to use the >>>>>>>>>>>> supported >>>>>>>>>>>> JNI >>>>>>>>>>>> >>> interface (as >>>>>>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>>>>>> interface that >>>>>>>>>>>> >>> exists for >>>>>>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> I think that we do not use JVM interface if we >>>>>>>>>>>> add new >>>>>>>>>>>> method in >>>>>>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>> >>> > >>> --- >>>>>>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>>>>>> >>> > >>> +++ >>>>>>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>>>>>> >>> > >>> else >>>>>>>>>>>> >>> > >>> return md.toNameAndVersion() + " (" >>>>>>>>>>>> + loc >>>>>>>>>>>> + ")"; >>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>> >>> > >>> + static void setNativeThreadName(String name) { >>>>>>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>>>>>> >>> > >>> + } >>>>>>>>>>>> >>> > >> >>>>>>>>>>>> >>> > >> You could also make that call via JNI directly, so >>>>>>>>>>>> not >>>>>>>>>>>> sure the >>>>>>>>>>>> >>> helper adds much here. But it won't work unless you change >>>>>>>>>>>> the >>>>>>>>>>>> semantics >>>>>>>>>>>> >>> of setName so I'm not sure what you were thinking here. To >>>>>>>>>>>> take >>>>>>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you would >>>>>>>>>>>> need to >>>>>>>>>>>> call >>>>>>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>>>>>> >>> > >> >>>>>>>>>>>> >>> > >> David >>>>>>>>>>>> >>> > >> ----- >>>>>>>>>>>> >>> > >> >>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c >>>>>>>>>>>> Wed >>>>>>>>>>>> Apr 13 >>>>>>>>>>>> 14:19:30 >>>>>>>>>>>> >>> > >>> 2016 +0000 >>>>>>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c >>>>>>>>>>>> Sat >>>>>>>>>>>> Apr 16 >>>>>>>>>>>> 11:25:53 >>>>>>>>>>>> >>> > >>> 2016 +0900 >>>>>>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean >>>>>>>>>>>> doXUsage); >>>>>>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char >>>>>>>>>>>> *optString); >>>>>>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char >>>>>>>>>>>> *optString); >>>>>>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>>>>>>>> *name); >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>> >>> > >>> do { \ >>>>>>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != >>>>>>>>>>>> JNI_OK) >>>>>>>>>>>> { \ >>>>>>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, >>>>>>>>>>>> argc); >>>>>>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>>>>>>> mainArgs); >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>>>>>> >>> > >>> joptString); >>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> +/** >>>>>>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>>>>>> >>> > >>> + */ >>>>>>>>>>>> >>> > >>> +static void >>>>>>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>>>>>> >>> > >>> +{ >>>>>>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>>>>>> >>> > >>> + jstring nameString; >>>>>>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>>>>>> >>> > >>> + "setNativeThreadName", "(Ljava/lang/String;)V")); >>>>>>>>>>>> >>> > >>> + NULL_CHECK(nameString = >>>>>>>>>>>> (*env)->NewStringUTF(env, >>>>>>>>>>>> name)); >>>>>>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>>>>>> setNativeThreadNameID, >>>>>>>>>>>> >>> > >>> nameString); >>>>>>>>>>>> >>> > >>> +} >>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>> >>> > >>> /* >>>>>>>>>>>> >>> > >>> * Prints default usage or the Xusage message, see >>>>>>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> So I want to add new arg to >>>>>>>>>>>> JVM_SetNativeThreadName(). >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>>> However this is still a change to the exported JVM >>>>>>>>>>>> interface and so >>>>>>>>>>>> >>> > >>>> has to be approved. >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> Thanks, >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> Yasumasa >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> [1] >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> >>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> >>>>>>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>> > >>>>> Hi David, >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>>>>>> for main >>>>>>>>>>>> >>> thread and >>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>>>>>> >>> > >>>>> I will send review request to hotspot-runtime-dev. >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>> behaviour by >>>>>>>>>>>> itself as >>>>>>>>>>>> >>> setName >>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>>>> thread. >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> I know. >>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>> could be >>>>>>>>>>>> considered a >>>>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>>>> thread >>>>>>>>>>>> main, even >>>>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>>>> first place. >>>>>>>>>>>> >>> :( Such >>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>>>>>> JDK-7098194, >>>>>>>>>>>> and it is >>>>>>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in >>>>>>>>>>>> 7u2. >>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>>>>>>> >>> Thread#setNativeName() >>>>>>>>>>>> >>> > >>>>> only. >>>>>>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private >>>>>>>>>>>> method. >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>>>>>> >>> > >>>>> for force setting. >>>>>>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>>>>>> >>> > >>>>> However, this function is NOT public, so I >>>>>>>>>>>> think we >>>>>>>>>>>> can >>>>>>>>>>>> add one >>>>>>>>>>>> >>> more >>>>>>>>>>>> >>> > >>>>> argument. >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>>>>>>>> from Java >>>>>>>>>>>> >>> launcher. >>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>>>>>>>> really at >>>>>>>>>>>> >>> issue. Yes >>>>>>>>>>>> >>> > >>>> we would add another arg to the JVM function to >>>>>>>>>>>> allow >>>>>>>>>>>> it to >>>>>>>>>>>> apply to >>>>>>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>>>>>>>> reflect that >>>>>>>>>>>> >>> not just >>>>>>>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>>>>>>> exported JVM >>>>>>>>>>>> >>> interface >>>>>>>>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>>>>>>>> launcher to >>>>>>>>>>>> >>> use the >>>>>>>>>>>> >>> > >>>> supported JNI interface (as other processes would), >>>>>>>>>>>> not the >>>>>>>>>>>> internal >>>>>>>>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>>>>>>>> communicate >>>>>>>>>>>> >>> with the >>>>>>>>>>>> >>> > >>>> JVM. >>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>> >>> > >>>> David >>>>>>>>>>>> >>> > >>>> ----- >>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> Thanks, >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not >>>>>>>>>>>> tagged as >>>>>>>>>>>> being a >>>>>>>>>>>> >>> JNI-attached >>>>>>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = false); // >>>>>>>>>>>> for main >>>>>>>>>>>> >>> thread and >>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>> behaviour by >>>>>>>>>>>> itself as >>>>>>>>>>>> >>> setName >>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>>>> thread. >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 >>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>> Apr 14 >>>>>>>>>>>> 13:31:11 >>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri >>>>>>>>>>>> Apr 15 >>>>>>>>>>>> 17:50:10 >>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new >>>>>>>>>>>> JavaThread(true); >>>>>>>>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM initialization >>>>>>>>>>>> is complete >>>>>>>>>>>> >>> - nop if >>>>>>>>>>>> >>> > >>>>>>> no agents. >>>>>>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>>>> >>> > >>>>>>> + >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> I think we can do this straight after the >>>>>>>>>>>> JavaThread >>>>>>>>>>>> constructor. >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>>>>>>>> tracing >>>>>>>>>>>> >>> > >>>>>>> backend."); >>>>>>>>>>>> >>> > >>>>>>> } >>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> If it wants to name its native threads then >>>>>>>>>>>> it is >>>>>>>>>>>> free >>>>>>>>>>>> to do so, >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot >>>>>>>>>>>> change >>>>>>>>>>>> native >>>>>>>>>>>> >>> thread name >>>>>>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>>>>> >>> > >>>>>>> However, I think that it should be changed if >>>>>>>>>>>> Java >>>>>>>>>>>> developer >>>>>>>>>>>> >>> calls >>>>>>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>>>>>> >>> > >>>>>>> It is not the same of changing native thread >>>>>>>>>>>> name at >>>>>>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>>>>>> SetNativeThreadName() as >>>>>>>>>>>> below. >>>>>>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> The decision to not change the name of >>>>>>>>>>>> JNI-attached >>>>>>>>>>>> threads was a >>>>>>>>>>>> >>> > >>>>>> deliberate one** - this functionality originated >>>>>>>>>>>> with the OSX >>>>>>>>>>>> >>> port and >>>>>>>>>>>> >>> > >>>>>> it was reported that the initial feedback with >>>>>>>>>>>> this >>>>>>>>>>>> feature was to >>>>>>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that had >>>>>>>>>>>> been set by >>>>>>>>>>>> >>> the host >>>>>>>>>>>> >>> > >>>>>> process. If we do as you propose then we will >>>>>>>>>>>> just >>>>>>>>>>>> have an >>>>>>>>>>>> >>> > >>>>>> inconsistency for people to complain about: "why >>>>>>>>>>>> does my >>>>>>>>>>>> >>> native thread >>>>>>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> ** If you follow the bugs and related >>>>>>>>>>>> discussions on >>>>>>>>>>>> this, the >>>>>>>>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>>>>>>>> thread only, >>>>>>>>>>>> >>> non-JNI >>>>>>>>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>>>>>>>> were supposed >>>>>>>>>>>> >>> to be >>>>>>>>>>>> >>> > >>>>>> documented in the release notes - but as far as I >>>>>>>>>>>> can see >>>>>>>>>>>> that >>>>>>>>>>>> >>> never >>>>>>>>>>>> >>> > >>>>>> happened. :( >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> My position on this remains that if it is >>>>>>>>>>>> desirable >>>>>>>>>>>> for >>>>>>>>>>>> the main >>>>>>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have native >>>>>>>>>>>> names >>>>>>>>>>>> then the >>>>>>>>>>>> >>> > >>>>>> launcher needs to be setting them using the >>>>>>>>>>>> available >>>>>>>>>>>> platform >>>>>>>>>>>> >>> APIs. >>>>>>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as >>>>>>>>>>>> evidenced by >>>>>>>>>>>> the VM >>>>>>>>>>>> >>> code for >>>>>>>>>>>> >>> > >>>>>> this - due to the need to verify API >>>>>>>>>>>> availability. >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>>>>>> Thread.setName would >>>>>>>>>>>> >>> have to go >>>>>>>>>>>> >>> > >>>>>> through our CCC process I think. But a change in >>>>>>>>>>>> the launcher >>>>>>>>>>>> >>> would >>>>>>>>>>>> >>> > >>>>>> not. >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> Sorry. >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>> David >>>>>>>>>>>> >>> > >>>>>> ----- >>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu >>>>>>>>>>>> Apr 14 >>>>>>>>>>>> 13:31:11 >>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri >>>>>>>>>>>> Apr 15 >>>>>>>>>>>> 17:50:10 >>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>>>>>> >>> > >>>>>>> // Thread naming only supported for the >>>>>>>>>>>> current >>>>>>>>>>>> thread, >>>>>>>>>>>> >>> doesn't >>>>>>>>>>>> >>> > >>>>>>> work >>>>>>>>>>>> >>> > >>>>>>> for >>>>>>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>>>>>>> thread to avoid >>>>>>>>>>>> >>> stepping >>>>>>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>> David, >>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>> this. I >>>>>>>>>>>> don't like >>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>>>>>> initializing VM >>>>>>>>>>>> (before >>>>>>>>>>>> >>> > >>>>>>>>> calling >>>>>>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>>>>>> AttachCurrentThread(). >>>>>>>>>>>> So we >>>>>>>>>>>> >>> can't >>>>>>>>>>>> >>> > >>>>>>>>> set >>>>>>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> Right - I came to the same realization earlier >>>>>>>>>>>> this >>>>>>>>>>>> morning. >>>>>>>>>>>> >>> Which, >>>>>>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic >>>>>>>>>>>> premise >>>>>>>>>>>> here that >>>>>>>>>>>> >>> we don't >>>>>>>>>>>> >>> > >>>>>>>> set the name of threads not created by the JVM. >>>>>>>>>>>> The fact >>>>>>>>>>>> >>> that the >>>>>>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a >>>>>>>>>>>> JNI-attached >>>>>>>>>>>> thread seems >>>>>>>>>>>> >>> > >>>>>>>> accidental to me - so >>>>>>>>>>>> JVM_SetNativeThreadName is >>>>>>>>>>>> only >>>>>>>>>>>> working by >>>>>>>>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>>>>>>>> used for the >>>>>>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>>>>>>>> inconsistently >>>>>>>>>>>> >>> named at >>>>>>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher >>>>>>>>>>>> has >>>>>>>>>>>> to be >>>>>>>>>>>> >>> treated like >>>>>>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. If it >>>>>>>>>>>> wants to >>>>>>>>>>>> name its >>>>>>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, but I >>>>>>>>>>>> would not be >>>>>>>>>>>> >>> exporting >>>>>>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>>>>>>>> have to >>>>>>>>>>>> use the OS >>>>>>>>>>>> >>> > >>>>>>>> specific API's for that on a >>>>>>>>>>>> platform-by-platform >>>>>>>>>>>> basis. >>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> David >>>>>>>>>>>> >>> > >>>>>>>> ----- >>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar >>>>>>>>>>>> but >>>>>>>>>>>> perform >>>>>>>>>>>> >>> different >>>>>>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>>>>>> JVM_SetNativeThreadName >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the current >>>>>>>>>>>> thread, the >>>>>>>>>>>> >>> second >>>>>>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a >>>>>>>>>>>> comment >>>>>>>>>>>> somewhere >>>>>>>>>>>> >>> about >>>>>>>>>>>> >>> > >>>>>>>>>> what >>>>>>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>>>>>>> casts to >>>>>>>>>>>> (void*) >>>>>>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>> >>> used at >>>>>>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible >>>>>>>>>>>> keep >>>>>>>>>>>> the cast >>>>>>>>>>>> >>> on the >>>>>>>>>>>> >>> > >>>>>>>>>> same >>>>>>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>>> haven't had >>>>>>>>>>>> time to >>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>>>> JNI-attached >>>>>>>>>>>> >>> thread >>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>> then my >>>>>>>>>>>> suggestion >>>>>>>>>>>> >>> should >>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>> in our >>>>>>>>>>>> treatment of >>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, >>>>>>>>>>>> and I >>>>>>>>>>>> confirmed >>>>>>>>>>>> >>> native >>>>>>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) >>>>>>>>>>>> throws >>>>>>>>>>>> Exception{ >>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>> this. I >>>>>>>>>>>> don't like >>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>>>>>>>> comment. >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set >>>>>>>>>>>> native >>>>>>>>>>>> thread >>>>>>>>>>>> >>> name, and JLI >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another >>>>>>>>>>>> team so >>>>>>>>>>>> >>> core-libs will >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>>>>>>>> Kumar) - >>>>>>>>>>>> now cc'd. >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java >>>>>>>>>>>> upcall to >>>>>>>>>>>> >>> Thread.setName >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> than exporting >>>>>>>>>>>> JVM_SetNativeThreadName. No >>>>>>>>>>>> hotspot changes >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>>>>>>> Thread#setName() in >>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread name. >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not >>>>>>>>>>>> alive, >>>>>>>>>>>> which is >>>>>>>>>>>> >>> why the >>>>>>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>>>>>> attached thread. >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>>> haven't had >>>>>>>>>>>> time to >>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>>>> JNI-attached >>>>>>>>>>>> >>> thread >>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>> then my >>>>>>>>>>>> suggestion >>>>>>>>>>>> >>> should >>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>> in our >>>>>>>>>>>> treatment of >>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>> this. I >>>>>>>>>>>> don't like >>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>>>>>>> function to set >>>>>>>>>>>> >>> native >>>>>>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original thread as >>>>>>>>>>>> well ... >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug (sorry >>>>>>>>>>>> have >>>>>>>>>>>> been on >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher to be >>>>>>>>>>>> correct >>>>>>>>>>>> as we >>>>>>>>>>>> >>> do not >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, >>>>>>>>>>>> which >>>>>>>>>>>> includes the >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa Suenaga >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more >>>>>>>>>>>> reviewer >>>>>>>>>>>> :-) >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>> >>: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>>>>>>>> Suenaga >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>> >>> >>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>> >>>: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>> >>>>: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you don't >>>>>>>>>>>> set it: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* >>>>>>>>>>>> main_thread = >>>>>>>>>>>> new >>>>>>>>>>>> >>> JavaThread(); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>>>> >>> set_active_handles >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I missing >>>>>>>>>>>> something? >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the same >>>>>>>>>>>> to thread >>>>>>>>>>>> >>> name in >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in >>>>>>>>>>>> Thread or >>>>>>>>>>>> setName(). >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in >>>>>>>>>>>> Java >>>>>>>>>>>> app, >>>>>>>>>>>> native >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main >>>>>>>>>>>> thread is >>>>>>>>>>>> already >>>>>>>>>>>> >>> starte >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is >>>>>>>>>>>> set in >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of >>>>>>>>>>>> setting >>>>>>>>>>>> thrrad name >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But then >>>>>>>>>>>> something like >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>>>>>> Tue >>>>>>>>>>>> >>> Mar 29 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>>>>>> Wed >>>>>>>>>>>> >>> Mar 30 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial Thread >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>>>>>> create_initial_thread(Handle >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>>>>>> initial_thread_name = >>>>>>>>>>>> >>> "main"; >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> >>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>>>>>>>> (THREAD, k); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle thread_oop = >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>> >>> thread); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>> thread_oop, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev >>>>>>>>>>>> later. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>>>>>>>> itself >>>>>>>>>>>> 'java' and >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to me. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of the >>>>>>>>>>>> process >>>>>>>>>>>> (and >>>>>>>>>>>> >>> thus >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is 'main'. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in the >>>>>>>>>>>> process >>>>>>>>>>>> is not >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main thread >>>>>>>>>>>> with >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is >>>>>>>>>>>> for >>>>>>>>>>>> >>> JavaThread. So I >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native >>>>>>>>>>>> main >>>>>>>>>>>> thread. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>>>>>>>> anyhow, since >>>>>>>>>>>> >>> we want >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java >>>>>>>>>>>> thread >>>>>>>>>>>> name >>>>>>>>>>>> might >>>>>>>>>>>> >>> have >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. >>>>>>>>>>>> /proc. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid >>>>>>>>>>>> comm' >>>>>>>>>>>> | head -4 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with something >>>>>>>>>>>> like >>>>>>>>>>>> 'Java Main >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not be a >>>>>>>>>>>> Java >>>>>>>>>>>> >>> launcher - e.g. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI application, >>>>>>>>>>>> etc. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native main >>>>>>>>>>>> thread >>>>>>>>>>>> name, >>>>>>>>>>>> >>> I think >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new >>>>>>>>>>>> webrev? >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>> Suenaga wrote: >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will >>>>>>>>>>>> set >>>>>>>>>>>> thread >>>>>>>>>>>> >>> name via >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread >>>>>>>>>>>> does not >>>>>>>>>>>> have it. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have >>>>>>>>>>>> native >>>>>>>>>>>> name, >>>>>>>>>>>> and main >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main >>>>>>>>>>>> thread >>>>>>>>>>>> should have >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. >>>>>>>>>>>> Could >>>>>>>>>>>> you >>>>>>>>>>>> review it? >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>> >>> > >>>>>>>>>>>> >>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>> From david.holmes at oracle.com Tue Apr 26 13:08:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Apr 2016 23:08:27 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: References: <56F3F90D.9010408@gmail.com> <570FA803.1010105@Oracle.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> <571EF995.3000109@oracle.com> <571F367B.3010200@oracle.com> Message-ID: <571F684B.9080501@oracle.com> On 26/04/2016 10:54 PM, Yasumasa Suenaga wrote: > Hi David, > > For this issue, I think we can approach as following: > > > 1. Export new JVM function to set native thread name > It can avoid JNI call and can handle char* value. > However this plan has been rejected. > > 2. Call uncaught exception handler from Launcher > We have to clear (process) any pending exception before > DetachCurrentThread() call. (not documented?) > ------ >> so note that we are potentially calling DetachCurrentThread with an >> exception pending - which is prohibited by JNI** > >> **JNI spec needs to be modified here. > ------ > So we can process pending exception through uncaught > exception handler. > However, this plan has been rejected. > > 3. Do not set DestroyJavaVM name when exception is occurred > It disrupts consistency for native thread name. > > 4. Attach to JVM to set native thread name for DestroyJavaVM > It does not look good. > > > If all of them are not accepted, I guess that it is difficult. > Do you have any other idea? Sorry I don't. The basic idea of having the launcher set the native thread name is fine, but the mechanism to do that has been problematic. The "real" solution (ie one that other applications hosting the jvm would need to use) is for the launcher to duplicate the per-platform logic for os::set_native_thread_name - but that was undesirable. Instead we have tried to avoid that by finding a way to use whatever is already in the JVM - but adding a new JVM interface to expose it directly is not ideal; and hooking into the java.lang.Thread code to avoid that has run into these other problems. I really don't want to take the logic for uncaught exception handling that is in Thread::exit and duplicate it in the launcher. The effort and disruption here really does not justify the "it would be nice to set the native thread name for the main thread" objective. I never expected this to be as problematic as it has turned out. Sorry. David ----- > > Thanks, > > Yasumasa > > > On 2016/04/26 18:35, David Holmes wrote: >> On 26/04/2016 7:22 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> I thought about being able to save/restore the original pending >>>> exception but could not see a simple way to restore it - ie just by >>>> poking it back into the thread's pending exception field. The problem >>>> with using env->Throw is that it acts like the initial throwing of the >>>> exception and will have a number of side-effects that then get doubled >>>> up: >>>> - logging statements (UL and Event logging) >>>> - OOM counting >>> >>> Thanks, I understood. >>> >>>>>> so note that we are potentially calling DetachCurrentThread with an >>>>>> exception pending - which is prohibited by JNI**, but which we >>>>>> actually rely on for desired operation as DetachCurrentThread calls >>>>>> thread->exit() which performs uncaught exception handling (ie it >>>>>> prints the exception message and stacktrace) and then clears the >>>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>>> exceptions.) >>> >>> I think we can call uncaught exception handler before calling >>> DestroyJavaVM(). >>> I added it in new webrev for jdk: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/hotspot/ >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/jdk/ >>> >>> DispatchUncaughtException() in java.c emulates uncaught exception >>> handler >>> call in JavaThread::exit(). >>> I think this patch can provide the solution for our issue. >>> >>> Could you check it? >> >> Sorry - this is getting far too disruptive. I do not support changing >> the way the main thread behaves upon completion, just because we want >> to set a native thread name. >> >> David >> ----- >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/26 14:16, David Holmes wrote: >>>> On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: >>>>> Hi David, Kumar, >>>>> >>>>> I think that we should evacuate original exception before >>>>> DestroyJavaVM >>>>> thread name is set. >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ >>>>> >>>>> I added it to LEAVE macro in new webrev. >>>> >>>> BTW: in the LEAVE macro, stylistically all the code should be in the >>>> do { } while(false); loop. I overlooked that initially. >>>> >>>>> I tested it with following code. It works fine. >>>>> >>>>> ------------- >>>>> public void main(String[] args){ >>>>> throw new RuntimeException("test"); >>>>> } >>>>> ------------- >>>>> >>>>> What do you think about it? >>>> >>>> I thought about being able to save/restore the original pending >>>> exception but could not see a simple way to restore it - ie just by >>>> poking it back into the thread's pending exception field. The problem >>>> with using env->Throw is that it acts like the initial throwing of the >>>> exception and will have a number of side-effects that then get doubled >>>> up: >>>> - logging statements (UL and Event logging) >>>> - OOM counting >>>> >>>> I'm not sure whether that is acceptable or not >>>> >>>> That aside you should check if orig_throwable is non-null before >>>> clearing to avoid an unnecessary JNI call. >>>> >>>> Also "Resume original exception" -> "Restore any original exception" >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/26 11:16, David Holmes wrote: >>>>>> Hi Yasumasa, Kumar, >>>>>> >>>>>> Turns out this change breaks the behaviour of the launcher in the >>>>>> case >>>>>> that main() completes by throwing an exception. >>>>>> >>>>>> What we have in the launcher is: >>>>>> >>>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>>>> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; >>>>>> LEAVE(); >>>>>> >>>>>> where LEAVE would have expanded to: >>>>>> >>>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>> ret = 1; \ >>>>>> } \ >>>>>> if (JNI_TRUE) { \ >>>>>> (*vm)->DestroyJavaVM(vm); \ >>>>>> return ret; \ >>>>>> } \ >>>>>> >>>>>> so note that we are potentially calling DetachCurrentThread with an >>>>>> exception pending - which is prohibited by JNI**, but which we >>>>>> actually rely on for desired operation as DetachCurrentThread calls >>>>>> thread->exit() which performs uncaught exception handling (ie it >>>>>> prints the exception message and stacktrace) and then clears the >>>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>>> exceptions.) >>>>>> >>>>>> **JNI spec needs to be modified here. >>>>>> >>>>>> With the current change we have now inserted the following at the >>>>>> start of LEAVE: >>>>>> >>>>>> SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>> if ((*env)->ExceptionOccurred(env)) { \ >>>>>> (*env)->ExceptionClear(env); \ >>>>>> } \ >>>>>> >>>>>> this has two unintended consequences: >>>>>> >>>>>> 1. SetNativeThreadName itself calls a number of JNI methods, with the >>>>>> exception pending - which is not permitted. So straight away where we >>>>>> have: >>>>>> >>>>>> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >>>>>> >>>>>> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make >>>>>> calls >>>>>> using the VM's CHECK_NULL macro - which checks for a pending >>>>>> exception >>>>>> (which it finds) and returns NULL. So the jli NULL_CHECK macro then >>>>>> reports a JNI error: >>>>>> >>>>>> Error: A JNI error has occurred, please check your installation and >>>>>> try again >>>>>> >>>>>> >>>>>> 2. There is no longer an exception from main() for >>>>>> DetachCurrentThread >>>>>> to report, so we exit with a return code of 1 as required, but don't >>>>>> report the exception message/stacktrace. >>>>>> >>>>>> I don't see a reasonable solution for this other than abandoning the >>>>>> attempt to change the name from "main" to "DestroyJavaVM" - which if >>>>>> we can't do, I question the utility of setting the name in the first >>>>>> place (while it might be useful in some circumstances [when main() is >>>>>> running] it will cause confusion in others [when main() has exited]). >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 25/04/2016 3:47 PM, David Holmes wrote: >>>>>>> Looks good to me. >>>>>>> >>>>>>> I'll sponsor this "tomorrow". >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi Kumar, >>>>>>>> >>>>>>>> Thank you for your comment! >>>>>>>> I've fixed them and uploaded new webrev. Could you review again? >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>>>>>>> >>>>>>>>> Also a couple of minor suggestions: >>>>>>>>> >>>>>>>>> - * Set native thread name as possible. >>>>>>>>> + * Set native thread name if possible. >>>>>>>>> >>>>>>>>> >>>>>>>>> + /* >>>>>>>>> - * We can clear pending exception because exception at this >>>>>>>>> point >>>>>>>>> - * is not critical. >>>>>>>>> + */ >>>>>>>>> >>>>>>>>> + /* >>>>>>>>> + * Clear non critical pending exceptions at this point. >>>>>>>>> + */ >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Kumar >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> This is in the wrong place: >>>>>>>>>> >>>>>>>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>> 1716 /* >>>>>>>>>> 1717 * We can clear pending exception because exception at >>>>>>>>>> this point >>>>>>>>>> 1718 * is not critical. >>>>>>>>>> 1719 */ >>>>>>>>>> 1720 (*env)->ExceptionClear(env); >>>>>>>>>> 1721 } >>>>>>>>>> >>>>>>>>>> This above needs to be after >>>>>>>>>> 391 SetNativeThreadName(env, "main"); >>>>>>>>>> 392 >>>>>>>>>> >>>>>>>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>>>>>>> but have also encountered an exception. In which case >>>>>>>>>> the method SetNativeThreadName will return to the caller, as >>>>>>>>>> if nothing has happened, because NULL_CHECK simply checks for >>>>>>>>>> NULL >>>>>>>>>> and returns to the caller. This will cause the caller to enter >>>>>>>>>> the VM with exceptions. >>>>>>>>>> >>>>>>>>>> Kumar >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>>> ignore >>>>>>>>>>>> it. Either way we have to clear the exception before >>>>>>>>>>>> continuing. >>>>>>>>>>> >>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> I have uploaded webrev.04 as below. >>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>> >>>>>>>>>>>>> > - hotspot: >>>>>>>>>>>>> > >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Looks fine. >>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> > - jdk: >>>>>>>>>>>>> > >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As per private email (but repeated here on the record) in >>>>>>>>>>>> java.c: >>>>>>>>>>>> >>>>>>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>>>>>>> 1717 } >>>>>>>>>>>> >>>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>>> ignore >>>>>>>>>>>> it. Either way we have to clear the exception before >>>>>>>>>>>> continuing. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>>>>>>> >: >>>>>>>>>>>>> > >>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>> > >>>>>>>>>>>>> > - hotspot: >>>>>>>>>>>>> > >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> > - jdk: >>>>>>>>>>>>> > >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>>>>>>> process, I >>>>>>>>>>>>> would have done it immediately after here: >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > I think that native thread name ("main") should be set just >>>>>>>>>>>>> before >>>>>>>>>>>>> > main method call. >>>>>>>>>>>>> > However, main thread is already started, so I moved it >>>>>>>>>>>>> as you >>>>>>>>>>>>> suggested. >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>>>>> have to >>>>>>>>>>>>> go from char* to java.lang.String to call setNativeName which >>>>>>>>>>>>> then >>>>>>>>>>>>> calls >>>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back >>>>>>>>>>>>> to a >>>>>>>>>>>>> char* ! >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > SoI proposed to export new JVM function to set native >>>>>>>>>>>>> thread >>>>>>>>>>>>> name with >>>>>>>>>>>>> > const char *. >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>> > >>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Thanks for persevering with this to get it into the >>>>>>>>>>>>> current >>>>>>>>>>>>> form. >>>>>>>>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Hi Gerard, >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > hi Yasumasa, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > ======== >>>>>>>>>>>>> >>> > File: java.c >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>>>>> >>> after every single JNI call? In this example instead of >>>>>>>>>>>>> NULL_CHECK, >>>>>>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> It is not critical if we encounter error at JNI function >>>>>>>>>>>>> call >>>>>>>>>>>>> because >>>>>>>>>>>>> >>> we cannot set native thread name only. >>>>>>>>>>>>> >>> So I think that we do not need to leave from launcher >>>>>>>>>>>>> process. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> I agree we do not need to abort if an exception occurs >>>>>>>>>>>>> (and in >>>>>>>>>>>>> fact >>>>>>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>>>>>> but we >>>>>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>>>>> futher JNI >>>>>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>>>>> extensively >>>>>>>>>>>>> throughout the launcher code - so if this usage is wrong >>>>>>>>>>>>> then it >>>>>>>>>>>>> is all >>>>>>>>>>>>> wrong! More on this code below ... >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Other comments: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Please add a comment to the method now that you removed >>>>>>>>>>>>> the >>>>>>>>>>>>> internal >>>>>>>>>>>>> comment: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> // Sets the native thread name for a JavaThread. If >>>>>>>>>>>>> specifically >>>>>>>>>>>>> >> // requested JNI-attached threads can also have their >>>>>>>>>>>>> native >>>>>>>>>>>>> name set; >>>>>>>>>>>>> >> // otherwise we do not modify JNI-attached threads as >>>>>>>>>>>>> it may >>>>>>>>>>>>> interfere >>>>>>>>>>>>> >> // with the application that created them. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> --- >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Please add the following comments: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>>>>>>> >> setNativeName(name, false); >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>>>>>>> permitted) to >>>>>>>>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>>>>>>>> >> private native void setNativeName(String name, boolean >>>>>>>>>>>>> allowAttachedThread); >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> --- >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> 328 #define LEAVE() \ >>>>>>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> I was going to suggest this be set later, but realized we >>>>>>>>>>>>> have >>>>>>>>>>>>> to be >>>>>>>>>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> + /* Set native thread name. */ >>>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> The comment is redundant given the name of the method. >>>>>>>>>>>>> That >>>>>>>>>>>>> aside >>>>>>>>>>>>> I'm not sure why you do this so late in the process, I would >>>>>>>>>>>>> have >>>>>>>>>>>>> done >>>>>>>>>>>>> it immediately after here: >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>>>>>>> >> 388 exit(1); >>>>>>>>>>>>> >> 389 } >>>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> + /** >>>>>>>>>>>>> >> + * Set native thread name as possible. >>>>>>>>>>>>> >> + */ >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Other than the as->if change I'm unclear where the >>>>>>>>>>>>> "possible" >>>>>>>>>>>>> bit >>>>>>>>>>>>> comes into play - why would it not be possible? >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>>>>>>> "java/lang/Thread")); >>>>>>>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>>>>>>> cls, >>>>>>>>>>>>> >> 1707 "currentThread", >>>>>>>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>>>>>>> >> 1709 currentThreadID)); >>>>>>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = >>>>>>>>>>>>> (*env)->GetMethodID(env, >>>>>>>>>>>>> cls, >>>>>>>>>>>>> >> 1711 "setNativeName", >>>>>>>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>>>>>>> name)); >>>>>>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>>>>>>> setNativeNameID, >>>>>>>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> As above NULL_CHECK is fine here, but we should check for >>>>>>>>>>>>> and >>>>>>>>>>>>> clear >>>>>>>>>>>>> any pending exception after CallVoidMethod. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>>>>> have to >>>>>>>>>>>>> go from char* to java.lang.String to call setNativeName which >>>>>>>>>>>>> then >>>>>>>>>>>>> calls >>>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back >>>>>>>>>>>>> to a >>>>>>>>>>>>> char* ! >>>>>>>>>>>>> Overall I wonder about the affect on startup cost. But if >>>>>>>>>>>>> there >>>>>>>>>>>>> is an >>>>>>>>>>>>> issue we can revisit this. >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>> >> David >>>>>>>>>>>>> >> ----- >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be >>>>>>>>>>>>> ?Set >>>>>>>>>>>>> native >>>>>>>>>>>>> thread >>>>>>>>>>>>> >>> name if possible.? not "Set native thread name as >>>>>>>>>>>>> possible.?? >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Sorry for my bad English :-) >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>> > cheers >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>>>>>>> >>>>>>>>>>>>> >>> >> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > Hi David, >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > I uploaded new webrev: >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > - hotspot: >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > - jdk: >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>>>>>>> setName so I'm >>>>>>>>>>>>> >>> not sure what you were thinking here. To take advantage >>>>>>>>>>>>> of an >>>>>>>>>>>>> arg >>>>>>>>>>>>> taking >>>>>>>>>>>>> >>> JVM_SetNativThreadName you would need to call it >>>>>>>>>>>>> directly as >>>>>>>>>>>>> no Java >>>>>>>>>>>>> >>> code will call it . ??? >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>> thread. >>>>>>>>>>>>> >>> > > This change can set native thread name if main >>>>>>>>>>>>> thread >>>>>>>>>>>>> changes to >>>>>>>>>>>>> >>> JNI-attached thread. >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > Thanks, >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > Yasumasa >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > >>>>>>>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>> > >>> Hi David, >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>>> could be >>>>>>>>>>>>> considered a >>>>>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>>>>> thread >>>>>>>>>>>>> main, even >>>>>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>>>>> first place. >>>>>>>>>>>>> >>> :( Such >>>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> I understood. >>>>>>>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at >>>>>>>>>>>>> Oracle.) >>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>> >>> > >> Sorry you can't file a CCC request, you would >>>>>>>>>>>>> need a >>>>>>>>>>>>> sponsor for >>>>>>>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>>>>>>> proposed change >>>>>>>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>>>>>>> restore the >>>>>>>>>>>>> >>> "broken" behaviour. >>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>> >>> > >>> I want to continue to discuss about it on >>>>>>>>>>>>> JDK-8154331 >>>>>>>>>>>>> [1]. >>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>> >>> > >> Okay we can do that. >>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>>> Further, we expect the launcher to use the >>>>>>>>>>>>> supported >>>>>>>>>>>>> JNI >>>>>>>>>>>>> >>> interface (as >>>>>>>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>>>>>>> interface that >>>>>>>>>>>>> >>> exists for >>>>>>>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> I think that we do not use JVM interface if we >>>>>>>>>>>>> add new >>>>>>>>>>>>> method in >>>>>>>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>> >>> > >>> --- >>>>>>>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>>>>>>> >>> > >>> +++ >>>>>>>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>>>>>>> >>> > >>> else >>>>>>>>>>>>> >>> > >>> return md.toNameAndVersion() + " (" >>>>>>>>>>>>> + loc >>>>>>>>>>>>> + ")"; >>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>> >>> > >>> + static void setNativeThreadName(String >>>>>>>>>>>>> name) { >>>>>>>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>>>>>>> >>> > >>> + } >>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>> >>> > >> You could also make that call via JNI directly, so >>>>>>>>>>>>> not >>>>>>>>>>>>> sure the >>>>>>>>>>>>> >>> helper adds much here. But it won't work unless you >>>>>>>>>>>>> change >>>>>>>>>>>>> the >>>>>>>>>>>>> semantics >>>>>>>>>>>>> >>> of setName so I'm not sure what you were thinking >>>>>>>>>>>>> here. To >>>>>>>>>>>>> take >>>>>>>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you >>>>>>>>>>>>> would >>>>>>>>>>>>> need to >>>>>>>>>>>>> call >>>>>>>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>> >>> > >> David >>>>>>>>>>>>> >>> > >> ----- >>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>> Wed >>>>>>>>>>>>> Apr 13 >>>>>>>>>>>>> 14:19:30 >>>>>>>>>>>>> >>> > >>> 2016 +0000 >>>>>>>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>> Sat >>>>>>>>>>>>> Apr 16 >>>>>>>>>>>>> 11:25:53 >>>>>>>>>>>>> >>> > >>> 2016 +0900 >>>>>>>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean >>>>>>>>>>>>> doXUsage); >>>>>>>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char >>>>>>>>>>>>> *optString); >>>>>>>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char >>>>>>>>>>>>> *optString); >>>>>>>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>>>>>>>>> *name); >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>>> >>> > >>> do { \ >>>>>>>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != >>>>>>>>>>>>> JNI_OK) >>>>>>>>>>>>> { \ >>>>>>>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, >>>>>>>>>>>>> argc); >>>>>>>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, >>>>>>>>>>>>> mainID, >>>>>>>>>>>>> mainArgs); >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>>>>>>> >>> > >>> joptString); >>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> +/** >>>>>>>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>>>>>>> >>> > >>> + */ >>>>>>>>>>>>> >>> > >>> +static void >>>>>>>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>>>>>>> >>> > >>> +{ >>>>>>>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>>>>>>> >>> > >>> + jstring nameString; >>>>>>>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>>>>>>> >>> > >>> + "setNativeThreadName", >>>>>>>>>>>>> "(Ljava/lang/String;)V")); >>>>>>>>>>>>> >>> > >>> + NULL_CHECK(nameString = >>>>>>>>>>>>> (*env)->NewStringUTF(env, >>>>>>>>>>>>> name)); >>>>>>>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>>>>>>> setNativeThreadNameID, >>>>>>>>>>>>> >>> > >>> nameString); >>>>>>>>>>>>> >>> > >>> +} >>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>> >>> > >>> /* >>>>>>>>>>>>> >>> > >>> * Prints default usage or the Xusage message, >>>>>>>>>>>>> see >>>>>>>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> So I want to add new arg to >>>>>>>>>>>>> JVM_SetNativeThreadName(). >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>>> However this is still a change to the exported >>>>>>>>>>>>> JVM >>>>>>>>>>>>> interface and so >>>>>>>>>>>>> >>> > >>>> has to be approved. >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> Thanks, >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> Yasumasa >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> [1] >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>> > >>>>> Hi David, >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = >>>>>>>>>>>>> false); // >>>>>>>>>>>>> for main >>>>>>>>>>>>> >>> thread and >>>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>>>>>>> >>> > >>>>> I will send review request to >>>>>>>>>>>>> hotspot-runtime-dev. >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>>> behaviour by >>>>>>>>>>>>> itself as >>>>>>>>>>>>> >>> setName >>>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>>>>> thread. >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> I know. >>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>>> could be >>>>>>>>>>>>> considered a >>>>>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>>>>> thread >>>>>>>>>>>>> main, even >>>>>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>>>>> first place. >>>>>>>>>>>>> >>> :( Such >>>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>>>>>>> JDK-7098194, >>>>>>>>>>>>> and it is >>>>>>>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in >>>>>>>>>>>>> 7u2. >>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>>>>>>>> >>> Thread#setNativeName() >>>>>>>>>>>>> >>> > >>>>> only. >>>>>>>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private >>>>>>>>>>>>> method. >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>>>>>>> >>> > >>>>> for force setting. >>>>>>>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>>>>>>> >>> > >>>>> However, this function is NOT public, so I >>>>>>>>>>>>> think we >>>>>>>>>>>>> can >>>>>>>>>>>>> add one >>>>>>>>>>>>> >>> more >>>>>>>>>>>>> >>> > >>>>> argument. >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>>>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>>>>>>>>> from Java >>>>>>>>>>>>> >>> launcher. >>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>>>>>>>>> really at >>>>>>>>>>>>> >>> issue. Yes >>>>>>>>>>>>> >>> > >>>> we would add another arg to the JVM function to >>>>>>>>>>>>> allow >>>>>>>>>>>>> it to >>>>>>>>>>>>> apply to >>>>>>>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>>>>>>>>> reflect that >>>>>>>>>>>>> >>> not just >>>>>>>>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>>>>>>>> exported JVM >>>>>>>>>>>>> >>> interface >>>>>>>>>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>>>>>>>>> launcher to >>>>>>>>>>>>> >>> use the >>>>>>>>>>>>> >>> > >>>> supported JNI interface (as other processes >>>>>>>>>>>>> would), >>>>>>>>>>>>> not the >>>>>>>>>>>>> internal >>>>>>>>>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>>>>>>>>> communicate >>>>>>>>>>>>> >>> with the >>>>>>>>>>>>> >>> > >>>> JVM. >>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>> >>> > >>>> David >>>>>>>>>>>>> >>> > >>>> ----- >>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not >>>>>>>>>>>>> tagged as >>>>>>>>>>>>> being a >>>>>>>>>>>>> >>> JNI-attached >>>>>>>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = >>>>>>>>>>>>> false); // >>>>>>>>>>>>> for main >>>>>>>>>>>>> >>> thread and >>>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>>> behaviour by >>>>>>>>>>>>> itself as >>>>>>>>>>>>> >>> setName >>>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>>>>> thread. >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 >>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>> Apr 14 >>>>>>>>>>>>> 13:31:11 >>>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri >>>>>>>>>>>>> Apr 15 >>>>>>>>>>>>> 17:50:10 >>>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>>>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new >>>>>>>>>>>>> JavaThread(true); >>>>>>>>>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM >>>>>>>>>>>>> initialization >>>>>>>>>>>>> is complete >>>>>>>>>>>>> >>> - nop if >>>>>>>>>>>>> >>> > >>>>>>> no agents. >>>>>>>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>>>>> >>> > >>>>>>> + >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> I think we can do this straight after the >>>>>>>>>>>>> JavaThread >>>>>>>>>>>>> constructor. >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>>>>>>>>> tracing >>>>>>>>>>>>> >>> > >>>>>>> backend."); >>>>>>>>>>>>> >>> > >>>>>>> } >>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> If it wants to name its native threads then >>>>>>>>>>>>> it is >>>>>>>>>>>>> free >>>>>>>>>>>>> to do so, >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot >>>>>>>>>>>>> change >>>>>>>>>>>>> native >>>>>>>>>>>>> >>> thread name >>>>>>>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>>>>>> >>> > >>>>>>> However, I think that it should be changed if >>>>>>>>>>>>> Java >>>>>>>>>>>>> developer >>>>>>>>>>>>> >>> calls >>>>>>>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>>>>>>> >>> > >>>>>>> It is not the same of changing native thread >>>>>>>>>>>>> name at >>>>>>>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>>>>>>> SetNativeThreadName() as >>>>>>>>>>>>> below. >>>>>>>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> The decision to not change the name of >>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>> threads was a >>>>>>>>>>>>> >>> > >>>>>> deliberate one** - this functionality >>>>>>>>>>>>> originated >>>>>>>>>>>>> with the OSX >>>>>>>>>>>>> >>> port and >>>>>>>>>>>>> >>> > >>>>>> it was reported that the initial feedback with >>>>>>>>>>>>> this >>>>>>>>>>>>> feature was to >>>>>>>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that >>>>>>>>>>>>> had >>>>>>>>>>>>> been set by >>>>>>>>>>>>> >>> the host >>>>>>>>>>>>> >>> > >>>>>> process. If we do as you propose then we will >>>>>>>>>>>>> just >>>>>>>>>>>>> have an >>>>>>>>>>>>> >>> > >>>>>> inconsistency for people to complain about: >>>>>>>>>>>>> "why >>>>>>>>>>>>> does my >>>>>>>>>>>>> >>> native thread >>>>>>>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> ** If you follow the bugs and related >>>>>>>>>>>>> discussions on >>>>>>>>>>>>> this, the >>>>>>>>>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>>>>>>>>> thread only, >>>>>>>>>>>>> >>> non-JNI >>>>>>>>>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>>>>>>>>> were supposed >>>>>>>>>>>>> >>> to be >>>>>>>>>>>>> >>> > >>>>>> documented in the release notes - but as far >>>>>>>>>>>>> as I >>>>>>>>>>>>> can see >>>>>>>>>>>>> that >>>>>>>>>>>>> >>> never >>>>>>>>>>>>> >>> > >>>>>> happened. :( >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> My position on this remains that if it is >>>>>>>>>>>>> desirable >>>>>>>>>>>>> for >>>>>>>>>>>>> the main >>>>>>>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have >>>>>>>>>>>>> native >>>>>>>>>>>>> names >>>>>>>>>>>>> then the >>>>>>>>>>>>> >>> > >>>>>> launcher needs to be setting them using the >>>>>>>>>>>>> available >>>>>>>>>>>>> platform >>>>>>>>>>>>> >>> APIs. >>>>>>>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as >>>>>>>>>>>>> evidenced by >>>>>>>>>>>>> the VM >>>>>>>>>>>>> >>> code for >>>>>>>>>>>>> >>> > >>>>>> this - due to the need to verify API >>>>>>>>>>>>> availability. >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>>>>>>> Thread.setName would >>>>>>>>>>>>> >>> have to go >>>>>>>>>>>>> >>> > >>>>>> through our CCC process I think. But a >>>>>>>>>>>>> change in >>>>>>>>>>>>> the launcher >>>>>>>>>>>>> >>> would >>>>>>>>>>>>> >>> > >>>>>> not. >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> Sorry. >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>> David >>>>>>>>>>>>> >>> > >>>>>> ----- >>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu >>>>>>>>>>>>> Apr 14 >>>>>>>>>>>>> 13:31:11 >>>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri >>>>>>>>>>>>> Apr 15 >>>>>>>>>>>>> 17:50:10 >>>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>>>>>>> >>> > >>>>>>> // Thread naming only supported for the >>>>>>>>>>>>> current >>>>>>>>>>>>> thread, >>>>>>>>>>>>> >>> doesn't >>>>>>>>>>>>> >>> > >>>>>>> work >>>>>>>>>>>>> >>> > >>>>>>> for >>>>>>>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>>>>>>>> thread to avoid >>>>>>>>>>>>> >>> stepping >>>>>>>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>> David, >>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>>> this. I >>>>>>>>>>>>> don't like >>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>>>>>>> initializing VM >>>>>>>>>>>>> (before >>>>>>>>>>>>> >>> > >>>>>>>>> calling >>>>>>>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>>>>>>> AttachCurrentThread(). >>>>>>>>>>>>> So we >>>>>>>>>>>>> >>> can't >>>>>>>>>>>>> >>> > >>>>>>>>> set >>>>>>>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> Right - I came to the same realization >>>>>>>>>>>>> earlier >>>>>>>>>>>>> this >>>>>>>>>>>>> morning. >>>>>>>>>>>>> >>> Which, >>>>>>>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic >>>>>>>>>>>>> premise >>>>>>>>>>>>> here that >>>>>>>>>>>>> >>> we don't >>>>>>>>>>>>> >>> > >>>>>>>> set the name of threads not created by the >>>>>>>>>>>>> JVM. >>>>>>>>>>>>> The fact >>>>>>>>>>>>> >>> that the >>>>>>>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a >>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>> thread seems >>>>>>>>>>>>> >>> > >>>>>>>> accidental to me - so >>>>>>>>>>>>> JVM_SetNativeThreadName is >>>>>>>>>>>>> only >>>>>>>>>>>>> working by >>>>>>>>>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>>>>>>>>> used for the >>>>>>>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>>>>>>>>> inconsistently >>>>>>>>>>>>> >>> named at >>>>>>>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher >>>>>>>>>>>>> has >>>>>>>>>>>>> to be >>>>>>>>>>>>> >>> treated like >>>>>>>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. >>>>>>>>>>>>> If it >>>>>>>>>>>>> wants to >>>>>>>>>>>>> name its >>>>>>>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, >>>>>>>>>>>>> but I >>>>>>>>>>>>> would not be >>>>>>>>>>>>> >>> exporting >>>>>>>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>>>>>>>>> have to >>>>>>>>>>>>> use the OS >>>>>>>>>>>>> >>> > >>>>>>>> specific API's for that on a >>>>>>>>>>>>> platform-by-platform >>>>>>>>>>>>> basis. >>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> David >>>>>>>>>>>>> >>> > >>>>>>>> ----- >>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar >>>>>>>>>>>>> but >>>>>>>>>>>>> perform >>>>>>>>>>>>> >>> different >>>>>>>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>>>>>>> JVM_SetNativeThreadName >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the >>>>>>>>>>>>> current >>>>>>>>>>>>> thread, the >>>>>>>>>>>>> >>> second >>>>>>>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a >>>>>>>>>>>>> comment >>>>>>>>>>>>> somewhere >>>>>>>>>>>>> >>> about >>>>>>>>>>>>> >>> > >>>>>>>>>> what >>>>>>>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>>>>>>>> casts to >>>>>>>>>>>>> (void*) >>>>>>>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>>> >>> used at >>>>>>>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible >>>>>>>>>>>>> keep >>>>>>>>>>>>> the cast >>>>>>>>>>>>> >>> on the >>>>>>>>>>>>> >>> > >>>>>>>>>> same >>>>>>>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>>>> haven't had >>>>>>>>>>>>> time to >>>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>> >>> thread >>>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>>> then my >>>>>>>>>>>>> suggestion >>>>>>>>>>>>> >>> should >>>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>>> in our >>>>>>>>>>>>> treatment of >>>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, >>>>>>>>>>>>> and I >>>>>>>>>>>>> confirmed >>>>>>>>>>>>> >>> native >>>>>>>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) >>>>>>>>>>>>> throws >>>>>>>>>>>>> Exception{ >>>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>>> this. I >>>>>>>>>>>>> don't like >>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>>>>>>>>> comment. >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set >>>>>>>>>>>>> native >>>>>>>>>>>>> thread >>>>>>>>>>>>> >>> name, and JLI >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another >>>>>>>>>>>>> team so >>>>>>>>>>>>> >>> core-libs will >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>>>>>>>>> Kumar) - >>>>>>>>>>>>> now cc'd. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java >>>>>>>>>>>>> upcall to >>>>>>>>>>>>> >>> Thread.setName >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> than exporting >>>>>>>>>>>>> JVM_SetNativeThreadName. No >>>>>>>>>>>>> hotspot changes >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>>>>>>>> Thread#setName() in >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread >>>>>>>>>>>>> name. >>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not >>>>>>>>>>>>> alive, >>>>>>>>>>>>> which is >>>>>>>>>>>>> >>> why the >>>>>>>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>>>>>>> attached thread. >>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>>>> haven't had >>>>>>>>>>>>> time to >>>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>> >>> thread >>>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>>> then my >>>>>>>>>>>>> suggestion >>>>>>>>>>>>> >>> should >>>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>>> in our >>>>>>>>>>>>> treatment of >>>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>>> this. I >>>>>>>>>>>>> don't like >>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>>>>>>>> function to set >>>>>>>>>>>>> >>> native >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original >>>>>>>>>>>>> thread as >>>>>>>>>>>>> well ... >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug >>>>>>>>>>>>> (sorry >>>>>>>>>>>>> have >>>>>>>>>>>>> been on >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher >>>>>>>>>>>>> to be >>>>>>>>>>>>> correct >>>>>>>>>>>>> as we >>>>>>>>>>>>> >>> do not >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, >>>>>>>>>>>>> which >>>>>>>>>>>>> includes the >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa >>>>>>>>>>>>> Suenaga >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more >>>>>>>>>>>>> reviewer >>>>>>>>>>>>> :-) >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>>>>>>>>> Suenaga >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>> >>> >>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>>: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>> >>>>: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you >>>>>>>>>>>>> don't >>>>>>>>>>>>> set it: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* >>>>>>>>>>>>> main_thread = >>>>>>>>>>>>> new >>>>>>>>>>>>> >>> JavaThread(); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>>>>> >>> set_active_handles >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I >>>>>>>>>>>>> missing >>>>>>>>>>>>> something? >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the >>>>>>>>>>>>> same >>>>>>>>>>>>> to thread >>>>>>>>>>>>> >>> name in >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in >>>>>>>>>>>>> Thread or >>>>>>>>>>>>> setName(). >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in >>>>>>>>>>>>> Java >>>>>>>>>>>>> app, >>>>>>>>>>>>> native >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main >>>>>>>>>>>>> thread is >>>>>>>>>>>>> already >>>>>>>>>>>>> >>> starte >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is >>>>>>>>>>>>> set in >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of >>>>>>>>>>>>> setting >>>>>>>>>>>>> thrrad name >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But >>>>>>>>>>>>> then >>>>>>>>>>>>> something like >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>> Tue >>>>>>>>>>>>> >>> Mar 29 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>> Wed >>>>>>>>>>>>> >>> Mar 30 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial >>>>>>>>>>>>> Thread >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>>>>>>> create_initial_thread(Handle >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>>>>>>> initial_thread_name = >>>>>>>>>>>>> >>> "main"; >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>>>>>>>>> (THREAD, k); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle >>>>>>>>>>>>> thread_oop = >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>> >>> thread); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>>> thread_oop, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev >>>>>>>>>>>>> later. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>>>>>>>>> itself >>>>>>>>>>>>> 'java' and >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to >>>>>>>>>>>>> me. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of >>>>>>>>>>>>> the >>>>>>>>>>>>> process >>>>>>>>>>>>> (and >>>>>>>>>>>>> >>> thus >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is >>>>>>>>>>>>> 'main'. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in >>>>>>>>>>>>> the >>>>>>>>>>>>> process >>>>>>>>>>>>> is not >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main >>>>>>>>>>>>> thread >>>>>>>>>>>>> with >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is >>>>>>>>>>>>> for >>>>>>>>>>>>> >>> JavaThread. So I >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native >>>>>>>>>>>>> main >>>>>>>>>>>>> thread. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>>>>>>>>> anyhow, since >>>>>>>>>>>>> >>> we want >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java >>>>>>>>>>>>> thread >>>>>>>>>>>>> name >>>>>>>>>>>>> might >>>>>>>>>>>>> >>> have >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. >>>>>>>>>>>>> /proc. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid >>>>>>>>>>>>> comm' >>>>>>>>>>>>> | head -4 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with >>>>>>>>>>>>> something >>>>>>>>>>>>> like >>>>>>>>>>>>> 'Java Main >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not >>>>>>>>>>>>> be a >>>>>>>>>>>>> Java >>>>>>>>>>>>> >>> launcher - e.g. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI >>>>>>>>>>>>> application, >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native >>>>>>>>>>>>> main >>>>>>>>>>>>> thread >>>>>>>>>>>>> name, >>>>>>>>>>>>> >>> I think >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new >>>>>>>>>>>>> webrev? >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>> Suenaga wrote: >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will >>>>>>>>>>>>> set >>>>>>>>>>>>> thread >>>>>>>>>>>>> >>> name via >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread >>>>>>>>>>>>> does not >>>>>>>>>>>>> have it. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have >>>>>>>>>>>>> native >>>>>>>>>>>>> name, >>>>>>>>>>>>> and main >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main >>>>>>>>>>>>> thread >>>>>>>>>>>>> should have >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. >>>>>>>>>>>>> Could >>>>>>>>>>>>> you >>>>>>>>>>>>> review it? >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> From rachel.protacio at oracle.com Tue Apr 26 13:19:00 2016 From: rachel.protacio at oracle.com (Rachel Protacio) Date: Tue, 26 Apr 2016 09:19:00 -0400 Subject: RFR: 8152844: JVM InstanceKlass Methods For Obtaining Package/Module Should Be Moved to Klass In-Reply-To: <571EF022.30103@oracle.com> References: <571933EF.6040304@oracle.com> <57198BE9.5080107@oracle.com> <571A25FF.1080700@oracle.com> <571A41D1.30707@oracle.com> <571DAD2E.1000200@oracle.com> <571E1929.8040608@oracle.com> <571EF022.30103@oracle.com> Message-ID: <571F6AC4.8040801@oracle.com> Great, thank you. Will commit. Rachel On 4/26/2016 12:35 AM, David Holmes wrote: > On 25/04/2016 11:18 PM, Rachel Protacio wrote: >> Hi, >> >> No, that's fine. Here's the updated webrev: >> http://cr.openjdk.java.net/~rprotacio/8152844.01/ > > Thanks - looks good. > > David > >> Rachel >> >> On 4/25/2016 1:37 AM, David Holmes wrote: >>> Hi Rachel, >>> >>> Maybe too late, but despite comments to the contrary from the other >>> reviewers I think there are enough suggested changes being suggested >>> that I would want to see another webrev. >>> >>> Thanks, >>> David >>> >>> On 23/04/2016 1:22 AM, Rachel Protacio wrote: >>>> Hi, Coleen, >>>> >>>> Thanks for the review! I'll remove the arrayKlass entries and, >>>> seeing no >>>> other objections, will commit. >>>> >>>> Rachel >>>> >>>> On 4/22/2016 9:24 AM, Coleen Phillimore wrote: >>>>> >>>>> Hi, >>>>> >>>>> http://cr.openjdk.java.net/~rprotacio/8152844.00/src/share/vm/oops/arrayKlass.cpp.udiff.html >>>>> >>>>> >>>>> >>>>> >>>>> I don't think you need module or package declared in arrayKlass.hpp >>>>> since it should be abstract also, ie. there should be no instances of >>>>> ArrayKlass. >>>>> >>>>> Otherwise, looks great. I love seeing those InstanceKlass::casts go >>>>> away. >>>>> >>>>> Coleen >>>>> >>>>> >>>>> On 4/21/16 10:26 PM, David Holmes wrote: >>>>>> Hi Rachel, >>>>>> >>>>>> On 22/04/2016 6:11 AM, Rachel Protacio wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this fix for the package() and module() functions, >>>>>>> making >>>>>>> them pure virtual functions of Klass and implementing them in the >>>>>>> relevant child classes. This cleans up some verbose and repetitive >>>>>>> code >>>>>>> that was casting and checking klass types. Also added test cases to >>>>>>> runtime/modules/getModuleJNI/GetModule.java, ensuring that all the >>>>>>> module() functions work as expected. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152844 >>>>>>> Open webrev: http://cr.openjdk.java.net/~rprotacio/8152844.00/ >>>>>> >>>>>> The refactoring all looks good to me (though C++ annoys me in >>>>>> needing >>>>>> to re-declare the functions in each subclass :) ). >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Tested with jtreg tests in jdk/test (java/lang, java/io, >>>>>>> java/security, >>>>>>> java/util, tools/jimage, tools/jlink, and tools/jmod), JPRT, and >>>>>>> RBT >>>>>>> hotspot and non-colo tests. >>>>>>> >>>>>>> Thanks! >>>>>>> Rachel >>>>> >>>> >> From kumar.x.srinivasan at oracle.com Tue Apr 26 14:21:35 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 26 Apr 2016 07:21:35 -0700 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571F684B.9080501@oracle.com> References: <56F3F90D.9010408@gmail.com> <570FB328.5020902@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> <571EF995.3000109@oracle.com> <571F367B.3010200@oracle.com> <571F684B.9080501@oracle.! com> Message-ID: <571F796F.9010301@oracle.com> On 4/26/2016 6:08 AM, David Holmes wrote: > On 26/04/2016 10:54 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> For this issue, I think we can approach as following: >> >> >> 1. Export new JVM function to set native thread name >> It can avoid JNI call and can handle char* value. >> However this plan has been rejected. >> >> 2. Call uncaught exception handler from Launcher >> We have to clear (process) any pending exception before >> DetachCurrentThread() call. (not documented?) >> ------ >>> so note that we are potentially calling DetachCurrentThread with an >>> exception pending - which is prohibited by JNI** >> >>> **JNI spec needs to be modified here. >> ------ >> So we can process pending exception through uncaught >> exception handler. >> However, this plan has been rejected. >> >> 3. Do not set DestroyJavaVM name when exception is occurred >> It disrupts consistency for native thread name. >> >> 4. Attach to JVM to set native thread name for DestroyJavaVM >> It does not look good. >> >> >> If all of them are not accepted, I guess that it is difficult. >> Do you have any other idea? > > Sorry I don't. The basic idea of having the launcher set the native > thread name is fine, but the mechanism to do that has been > problematic. The "real" solution (ie one that other applications > hosting the jvm would need to use) is for the launcher to duplicate > the per-platform logic for os::set_native_thread_name - but that was > undesirable. Instead we have tried to avoid that by finding a way to > use whatever is already in the JVM - but adding a new JVM interface to > expose it directly is not ideal; and hooking into the java.lang.Thread > code to avoid that has run into these other problems. I really don't > want to take the logic for uncaught exception handling that is in > Thread::exit and duplicate it in the launcher. > > The effort and disruption here really does not justify the "it would > be nice to set the native thread name for the main thread" objective. > > I never expected this to be as problematic as it has turned out. I agree with Holmes-san, I think this needlessly complicates the launcher, more than I would like!, ie simply to set a name which seems to be useful only for folks trying to debug the VM ??? besides ps and few other OS related utils it has no visibility of value to the JRE or the JDK APIs. Thanks Kumar > > Sorry. > > David > ----- > > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/04/26 18:35, David Holmes wrote: >>> On 26/04/2016 7:22 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>>> I thought about being able to save/restore the original pending >>>>> exception but could not see a simple way to restore it - ie just by >>>>> poking it back into the thread's pending exception field. The problem >>>>> with using env->Throw is that it acts like the initial throwing of >>>>> the >>>>> exception and will have a number of side-effects that then get >>>>> doubled >>>>> up: >>>>> - logging statements (UL and Event logging) >>>>> - OOM counting >>>> >>>> Thanks, I understood. >>>> >>>>>>> so note that we are potentially calling DetachCurrentThread with an >>>>>>> exception pending - which is prohibited by JNI**, but which we >>>>>>> actually rely on for desired operation as DetachCurrentThread calls >>>>>>> thread->exit() which performs uncaught exception handling (ie it >>>>>>> prints the exception message and stacktrace) and then clears the >>>>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>>>> exceptions.) >>>> >>>> I think we can call uncaught exception handler before calling >>>> DestroyJavaVM(). >>>> I added it in new webrev for jdk: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/hotspot/ >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/jdk/ >>>> >>>> DispatchUncaughtException() in java.c emulates uncaught exception >>>> handler >>>> call in JavaThread::exit(). >>>> I think this patch can provide the solution for our issue. >>>> >>>> Could you check it? >>> >>> Sorry - this is getting far too disruptive. I do not support changing >>> the way the main thread behaves upon completion, just because we want >>> to set a native thread name. >>> >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/26 14:16, David Holmes wrote: >>>>> On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, Kumar, >>>>>> >>>>>> I think that we should evacuate original exception before >>>>>> DestroyJavaVM >>>>>> thread name is set. >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ >>>>>> >>>>>> I added it to LEAVE macro in new webrev. >>>>> >>>>> BTW: in the LEAVE macro, stylistically all the code should be in the >>>>> do { } while(false); loop. I overlooked that initially. >>>>> >>>>>> I tested it with following code. It works fine. >>>>>> >>>>>> ------------- >>>>>> public void main(String[] args){ >>>>>> throw new RuntimeException("test"); >>>>>> } >>>>>> ------------- >>>>>> >>>>>> What do you think about it? >>>>> >>>>> I thought about being able to save/restore the original pending >>>>> exception but could not see a simple way to restore it - ie just by >>>>> poking it back into the thread's pending exception field. The problem >>>>> with using env->Throw is that it acts like the initial throwing of >>>>> the >>>>> exception and will have a number of side-effects that then get >>>>> doubled >>>>> up: >>>>> - logging statements (UL and Event logging) >>>>> - OOM counting >>>>> >>>>> I'm not sure whether that is acceptable or not >>>>> >>>>> That aside you should check if orig_throwable is non-null before >>>>> clearing to avoid an unnecessary JNI call. >>>>> >>>>> Also "Resume original exception" -> "Restore any original exception" >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/26 11:16, David Holmes wrote: >>>>>>> Hi Yasumasa, Kumar, >>>>>>> >>>>>>> Turns out this change breaks the behaviour of the launcher in the >>>>>>> case >>>>>>> that main() completes by throwing an exception. >>>>>>> >>>>>>> What we have in the launcher is: >>>>>>> >>>>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>>>>> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; >>>>>>> LEAVE(); >>>>>>> >>>>>>> where LEAVE would have expanded to: >>>>>>> >>>>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>> ret = 1; \ >>>>>>> } \ >>>>>>> if (JNI_TRUE) { \ >>>>>>> (*vm)->DestroyJavaVM(vm); \ >>>>>>> return ret; \ >>>>>>> } \ >>>>>>> >>>>>>> so note that we are potentially calling DetachCurrentThread with an >>>>>>> exception pending - which is prohibited by JNI**, but which we >>>>>>> actually rely on for desired operation as DetachCurrentThread calls >>>>>>> thread->exit() which performs uncaught exception handling (ie it >>>>>>> prints the exception message and stacktrace) and then clears the >>>>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>>>> exceptions.) >>>>>>> >>>>>>> **JNI spec needs to be modified here. >>>>>>> >>>>>>> With the current change we have now inserted the following at the >>>>>>> start of LEAVE: >>>>>>> >>>>>>> SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>> if ((*env)->ExceptionOccurred(env)) { \ >>>>>>> (*env)->ExceptionClear(env); \ >>>>>>> } \ >>>>>>> >>>>>>> this has two unintended consequences: >>>>>>> >>>>>>> 1. SetNativeThreadName itself calls a number of JNI methods, >>>>>>> with the >>>>>>> exception pending - which is not permitted. So straight away >>>>>>> where we >>>>>>> have: >>>>>>> >>>>>>> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >>>>>>> >>>>>>> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make >>>>>>> calls >>>>>>> using the VM's CHECK_NULL macro - which checks for a pending >>>>>>> exception >>>>>>> (which it finds) and returns NULL. So the jli NULL_CHECK macro then >>>>>>> reports a JNI error: >>>>>>> >>>>>>> Error: A JNI error has occurred, please check your installation and >>>>>>> try again >>>>>>> >>>>>>> >>>>>>> 2. There is no longer an exception from main() for >>>>>>> DetachCurrentThread >>>>>>> to report, so we exit with a return code of 1 as required, but >>>>>>> don't >>>>>>> report the exception message/stacktrace. >>>>>>> >>>>>>> I don't see a reasonable solution for this other than abandoning >>>>>>> the >>>>>>> attempt to change the name from "main" to "DestroyJavaVM" - >>>>>>> which if >>>>>>> we can't do, I question the utility of setting the name in the >>>>>>> first >>>>>>> place (while it might be useful in some circumstances [when >>>>>>> main() is >>>>>>> running] it will cause confusion in others [when main() has >>>>>>> exited]). >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 25/04/2016 3:47 PM, David Holmes wrote: >>>>>>>> Looks good to me. >>>>>>>> >>>>>>>> I'll sponsor this "tomorrow". >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>>>>>>>> Hi Kumar, >>>>>>>>> >>>>>>>>> Thank you for your comment! >>>>>>>>> I've fixed them and uploaded new webrev. Could you review again? >>>>>>>>> >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>>>>>>>> >>>>>>>>>> Also a couple of minor suggestions: >>>>>>>>>> >>>>>>>>>> - * Set native thread name as possible. >>>>>>>>>> + * Set native thread name if possible. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> + /* >>>>>>>>>> - * We can clear pending exception because exception at >>>>>>>>>> this >>>>>>>>>> point >>>>>>>>>> - * is not critical. >>>>>>>>>> + */ >>>>>>>>>> >>>>>>>>>> + /* >>>>>>>>>> + * Clear non critical pending exceptions at this point. >>>>>>>>>> + */ >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Kumar >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is in the wrong place: >>>>>>>>>>> >>>>>>>>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>>> 1716 /* >>>>>>>>>>> 1717 * We can clear pending exception because >>>>>>>>>>> exception at >>>>>>>>>>> this point >>>>>>>>>>> 1718 * is not critical. >>>>>>>>>>> 1719 */ >>>>>>>>>>> 1720 (*env)->ExceptionClear(env); >>>>>>>>>>> 1721 } >>>>>>>>>>> >>>>>>>>>>> This above needs to be after >>>>>>>>>>> 391 SetNativeThreadName(env, "main"); >>>>>>>>>>> 392 >>>>>>>>>>> >>>>>>>>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>>>>>>>> but have also encountered an exception. In which case >>>>>>>>>>> the method SetNativeThreadName will return to the caller, as >>>>>>>>>>> if nothing has happened, because NULL_CHECK simply checks for >>>>>>>>>>> NULL >>>>>>>>>>> and returns to the caller. This will cause the caller to enter >>>>>>>>>>> the VM with exceptions. >>>>>>>>>>> >>>>>>>>>>> Kumar >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>>>> ignore >>>>>>>>>>>>> it. Either way we have to clear the exception before >>>>>>>>>>>>> continuing. >>>>>>>>>>>> >>>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have uploaded webrev.04 as below. >>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>> >>>>>>>>>>>>>> > - hotspot: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Looks fine. >>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > - jdk: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> As per private email (but repeated here on the record) in >>>>>>>>>>>>> java.c: >>>>>>>>>>>>> >>>>>>>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>>>>>>>> 1717 } >>>>>>>>>>>>> >>>>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>>>> ignore >>>>>>>>>>>>> it. Either way we have to clear the exception before >>>>>>>>>>>>> continuing. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>>>>>>>> >: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > - hotspot: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > - jdk: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>>>>>>>> process, I >>>>>>>>>>>>>> would have done it immediately after here: >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > I think that native thread name ("main") should be set >>>>>>>>>>>>>> just >>>>>>>>>>>>>> before >>>>>>>>>>>>>> > main method call. >>>>>>>>>>>>>> > However, main thread is already started, so I moved it >>>>>>>>>>>>>> as you >>>>>>>>>>>>>> suggested. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> >> One thing I dislike about the current structure is >>>>>>>>>>>>>> that we >>>>>>>>>>>>>> have to >>>>>>>>>>>>>> go from char* to java.lang.String to call setNativeName >>>>>>>>>>>>>> which >>>>>>>>>>>>>> then >>>>>>>>>>>>>> calls >>>>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back >>>>>>>>>>>>>> to a >>>>>>>>>>>>>> char* ! >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > SoI proposed to export new JVM function to set native >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> name with >>>>>>>>>>>>>> > const char *. >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Thanks for persevering with this to get it into the >>>>>>>>>>>>>> current >>>>>>>>>>>>>> form. >>>>>>>>>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Hi Gerard, >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > hi Yasumasa, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > ======== >>>>>>>>>>>>>> >>> > File: java.c >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>>>>>> >>> after every single JNI call? In this example instead of >>>>>>>>>>>>>> NULL_CHECK, >>>>>>>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> It is not critical if we encounter error at JNI >>>>>>>>>>>>>> function >>>>>>>>>>>>>> call >>>>>>>>>>>>>> because >>>>>>>>>>>>>> >>> we cannot set native thread name only. >>>>>>>>>>>>>> >>> So I think that we do not need to leave from launcher >>>>>>>>>>>>>> process. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> I agree we do not need to abort if an exception occurs >>>>>>>>>>>>>> (and in >>>>>>>>>>>>>> fact >>>>>>>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>>>>>>> but we >>>>>>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>>>>>> futher JNI >>>>>>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>>>>>> extensively >>>>>>>>>>>>>> throughout the launcher code - so if this usage is wrong >>>>>>>>>>>>>> then it >>>>>>>>>>>>>> is all >>>>>>>>>>>>>> wrong! More on this code below ... >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Other comments: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Please add a comment to the method now that you removed >>>>>>>>>>>>>> the >>>>>>>>>>>>>> internal >>>>>>>>>>>>>> comment: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> // Sets the native thread name for a JavaThread. If >>>>>>>>>>>>>> specifically >>>>>>>>>>>>>> >> // requested JNI-attached threads can also have their >>>>>>>>>>>>>> native >>>>>>>>>>>>>> name set; >>>>>>>>>>>>>> >> // otherwise we do not modify JNI-attached threads as >>>>>>>>>>>>>> it may >>>>>>>>>>>>>> interfere >>>>>>>>>>>>>> >> // with the application that created them. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Please add the following comments: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>>>>>>>> >> setNativeName(name, false); >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>>>>>>>> permitted) to >>>>>>>>>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>>>>>>>>> >> private native void setNativeName(String name, boolean >>>>>>>>>>>>>> allowAttachedThread); >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> 328 #define LEAVE() \ >>>>>>>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> I was going to suggest this be set later, but >>>>>>>>>>>>>> realized we >>>>>>>>>>>>>> have >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> attached to do this and that happens inside >>>>>>>>>>>>>> DestroyJavaVM. :) >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> + /* Set native thread name. */ >>>>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> The comment is redundant given the name of the method. >>>>>>>>>>>>>> That >>>>>>>>>>>>>> aside >>>>>>>>>>>>>> I'm not sure why you do this so late in the process, I would >>>>>>>>>>>>>> have >>>>>>>>>>>>>> done >>>>>>>>>>>>>> it immediately after here: >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>>>>>>>> >> 388 exit(1); >>>>>>>>>>>>>> >> 389 } >>>>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> + /** >>>>>>>>>>>>>> >> + * Set native thread name as possible. >>>>>>>>>>>>>> >> + */ >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Other than the as->if change I'm unclear where the >>>>>>>>>>>>>> "possible" >>>>>>>>>>>>>> bit >>>>>>>>>>>>>> comes into play - why would it not be possible? >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>>>>>>>> "java/lang/Thread")); >>>>>>>>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>>>>>>>> cls, >>>>>>>>>>>>>> >> 1707 "currentThread", >>>>>>>>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>>>>>>>> >> 1709 currentThreadID)); >>>>>>>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = >>>>>>>>>>>>>> (*env)->GetMethodID(env, >>>>>>>>>>>>>> cls, >>>>>>>>>>>>>> >> 1711 "setNativeName", >>>>>>>>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>>>>>>>> >> 1712 NULL_CHECK(nameString = >>>>>>>>>>>>>> (*env)->NewStringUTF(env, >>>>>>>>>>>>>> name)); >>>>>>>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>>>>>>>> setNativeNameID, >>>>>>>>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> As above NULL_CHECK is fine here, but we should check >>>>>>>>>>>>>> for >>>>>>>>>>>>>> and >>>>>>>>>>>>>> clear >>>>>>>>>>>>>> any pending exception after CallVoidMethod. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> One thing I dislike about the current structure is >>>>>>>>>>>>>> that we >>>>>>>>>>>>>> have to >>>>>>>>>>>>>> go from char* to java.lang.String to call setNativeName >>>>>>>>>>>>>> which >>>>>>>>>>>>>> then >>>>>>>>>>>>>> calls >>>>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back >>>>>>>>>>>>>> to a >>>>>>>>>>>>>> char* ! >>>>>>>>>>>>>> Overall I wonder about the affect on startup cost. But if >>>>>>>>>>>>>> there >>>>>>>>>>>>>> is an >>>>>>>>>>>>>> issue we can revisit this. >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>> >> David >>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be >>>>>>>>>>>>>> ?Set >>>>>>>>>>>>>> native >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> >>> name if possible.? not "Set native thread name as >>>>>>>>>>>>>> possible.?? >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Sorry for my bad English :-) >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>> > cheers >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > Hi David, >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > I uploaded new webrev: >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > - hotspot: >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > - jdk: >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>>>>>>>> setName so I'm >>>>>>>>>>>>>> >>> not sure what you were thinking here. To take advantage >>>>>>>>>>>>>> of an >>>>>>>>>>>>>> arg >>>>>>>>>>>>>> taking >>>>>>>>>>>>>> >>> JVM_SetNativThreadName you would need to call it >>>>>>>>>>>>>> directly as >>>>>>>>>>>>>> no Java >>>>>>>>>>>>>> >>> code will call it . ??? >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> >>> > > This change can set native thread name if main >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> changes to >>>>>>>>>>>>>> >>> JNI-attached thread. >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > Thanks, >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > Yasumasa >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>> > >>> Hi David, >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>>>> could be >>>>>>>>>>>>>> considered a >>>>>>>>>>>>>> >>> > >>>> regression that setName stops setting the >>>>>>>>>>>>>> native >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> main, even >>>>>>>>>>>>>> >>> > >>>> though we never really intended it to work >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> first place. >>>>>>>>>>>>>> >>> :( Such >>>>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> I understood. >>>>>>>>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at >>>>>>>>>>>>>> Oracle.) >>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>> >>> > >> Sorry you can't file a CCC request, you would >>>>>>>>>>>>>> need a >>>>>>>>>>>>>> sponsor for >>>>>>>>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>>>>>>>> proposed change >>>>>>>>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>>>>>>>> restore the >>>>>>>>>>>>>> >>> "broken" behaviour. >>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>> >>> > >>> I want to continue to discuss about it on >>>>>>>>>>>>>> JDK-8154331 >>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>> >>> > >> Okay we can do that. >>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>>> Further, we expect the launcher to use the >>>>>>>>>>>>>> supported >>>>>>>>>>>>>> JNI >>>>>>>>>>>>>> >>> interface (as >>>>>>>>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>>>>>>>> interface that >>>>>>>>>>>>>> >>> exists for >>>>>>>>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> I think that we do not use JVM interface if we >>>>>>>>>>>>>> add new >>>>>>>>>>>>>> method in >>>>>>>>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>> >>> > >>> --- >>>>>>>>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>>>>>>>> >>> > >>> +++ >>>>>>>>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>>>>>>>> >>> > >>> else >>>>>>>>>>>>>> >>> > >>> return md.toNameAndVersion() + " (" >>>>>>>>>>>>>> + loc >>>>>>>>>>>>>> + ")"; >>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>> >>> > >>> + static void setNativeThreadName(String >>>>>>>>>>>>>> name) { >>>>>>>>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>>>>>>>> >>> > >>> + } >>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>> >>> > >> You could also make that call via JNI >>>>>>>>>>>>>> directly, so >>>>>>>>>>>>>> not >>>>>>>>>>>>>> sure the >>>>>>>>>>>>>> >>> helper adds much here. But it won't work unless you >>>>>>>>>>>>>> change >>>>>>>>>>>>>> the >>>>>>>>>>>>>> semantics >>>>>>>>>>>>>> >>> of setName so I'm not sure what you were thinking >>>>>>>>>>>>>> here. To >>>>>>>>>>>>>> take >>>>>>>>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you >>>>>>>>>>>>>> would >>>>>>>>>>>>>> need to >>>>>>>>>>>>>> call >>>>>>>>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>> >>> > >> David >>>>>>>>>>>>>> >>> > >> ----- >>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>> Wed >>>>>>>>>>>>>> Apr 13 >>>>>>>>>>>>>> 14:19:30 >>>>>>>>>>>>>> >>> > >>> 2016 +0000 >>>>>>>>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>> Sat >>>>>>>>>>>>>> Apr 16 >>>>>>>>>>>>>> 11:25:53 >>>>>>>>>>>>>> >>> > >>> 2016 +0900 >>>>>>>>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean >>>>>>>>>>>>>> doXUsage); >>>>>>>>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char >>>>>>>>>>>>>> *optString); >>>>>>>>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char >>>>>>>>>>>>>> *optString); >>>>>>>>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, >>>>>>>>>>>>>> char >>>>>>>>>>>>>> *name); >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>>>> >>> > >>> do { \ >>>>>>>>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != >>>>>>>>>>>>>> JNI_OK) >>>>>>>>>>>>>> { \ >>>>>>>>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, >>>>>>>>>>>>>> argc); >>>>>>>>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, >>>>>>>>>>>>>> mainID, >>>>>>>>>>>>>> mainArgs); >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>>>>>>>> >>> > >>> joptString); >>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> +/** >>>>>>>>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>>>>>>>> >>> > >>> + */ >>>>>>>>>>>>>> >>> > >>> +static void >>>>>>>>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>>>>>>>> >>> > >>> +{ >>>>>>>>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>>>>>>>> >>> > >>> + jstring nameString; >>>>>>>>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>>>>>>>> >>> > >>> + "setNativeThreadName", >>>>>>>>>>>>>> "(Ljava/lang/String;)V")); >>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(nameString = >>>>>>>>>>>>>> (*env)->NewStringUTF(env, >>>>>>>>>>>>>> name)); >>>>>>>>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>>>>>>>> setNativeThreadNameID, >>>>>>>>>>>>>> >>> > >>> nameString); >>>>>>>>>>>>>> >>> > >>> +} >>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>> >>> > >>> /* >>>>>>>>>>>>>> >>> > >>> * Prints default usage or the Xusage message, >>>>>>>>>>>>>> see >>>>>>>>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> So I want to add new arg to >>>>>>>>>>>>>> JVM_SetNativeThreadName(). >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>>> However this is still a change to the exported >>>>>>>>>>>>>> JVM >>>>>>>>>>>>>> interface and so >>>>>>>>>>>>>> >>> > >>>> has to be approved. >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> Thanks, >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> Yasumasa >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> [1] >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> >>> > >>>>> Hi David, >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment >>>>>>>>>>>>>> here: >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = >>>>>>>>>>>>>> false); // >>>>>>>>>>>>>> for main >>>>>>>>>>>>>> >>> thread and >>>>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>>>>>>>> >>> > >>>>> I will send review request to >>>>>>>>>>>>>> hotspot-runtime-dev. >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>>>> behaviour by >>>>>>>>>>>>>> itself as >>>>>>>>>>>>>> >>> setName >>>>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the >>>>>>>>>>>>>> main >>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> I know. >>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>>>> could be >>>>>>>>>>>>>> considered a >>>>>>>>>>>>>> >>> > >>>> regression that setName stops setting the >>>>>>>>>>>>>> native >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> main, even >>>>>>>>>>>>>> >>> > >>>> though we never really intended it to work >>>>>>>>>>>>>> in the >>>>>>>>>>>>>> first place. >>>>>>>>>>>>>> >>> :( Such >>>>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>>>>>>>> JDK-7098194, >>>>>>>>>>>>>> and it is >>>>>>>>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in >>>>>>>>>>>>>> 7u2. >>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>>>>>>>>> >>> Thread#setNativeName() >>>>>>>>>>>>>> >>> > >>>>> only. >>>>>>>>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private >>>>>>>>>>>>>> method. >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>>>>>>>> >>> > >>>>> for force setting. >>>>>>>>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>>>>>>>> >>> > >>>>> However, this function is NOT public, so I >>>>>>>>>>>>>> think we >>>>>>>>>>>>>> can >>>>>>>>>>>>>> add one >>>>>>>>>>>>>> >>> more >>>>>>>>>>>>>> >>> > >>>>> argument. >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>>>>>>>> >>> > >>>>> If it is accepted, we can set native thread >>>>>>>>>>>>>> name >>>>>>>>>>>>>> from Java >>>>>>>>>>>>>> >>> launcher. >>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>> >>> > >>>> The private/public aspect of the Java API is >>>>>>>>>>>>>> not >>>>>>>>>>>>>> really at >>>>>>>>>>>>>> >>> issue. Yes >>>>>>>>>>>>>> >>> > >>>> we would add another arg to the JVM function to >>>>>>>>>>>>>> allow >>>>>>>>>>>>>> it to >>>>>>>>>>>>>> apply to >>>>>>>>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the >>>>>>>>>>>>>> arg >>>>>>>>>>>>>> reflect that >>>>>>>>>>>>>> >>> not just >>>>>>>>>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>>>>>>>>> exported JVM >>>>>>>>>>>>>> >>> interface >>>>>>>>>>>>>> >>> > >>>> and so has to be approved. Further, we >>>>>>>>>>>>>> expect the >>>>>>>>>>>>>> launcher to >>>>>>>>>>>>>> >>> use the >>>>>>>>>>>>>> >>> > >>>> supported JNI interface (as other processes >>>>>>>>>>>>>> would), >>>>>>>>>>>>>> not the >>>>>>>>>>>>>> internal >>>>>>>>>>>>>> >>> > >>>> JVM interface that exists for the JDK >>>>>>>>>>>>>> sources to >>>>>>>>>>>>>> communicate >>>>>>>>>>>>>> >>> with the >>>>>>>>>>>>>> >>> > >>>> JVM. >>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>> >>> > >>>> David >>>>>>>>>>>>>> >>> > >>>> ----- >>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not >>>>>>>>>>>>>> tagged as >>>>>>>>>>>>>> being a >>>>>>>>>>>>>> >>> JNI-attached >>>>>>>>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment >>>>>>>>>>>>>> here: >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = >>>>>>>>>>>>>> false); // >>>>>>>>>>>>>> for main >>>>>>>>>>>>>> >>> thread and >>>>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>>>> behaviour by >>>>>>>>>>>>>> itself as >>>>>>>>>>>>>> >>> setName >>>>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the >>>>>>>>>>>>>> main >>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 >>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>> Apr 14 >>>>>>>>>>>>>> 13:31:11 >>>>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri >>>>>>>>>>>>>> Apr 15 >>>>>>>>>>>>>> 17:50:10 >>>>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> // Attach the main thread to this os >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new >>>>>>>>>>>>>> JavaThread(); >>>>>>>>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new >>>>>>>>>>>>>> JavaThread(true); >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>>>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM >>>>>>>>>>>>>> initialization >>>>>>>>>>>>>> is complete >>>>>>>>>>>>>> >>> - nop if >>>>>>>>>>>>>> >>> > >>>>>>> no agents. >>>>>>>>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>>>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>>>>>> >>> > >>>>>>> + >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> I think we can do this straight after the >>>>>>>>>>>>>> JavaThread >>>>>>>>>>>>>> constructor. >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to >>>>>>>>>>>>>> start >>>>>>>>>>>>>> tracing >>>>>>>>>>>>>> >>> > >>>>>>> backend."); >>>>>>>>>>>>>> >>> > >>>>>>> } >>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> If it wants to name its native threads then >>>>>>>>>>>>>> it is >>>>>>>>>>>>>> free >>>>>>>>>>>>>> to do so, >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot >>>>>>>>>>>>>> change >>>>>>>>>>>>>> native >>>>>>>>>>>>>> >>> thread name >>>>>>>>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached >>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> >>> > >>>>>>> However, I think that it should be >>>>>>>>>>>>>> changed if >>>>>>>>>>>>>> Java >>>>>>>>>>>>>> developer >>>>>>>>>>>>>> >>> calls >>>>>>>>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>>>>>>>> >>> > >>>>>>> It is not the same of changing native thread >>>>>>>>>>>>>> name at >>>>>>>>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>>>>>>>> SetNativeThreadName() as >>>>>>>>>>>>>> below. >>>>>>>>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> The decision to not change the name of >>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>> threads was a >>>>>>>>>>>>>> >>> > >>>>>> deliberate one** - this functionality >>>>>>>>>>>>>> originated >>>>>>>>>>>>>> with the OSX >>>>>>>>>>>>>> >>> port and >>>>>>>>>>>>>> >>> > >>>>>> it was reported that the initial feedback >>>>>>>>>>>>>> with >>>>>>>>>>>>>> this >>>>>>>>>>>>>> feature was to >>>>>>>>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that >>>>>>>>>>>>>> had >>>>>>>>>>>>>> been set by >>>>>>>>>>>>>> >>> the host >>>>>>>>>>>>>> >>> > >>>>>> process. If we do as you propose then we will >>>>>>>>>>>>>> just >>>>>>>>>>>>>> have an >>>>>>>>>>>>>> >>> > >>>>>> inconsistency for people to complain about: >>>>>>>>>>>>>> "why >>>>>>>>>>>>>> does my >>>>>>>>>>>>>> >>> native thread >>>>>>>>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> ** If you follow the bugs and related >>>>>>>>>>>>>> discussions on >>>>>>>>>>>>>> this, the >>>>>>>>>>>>>> >>> > >>>>>> semantics and limitations (truncation, >>>>>>>>>>>>>> current >>>>>>>>>>>>>> thread only, >>>>>>>>>>>>>> >>> non-JNI >>>>>>>>>>>>>> >>> > >>>>>> threads only) of setting the native thread >>>>>>>>>>>>>> name >>>>>>>>>>>>>> were supposed >>>>>>>>>>>>>> >>> to be >>>>>>>>>>>>>> >>> > >>>>>> documented in the release notes - but as far >>>>>>>>>>>>>> as I >>>>>>>>>>>>>> can see >>>>>>>>>>>>>> that >>>>>>>>>>>>>> >>> never >>>>>>>>>>>>>> >>> > >>>>>> happened. :( >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> My position on this remains that if it is >>>>>>>>>>>>>> desirable >>>>>>>>>>>>>> for >>>>>>>>>>>>>> the main >>>>>>>>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have >>>>>>>>>>>>>> native >>>>>>>>>>>>>> names >>>>>>>>>>>>>> then the >>>>>>>>>>>>>> >>> > >>>>>> launcher needs to be setting them using the >>>>>>>>>>>>>> available >>>>>>>>>>>>>> platform >>>>>>>>>>>>>> >>> APIs. >>>>>>>>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as >>>>>>>>>>>>>> evidenced by >>>>>>>>>>>>>> the VM >>>>>>>>>>>>>> >>> code for >>>>>>>>>>>>>> >>> > >>>>>> this - due to the need to verify API >>>>>>>>>>>>>> availability. >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>>>>>>>> Thread.setName would >>>>>>>>>>>>>> >>> have to go >>>>>>>>>>>>>> >>> > >>>>>> through our CCC process I think. But a >>>>>>>>>>>>>> change in >>>>>>>>>>>>>> the launcher >>>>>>>>>>>>>> >>> would >>>>>>>>>>>>>> >>> > >>>>>> not. >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> Sorry. >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>> David >>>>>>>>>>>>>> >>> > >>>>>> ----- >>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu >>>>>>>>>>>>>> Apr 14 >>>>>>>>>>>>>> 13:31:11 >>>>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri >>>>>>>>>>>>>> Apr 15 >>>>>>>>>>>>>> 17:50:10 >>>>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>>>>>>>> >>> > >>>>>>> // Thread naming only supported for the >>>>>>>>>>>>>> current >>>>>>>>>>>>>> thread, >>>>>>>>>>>>>> >>> doesn't >>>>>>>>>>>>>> >>> > >>>>>>> work >>>>>>>>>>>>>> >>> > >>>>>>> for >>>>>>>>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>>>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>>>>>>>>> thread to avoid >>>>>>>>>>>>>> >>> stepping >>>>>>>>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>> David, >>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks >>>>>>>>>>>>>> about >>>>>>>>>>>>>> this. I >>>>>>>>>>>>>> don't like >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>>>>>>>> initializing VM >>>>>>>>>>>>>> (before >>>>>>>>>>>>>> >>> > >>>>>>>>> calling >>>>>>>>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>>>>>>>> AttachCurrentThread(). >>>>>>>>>>>>>> So we >>>>>>>>>>>>>> >>> can't >>>>>>>>>>>>>> >>> > >>>>>>>>> set >>>>>>>>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> Right - I came to the same realization >>>>>>>>>>>>>> earlier >>>>>>>>>>>>>> this >>>>>>>>>>>>>> morning. >>>>>>>>>>>>>> >>> Which, >>>>>>>>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic >>>>>>>>>>>>>> premise >>>>>>>>>>>>>> here that >>>>>>>>>>>>>> >>> we don't >>>>>>>>>>>>>> >>> > >>>>>>>> set the name of threads not created by the >>>>>>>>>>>>>> JVM. >>>>>>>>>>>>>> The fact >>>>>>>>>>>>>> >>> that the >>>>>>>>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a >>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>> thread seems >>>>>>>>>>>>>> >>> > >>>>>>>> accidental to me - so >>>>>>>>>>>>>> JVM_SetNativeThreadName is >>>>>>>>>>>>>> only >>>>>>>>>>>>>> working by >>>>>>>>>>>>>> >>> > >>>>>>>> accident for the initial attach, and >>>>>>>>>>>>>> can't be >>>>>>>>>>>>>> used for the >>>>>>>>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> inconsistently >>>>>>>>>>>>>> >>> named at >>>>>>>>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the >>>>>>>>>>>>>> launcher >>>>>>>>>>>>>> has >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> >>> treated like >>>>>>>>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. >>>>>>>>>>>>>> If it >>>>>>>>>>>>>> wants to >>>>>>>>>>>>>> name its >>>>>>>>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, >>>>>>>>>>>>>> but I >>>>>>>>>>>>>> would not be >>>>>>>>>>>>>> >>> exporting >>>>>>>>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it >>>>>>>>>>>>>> would >>>>>>>>>>>>>> have to >>>>>>>>>>>>>> use the OS >>>>>>>>>>>>>> >>> > >>>>>>>> specific API's for that on a >>>>>>>>>>>>>> platform-by-platform >>>>>>>>>>>>>> basis. >>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> David >>>>>>>>>>>>>> >>> > >>>>>>>> ----- >>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too >>>>>>>>>>>>>> similar >>>>>>>>>>>>>> but >>>>>>>>>>>>>> perform >>>>>>>>>>>>>> >>> different >>>>>>>>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>>>>>>>> JVM_SetNativeThreadName >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the >>>>>>>>>>>>>> current >>>>>>>>>>>>>> thread, the >>>>>>>>>>>>>> >>> second >>>>>>>>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a >>>>>>>>>>>>>> comment >>>>>>>>>>>>>> somewhere >>>>>>>>>>>>>> >>> about >>>>>>>>>>>>>> >>> > >>>>>>>>>> what >>>>>>>>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>>>>>>>>> casts to >>>>>>>>>>>>>> (void*) >>>>>>>>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>>>> >>> used at >>>>>>>>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible >>>>>>>>>>>>>> keep >>>>>>>>>>>>>> the cast >>>>>>>>>>>>>> >>> on the >>>>>>>>>>>>>> >>> > >>>>>>>>>> same >>>>>>>>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>> time to >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is >>>>>>>>>>>>>> considered a >>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>> >>> thread >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>>>> then my >>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>> >>> should >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>>>> in our >>>>>>>>>>>>>> treatment of >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA >>>>>>>>>>>>>> b112, >>>>>>>>>>>>>> and I >>>>>>>>>>>>>> confirmed >>>>>>>>>>>>>> >>> native >>>>>>>>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) >>>>>>>>>>>>>> throws >>>>>>>>>>>>>> Exception{ >>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks >>>>>>>>>>>>>> about >>>>>>>>>>>>>> this. I >>>>>>>>>>>>>> don't like >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing >>>>>>>>>>>>>> Kumar's >>>>>>>>>>>>>> comment. >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa >>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set >>>>>>>>>>>>>> native >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> >>> name, and JLI >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another >>>>>>>>>>>>>> team so >>>>>>>>>>>>>> >>> core-libs will >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in >>>>>>>>>>>>>> particular >>>>>>>>>>>>>> Kumar) - >>>>>>>>>>>>>> now cc'd. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java >>>>>>>>>>>>>> upcall to >>>>>>>>>>>>>> >>> Thread.setName >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> than exporting >>>>>>>>>>>>>> JVM_SetNativeThreadName. No >>>>>>>>>>>>>> hotspot changes >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to >>>>>>>>>>>>>> use >>>>>>>>>>>>>> Thread#setName() in >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread >>>>>>>>>>>>>> name. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not >>>>>>>>>>>>>> alive, >>>>>>>>>>>>>> which is >>>>>>>>>>>>>> >>> why the >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>>>>>>>> attached thread. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>> time to >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is >>>>>>>>>>>>>> considered a >>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>> >>> thread >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>>>> then my >>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>> >>> should >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>>>> in our >>>>>>>>>>>>>> treatment of >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks >>>>>>>>>>>>>> about >>>>>>>>>>>>>> this. I >>>>>>>>>>>>>> don't like >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>>>>>>>>> function to set >>>>>>>>>>>>>> >>> native >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original >>>>>>>>>>>>>> thread as >>>>>>>>>>>>>> well ... >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug >>>>>>>>>>>>>> (sorry >>>>>>>>>>>>>> have >>>>>>>>>>>>>> been on >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> correct >>>>>>>>>>>>>> as we >>>>>>>>>>>>>> >>> do not >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via >>>>>>>>>>>>>> JNI, >>>>>>>>>>>>>> which >>>>>>>>>>>>>> includes the >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa >>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more >>>>>>>>>>>>>> reviewer >>>>>>>>>>>>>> :-) >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin >>>>>>>>>>>>>> Ehn >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>>: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin >>>>>>>>>>>>>> Ehn" >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>> >>>>: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you >>>>>>>>>>>>>> don't >>>>>>>>>>>>>> set it: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* >>>>>>>>>>>>>> main_thread = >>>>>>>>>>>>>> new >>>>>>>>>>>>>> >>> JavaThread(); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this >>>>>>>>>>>>>> before >>>>>>>>>>>>>> >>> set_active_handles >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I >>>>>>>>>>>>>> missing >>>>>>>>>>>>>> something? >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the >>>>>>>>>>>>>> same >>>>>>>>>>>>>> to thread >>>>>>>>>>>>>> >>> name in >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in >>>>>>>>>>>>>> Thread or >>>>>>>>>>>>>> setName(). >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new >>>>>>>>>>>>>> thread in >>>>>>>>>>>>>> Java >>>>>>>>>>>>>> app, >>>>>>>>>>>>>> native >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main >>>>>>>>>>>>>> thread is >>>>>>>>>>>>>> already >>>>>>>>>>>>>> >>> starte >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is >>>>>>>>>>>>>> set in >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of >>>>>>>>>>>>>> setting >>>>>>>>>>>>>> thrrad name >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But >>>>>>>>>>>>>> then >>>>>>>>>>>>>> something like >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>> Tue >>>>>>>>>>>>>> >>> Mar 29 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>> Wed >>>>>>>>>>>>>> >>> Mar 30 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial >>>>>>>>>>>>>> Thread >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>>>>>>>> create_initial_thread(Handle >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>>>>>>>> initial_thread_name = >>>>>>>>>>>>>> >>> "main"; >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle >>>>>>>>>>>>>> klass >>>>>>>>>>>>>> (THREAD, k); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle >>>>>>>>>>>>>> thread_oop = >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>> >>> thread); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue >>>>>>>>>>>>>> result(T_VOID); >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>>>> thread_oop, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new >>>>>>>>>>>>>> webrev >>>>>>>>>>>>>> later. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to >>>>>>>>>>>>>> name >>>>>>>>>>>>>> itself >>>>>>>>>>>>>> 'java' and >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to >>>>>>>>>>>>>> me. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> process >>>>>>>>>>>>>> (and >>>>>>>>>>>>>> >>> thus >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is >>>>>>>>>>>>>> 'main'. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in >>>>>>>>>>>>>> the >>>>>>>>>>>>>> process >>>>>>>>>>>>>> is not >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> with >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> set_native_thread_name() is >>>>>>>>>>>>>> for >>>>>>>>>>>>>> >>> JavaThread. So I >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native >>>>>>>>>>>>>> main >>>>>>>>>>>>>> thread. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can >>>>>>>>>>>>>> change it >>>>>>>>>>>>>> anyhow, since >>>>>>>>>>>>>> >>> we want >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> name >>>>>>>>>>>>>> might >>>>>>>>>>>>>> >>> have >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. >>>>>>>>>>>>>> /proc. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid >>>>>>>>>>>>>> comm' >>>>>>>>>>>>>> | head -4 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with >>>>>>>>>>>>>> something >>>>>>>>>>>>>> like >>>>>>>>>>>>>> 'Java Main >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not >>>>>>>>>>>>>> be a >>>>>>>>>>>>>> Java >>>>>>>>>>>>>> >>> launcher - e.g. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI >>>>>>>>>>>>>> application, >>>>>>>>>>>>>> etc. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native >>>>>>>>>>>>>> main >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> name, >>>>>>>>>>>>>> >>> I think >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new >>>>>>>>>>>>>> webrev? >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>> Suenaga wrote: >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux >>>>>>>>>>>>>> will >>>>>>>>>>>>>> set >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> >>> name via >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread >>>>>>>>>>>>>> does not >>>>>>>>>>>>>> have it. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have >>>>>>>>>>>>>> native >>>>>>>>>>>>>> name, >>>>>>>>>>>>>> and main >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main >>>>>>>>>>>>>> thread >>>>>>>>>>>>>> should have >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. >>>>>>>>>>>>>> Could >>>>>>>>>>>>>> you >>>>>>>>>>>>>> review it? >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> From coleen.phillimore at oracle.com Tue Apr 26 14:28:56 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Apr 2016 10:28:56 -0400 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: <19009225-ff51-912d-ed98-3a86ddb7bfbb@oracle.com> References: <57176C38.3000109@oracle.com> <571F2B68.90803@oracle.com> <19009225-ff51-912d-ed98-3a86ddb7bfbb@oracle.com> Message-ID: Agree, looks good. Thank you for making this change. Coleen On 4/26/16 4:49 AM, Robbin Ehn wrote: > Hi Serguei, > > Thanks! > > /Robbin > > On 04/26/2016 10:48 AM, serguei.spitsyn at oracle.com wrote: >> Hi Robin, >> >> Looks good. >> >> Thanks, >> Serguei >> >> >> On 4/20/16 04:47, Robbin Ehn wrote: >>> Hi all, please review! >>> >>> print() method was changed in 8154041 to have outputStream argument, >>> this renames print to print_on. >>> Since JvmtiBreakpoint extends GrowableElement print_on already exists >>> as a virtual const method, hence the const changes. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 >>> Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ >>> >>> Tested with: >>> >>> #define TraceJVMTICalls false >>> in hotspot/src/share/vm/prims/jvmtiEnv.cpp >>> set to true with test-set nsk.jvmti.SetBreakpoint >>> >>> Thanks! >>> >>> /Robbin >> From coleen.phillimore at oracle.com Tue Apr 26 14:30:00 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 26 Apr 2016 10:30:00 -0400 Subject: RFR(XXS): 8155085: [ppc] Fix Type-O in "8154580: Save mirror in interpreter frame..." In-Reply-To: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> References: <27fc379414dd431ba18d78e55ebbd53b@DEWDFE13DE09.global.corp.sap> Message-ID: <19d46745-f9bb-7281-9091-40339ac71d16@oracle.com> Sorry for the typo. This looks good. Coleen On 4/26/16 5:10 AM, Lindenmaier, Goetz wrote: > Hi, > > I please need a review for this tiny fix of a Type-O. A single letter is missing: > http://cr.openjdk.java.net/~goetz/wr16/8155085-TypeO/webrev.00/ > > Best regards, > Goetz. From yasuenag at gmail.com Tue Apr 26 14:38:06 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 26 Apr 2016 23:38:06 +0900 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <571F796F.9010301@oracle.com> References: <56F3F90D.9010408@gmail.com> <57106ED3.5090002@oracle.com> <5710AC04.3080909@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> <571EF995.3000109@oracle.com> <571F367B.3010200@oracle.com> <571F684B.9080501@oracle.! com> <571F796F.9010301@oracle.com> Message-ID: <74485460-c558-0b56-191b-07b7830834b6@gmail.com> Hi Kumar, David, > simply to set a name which seems to be useful only for folks trying to debug > the VM ??? besides ps and few other OS related utils it > has no visibility of value to the JRE or the JDK APIs. I want to check CPU time through ps command on Linux. Usually, I get "ps -eLf" and nid in threaddump to check which thread spends much CPU time. If I can get thread name from output of ps command, I can check it rapidly. So I want to set "main" name at least. Thanks, Yasumasa On 2016/04/26 23:21, Kumar Srinivasan wrote: > > On 4/26/2016 6:08 AM, David Holmes wrote: >> On 26/04/2016 10:54 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> For this issue, I think we can approach as following: >>> >>> >>> 1. Export new JVM function to set native thread name >>> It can avoid JNI call and can handle char* value. >>> However this plan has been rejected. >>> >>> 2. Call uncaught exception handler from Launcher >>> We have to clear (process) any pending exception before >>> DetachCurrentThread() call. (not documented?) >>> ------ >>>> so note that we are potentially calling DetachCurrentThread with an >>>> exception pending - which is prohibited by JNI** >>> >>>> **JNI spec needs to be modified here. >>> ------ >>> So we can process pending exception through uncaught >>> exception handler. >>> However, this plan has been rejected. >>> >>> 3. Do not set DestroyJavaVM name when exception is occurred >>> It disrupts consistency for native thread name. >>> >>> 4. Attach to JVM to set native thread name for DestroyJavaVM >>> It does not look good. >>> >>> >>> If all of them are not accepted, I guess that it is difficult. >>> Do you have any other idea? >> >> Sorry I don't. The basic idea of having the launcher set the native thread name is fine, but the mechanism to do that has been problematic. The "real" solution (ie one that other applications hosting the jvm would need to use) is for the launcher to duplicate the per-platform logic for os::set_native_thread_name - but that was undesirable. Instead we have tried to avoid that by finding a way to use whatever is already in the JVM - but adding a new JVM interface to expose it directly is not ideal; and hooking into the java.lang.Thread code to avoid that has run into these other problems. I really don't want to take the logic for uncaught exception handling that is in Thread::exit and duplicate it in the launcher. >> >> The effort and disruption here really does not justify the "it would be nice to set the native thread name for the main thread" objective. >> >> I never expected this to be as problematic as it has turned out. > > I agree with Holmes-san, I think this needlessly complicates > the launcher, more than I would like!, ie simply to set a name > which seems to be useful only for folks trying to debug > the VM ??? besides ps and few other OS related utils it > has no visibility of value to the JRE or the JDK APIs. > > Thanks > > Kumar > >> >> Sorry. >> >> David >> ----- >> >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/04/26 18:35, David Holmes wrote: >>>> On 26/04/2016 7:22 PM, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>>> I thought about being able to save/restore the original pending >>>>>> exception but could not see a simple way to restore it - ie just by >>>>>> poking it back into the thread's pending exception field. The problem >>>>>> with using env->Throw is that it acts like the initial throwing of the >>>>>> exception and will have a number of side-effects that then get doubled >>>>>> up: >>>>>> - logging statements (UL and Event logging) >>>>>> - OOM counting >>>>> >>>>> Thanks, I understood. >>>>> >>>>>>>> so note that we are potentially calling DetachCurrentThread with an >>>>>>>> exception pending - which is prohibited by JNI**, but which we >>>>>>>> actually rely on for desired operation as DetachCurrentThread calls >>>>>>>> thread->exit() which performs uncaught exception handling (ie it >>>>>>>> prints the exception message and stacktrace) and then clears the >>>>>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>>>>> exceptions.) >>>>> >>>>> I think we can call uncaught exception handler before calling >>>>> DestroyJavaVM(). >>>>> I added it in new webrev for jdk: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/hotspot/ >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/jdk/ >>>>> >>>>> DispatchUncaughtException() in java.c emulates uncaught exception >>>>> handler >>>>> call in JavaThread::exit(). >>>>> I think this patch can provide the solution for our issue. >>>>> >>>>> Could you check it? >>>> >>>> Sorry - this is getting far too disruptive. I do not support changing >>>> the way the main thread behaves upon completion, just because we want >>>> to set a native thread name. >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/04/26 14:16, David Holmes wrote: >>>>>> On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: >>>>>>> Hi David, Kumar, >>>>>>> >>>>>>> I think that we should evacuate original exception before >>>>>>> DestroyJavaVM >>>>>>> thread name is set. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ >>>>>>> >>>>>>> I added it to LEAVE macro in new webrev. >>>>>> >>>>>> BTW: in the LEAVE macro, stylistically all the code should be in the >>>>>> do { } while(false); loop. I overlooked that initially. >>>>>> >>>>>>> I tested it with following code. It works fine. >>>>>>> >>>>>>> ------------- >>>>>>> public void main(String[] args){ >>>>>>> throw new RuntimeException("test"); >>>>>>> } >>>>>>> ------------- >>>>>>> >>>>>>> What do you think about it? >>>>>> >>>>>> I thought about being able to save/restore the original pending >>>>>> exception but could not see a simple way to restore it - ie just by >>>>>> poking it back into the thread's pending exception field. The problem >>>>>> with using env->Throw is that it acts like the initial throwing of the >>>>>> exception and will have a number of side-effects that then get doubled >>>>>> up: >>>>>> - logging statements (UL and Event logging) >>>>>> - OOM counting >>>>>> >>>>>> I'm not sure whether that is acceptable or not >>>>>> >>>>>> That aside you should check if orig_throwable is non-null before >>>>>> clearing to avoid an unnecessary JNI call. >>>>>> >>>>>> Also "Resume original exception" -> "Restore any original exception" >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2016/04/26 11:16, David Holmes wrote: >>>>>>>> Hi Yasumasa, Kumar, >>>>>>>> >>>>>>>> Turns out this change breaks the behaviour of the launcher in the >>>>>>>> case >>>>>>>> that main() completes by throwing an exception. >>>>>>>> >>>>>>>> What we have in the launcher is: >>>>>>>> >>>>>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs); >>>>>>>> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; >>>>>>>> LEAVE(); >>>>>>>> >>>>>>>> where LEAVE would have expanded to: >>>>>>>> >>>>>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>> ret = 1; \ >>>>>>>> } \ >>>>>>>> if (JNI_TRUE) { \ >>>>>>>> (*vm)->DestroyJavaVM(vm); \ >>>>>>>> return ret; \ >>>>>>>> } \ >>>>>>>> >>>>>>>> so note that we are potentially calling DetachCurrentThread with an >>>>>>>> exception pending - which is prohibited by JNI**, but which we >>>>>>>> actually rely on for desired operation as DetachCurrentThread calls >>>>>>>> thread->exit() which performs uncaught exception handling (ie it >>>>>>>> prints the exception message and stacktrace) and then clears the >>>>>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>>>>> exceptions.) >>>>>>>> >>>>>>>> **JNI spec needs to be modified here. >>>>>>>> >>>>>>>> With the current change we have now inserted the following at the >>>>>>>> start of LEAVE: >>>>>>>> >>>>>>>> SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>> if ((*env)->ExceptionOccurred(env)) { \ >>>>>>>> (*env)->ExceptionClear(env); \ >>>>>>>> } \ >>>>>>>> >>>>>>>> this has two unintended consequences: >>>>>>>> >>>>>>>> 1. SetNativeThreadName itself calls a number of JNI methods, with the >>>>>>>> exception pending - which is not permitted. So straight away where we >>>>>>>> have: >>>>>>>> >>>>>>>> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >>>>>>>> >>>>>>>> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make >>>>>>>> calls >>>>>>>> using the VM's CHECK_NULL macro - which checks for a pending >>>>>>>> exception >>>>>>>> (which it finds) and returns NULL. So the jli NULL_CHECK macro then >>>>>>>> reports a JNI error: >>>>>>>> >>>>>>>> Error: A JNI error has occurred, please check your installation and >>>>>>>> try again >>>>>>>> >>>>>>>> >>>>>>>> 2. There is no longer an exception from main() for >>>>>>>> DetachCurrentThread >>>>>>>> to report, so we exit with a return code of 1 as required, but don't >>>>>>>> report the exception message/stacktrace. >>>>>>>> >>>>>>>> I don't see a reasonable solution for this other than abandoning the >>>>>>>> attempt to change the name from "main" to "DestroyJavaVM" - which if >>>>>>>> we can't do, I question the utility of setting the name in the first >>>>>>>> place (while it might be useful in some circumstances [when main() is >>>>>>>> running] it will cause confusion in others [when main() has exited]). >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 25/04/2016 3:47 PM, David Holmes wrote: >>>>>>>>> Looks good to me. >>>>>>>>> >>>>>>>>> I'll sponsor this "tomorrow". >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>>>>>>>>> Hi Kumar, >>>>>>>>>> >>>>>>>>>> Thank you for your comment! >>>>>>>>>> I've fixed them and uploaded new webrev. Could you review again? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>>>>>>>>> >>>>>>>>>>> Also a couple of minor suggestions: >>>>>>>>>>> >>>>>>>>>>> - * Set native thread name as possible. >>>>>>>>>>> + * Set native thread name if possible. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> + /* >>>>>>>>>>> - * We can clear pending exception because exception at this >>>>>>>>>>> point >>>>>>>>>>> - * is not critical. >>>>>>>>>>> + */ >>>>>>>>>>> >>>>>>>>>>> + /* >>>>>>>>>>> + * Clear non critical pending exceptions at this point. >>>>>>>>>>> + */ >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Kumar >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> This is in the wrong place: >>>>>>>>>>>> >>>>>>>>>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>>>> 1716 /* >>>>>>>>>>>> 1717 * We can clear pending exception because exception at >>>>>>>>>>>> this point >>>>>>>>>>>> 1718 * is not critical. >>>>>>>>>>>> 1719 */ >>>>>>>>>>>> 1720 (*env)->ExceptionClear(env); >>>>>>>>>>>> 1721 } >>>>>>>>>>>> >>>>>>>>>>>> This above needs to be after >>>>>>>>>>>> 391 SetNativeThreadName(env, "main"); >>>>>>>>>>>> 392 >>>>>>>>>>>> >>>>>>>>>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>>>>>>>>> but have also encountered an exception. In which case >>>>>>>>>>>> the method SetNativeThreadName will return to the caller, as >>>>>>>>>>>> if nothing has happened, because NULL_CHECK simply checks for >>>>>>>>>>>> NULL >>>>>>>>>>>> and returns to the caller. This will cause the caller to enter >>>>>>>>>>>> the VM with exceptions. >>>>>>>>>>>> >>>>>>>>>>>> Kumar >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>>>>> ignore >>>>>>>>>>>>>> it. Either way we have to clear the exception before >>>>>>>>>>>>>> continuing. >>>>>>>>>>>>> >>>>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>>>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have uploaded webrev.04 as below. >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > - hotspot: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Looks fine. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > - jdk: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> As per private email (but repeated here on the record) in >>>>>>>>>>>>>> java.c: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>>>>>>>>> 1717 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>>>>> ignore >>>>>>>>>>>>>> it. Either way we have to clear the exception before >>>>>>>>>>>>>> continuing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>>>>>>>>> >: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > - hotspot: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > - jdk: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>>>>>>>>> process, I >>>>>>>>>>>>>>> would have done it immediately after here: >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > I think that native thread name ("main") should be set just >>>>>>>>>>>>>>> before >>>>>>>>>>>>>>> > main method call. >>>>>>>>>>>>>>> > However, main thread is already started, so I moved it >>>>>>>>>>>>>>> as you >>>>>>>>>>>>>>> suggested. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>> go from char* to java.lang.String to call setNativeName which >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> calls >>>>>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back >>>>>>>>>>>>>>> to a >>>>>>>>>>>>>>> char* ! >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > SoI proposed to export new JVM function to set native >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> name with >>>>>>>>>>>>>>> > const char *. >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Thanks for persevering with this to get it into the >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> form. >>>>>>>>>>>>>>> Sorry I haven't been able to do a detailed review until now. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Hi Gerard, >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > hi Yasumasa, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > ======== >>>>>>>>>>>>>>> >>> > File: java.c >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>>>>>>> >>> after every single JNI call? In this example instead of >>>>>>>>>>>>>>> NULL_CHECK, >>>>>>>>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> It is not critical if we encounter error at JNI function >>>>>>>>>>>>>>> call >>>>>>>>>>>>>>> because >>>>>>>>>>>>>>> >>> we cannot set native thread name only. >>>>>>>>>>>>>>> >>> So I think that we do not need to leave from launcher >>>>>>>>>>>>>>> process. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> I agree we do not need to abort if an exception occurs >>>>>>>>>>>>>>> (and in >>>>>>>>>>>>>>> fact >>>>>>>>>>>>>>> I don't think an exception is even possible from this code), >>>>>>>>>>>>>>> but we >>>>>>>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>>>>>>> futher JNI >>>>>>>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>>>>>>> extensively >>>>>>>>>>>>>>> throughout the launcher code - so if this usage is wrong >>>>>>>>>>>>>>> then it >>>>>>>>>>>>>>> is all >>>>>>>>>>>>>>> wrong! More on this code below ... >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Other comments: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Please add a comment to the method now that you removed >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> internal >>>>>>>>>>>>>>> comment: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> // Sets the native thread name for a JavaThread. If >>>>>>>>>>>>>>> specifically >>>>>>>>>>>>>>> >> // requested JNI-attached threads can also have their >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> name set; >>>>>>>>>>>>>>> >> // otherwise we do not modify JNI-attached threads as >>>>>>>>>>>>>>> it may >>>>>>>>>>>>>>> interfere >>>>>>>>>>>>>>> >> // with the application that created them. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Please add the following comments: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>>>>>>>>> >> setNativeName(name, false); >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>>>>>>>>> permitted) to >>>>>>>>>>>>>>> >> + // allow JNI-attached threads to set their native name >>>>>>>>>>>>>>> >> private native void setNativeName(String name, boolean >>>>>>>>>>>>>>> allowAttachedThread); >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> 328 #define LEAVE() \ >>>>>>>>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> I was going to suggest this be set later, but realized we >>>>>>>>>>>>>>> have >>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>> attached to do this and that happens inside DestroyJavaVM. :) >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> + /* Set native thread name. */ >>>>>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> The comment is redundant given the name of the method. >>>>>>>>>>>>>>> That >>>>>>>>>>>>>>> aside >>>>>>>>>>>>>>> I'm not sure why you do this so late in the process, I would >>>>>>>>>>>>>>> have >>>>>>>>>>>>>>> done >>>>>>>>>>>>>>> it immediately after here: >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>>>>>>>>> >> 388 exit(1); >>>>>>>>>>>>>>> >> 389 } >>>>>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> + /** >>>>>>>>>>>>>>> >> + * Set native thread name as possible. >>>>>>>>>>>>>>> >> + */ >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Other than the as->if change I'm unclear where the >>>>>>>>>>>>>>> "possible" >>>>>>>>>>>>>>> bit >>>>>>>>>>>>>>> comes into play - why would it not be possible? >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>>>>>>>>> "java/lang/Thread")); >>>>>>>>>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>>>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>>>>>>>>> cls, >>>>>>>>>>>>>>> >> 1707 "currentThread", >>>>>>>>>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>>>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>>>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>>>>>>>>> >> 1709 currentThreadID)); >>>>>>>>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = >>>>>>>>>>>>>>> (*env)->GetMethodID(env, >>>>>>>>>>>>>>> cls, >>>>>>>>>>>>>>> >> 1711 "setNativeName", >>>>>>>>>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>>>>>>>>> >> 1712 NULL_CHECK(nameString = (*env)->NewStringUTF(env, >>>>>>>>>>>>>>> name)); >>>>>>>>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>>>>>>>>> setNativeNameID, >>>>>>>>>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> As above NULL_CHECK is fine here, but we should check for >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> clear >>>>>>>>>>>>>>> any pending exception after CallVoidMethod. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> One thing I dislike about the current structure is that we >>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>> go from char* to java.lang.String to call setNativeName which >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> calls >>>>>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back >>>>>>>>>>>>>>> to a >>>>>>>>>>>>>>> char* ! >>>>>>>>>>>>>>> Overall I wonder about the affect on startup cost. But if >>>>>>>>>>>>>>> there >>>>>>>>>>>>>>> is an >>>>>>>>>>>>>>> issue we can revisit this. >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>> >> David >>>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be >>>>>>>>>>>>>>> ?Set >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> >>> name if possible.? not "Set native thread name as >>>>>>>>>>>>>>> possible.?? >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Sorry for my bad English :-) >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>> > cheers >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > Hi David, >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > I uploaded new webrev: >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > - hotspot: >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > - jdk: >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>>>>>>>>> setName so I'm >>>>>>>>>>>>>>> >>> not sure what you were thinking here. To take advantage >>>>>>>>>>>>>>> of an >>>>>>>>>>>>>>> arg >>>>>>>>>>>>>>> taking >>>>>>>>>>>>>>> >>> JVM_SetNativThreadName you would need to call it >>>>>>>>>>>>>>> directly as >>>>>>>>>>>>>>> no Java >>>>>>>>>>>>>>> >>> code will call it . ??? >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>> >>> > > This change can set native thread name if main >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> changes to >>>>>>>>>>>>>>> >>> JNI-attached thread. >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > Thanks, >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > Yasumasa >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>>>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>> > >>> Hi David, >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>>>>> could be >>>>>>>>>>>>>>> considered a >>>>>>>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> main, even >>>>>>>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>>>>>>> first place. >>>>>>>>>>>>>>> >>> :( Such >>>>>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> I understood. >>>>>>>>>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>>>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at >>>>>>>>>>>>>>> Oracle.) >>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>> >>> > >> Sorry you can't file a CCC request, you would >>>>>>>>>>>>>>> need a >>>>>>>>>>>>>>> sponsor for >>>>>>>>>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>>>>>>>>> proposed change >>>>>>>>>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>>>>>>>>> restore the >>>>>>>>>>>>>>> >>> "broken" behaviour. >>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>> >>> > >>> I want to continue to discuss about it on >>>>>>>>>>>>>>> JDK-8154331 >>>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>> >>> > >> Okay we can do that. >>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>>> Further, we expect the launcher to use the >>>>>>>>>>>>>>> supported >>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>> >>> interface (as >>>>>>>>>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>>>>>>>>> interface that >>>>>>>>>>>>>>> >>> exists for >>>>>>>>>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> I think that we do not use JVM interface if we >>>>>>>>>>>>>>> add new >>>>>>>>>>>>>>> method in >>>>>>>>>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>>> >>> > >>> --- >>>>>>>>>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>>>>>>>>> >>> > >>> +++ >>>>>>>>>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>>>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>>>>>>>>> >>> > >>> else >>>>>>>>>>>>>>> >>> > >>> return md.toNameAndVersion() + " (" >>>>>>>>>>>>>>> + loc >>>>>>>>>>>>>>> + ")"; >>>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>>> >>> > >>> + static void setNativeThreadName(String >>>>>>>>>>>>>>> name) { >>>>>>>>>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>>>>>>>>> >>> > >>> + } >>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>> >>> > >> You could also make that call via JNI directly, so >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> sure the >>>>>>>>>>>>>>> >>> helper adds much here. But it won't work unless you >>>>>>>>>>>>>>> change >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> semantics >>>>>>>>>>>>>>> >>> of setName so I'm not sure what you were thinking >>>>>>>>>>>>>>> here. To >>>>>>>>>>>>>>> take >>>>>>>>>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you >>>>>>>>>>>>>>> would >>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>> call >>>>>>>>>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>> >>> > >> David >>>>>>>>>>>>>>> >>> > >> ----- >>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>>> Wed >>>>>>>>>>>>>>> Apr 13 >>>>>>>>>>>>>>> 14:19:30 >>>>>>>>>>>>>>> >>> > >>> 2016 +0000 >>>>>>>>>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>>> Sat >>>>>>>>>>>>>>> Apr 16 >>>>>>>>>>>>>>> 11:25:53 >>>>>>>>>>>>>>> >>> > >>> 2016 +0900 >>>>>>>>>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>>>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean >>>>>>>>>>>>>>> doXUsage); >>>>>>>>>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char >>>>>>>>>>>>>>> *optString); >>>>>>>>>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char >>>>>>>>>>>>>>> *optString); >>>>>>>>>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* env, char >>>>>>>>>>>>>>> *name); >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>>>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>>>>> >>> > >>> do { \ >>>>>>>>>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != >>>>>>>>>>>>>>> JNI_OK) >>>>>>>>>>>>>>> { \ >>>>>>>>>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>>>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, >>>>>>>>>>>>>>> argc); >>>>>>>>>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>>>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, >>>>>>>>>>>>>>> mainID, >>>>>>>>>>>>>>> mainArgs); >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>>>>>>>>> >>> > >>> joptString); >>>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> +/** >>>>>>>>>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>>>>>>>>> >>> > >>> + */ >>>>>>>>>>>>>>> >>> > >>> +static void >>>>>>>>>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>>>>>>>>> >>> > >>> +{ >>>>>>>>>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>>>>>>>>> >>> > >>> + jstring nameString; >>>>>>>>>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>>>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>>>>>>>>> >>> > >>> + "setNativeThreadName", >>>>>>>>>>>>>>> "(Ljava/lang/String;)V")); >>>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(nameString = >>>>>>>>>>>>>>> (*env)->NewStringUTF(env, >>>>>>>>>>>>>>> name)); >>>>>>>>>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>>>>>>>>> setNativeThreadNameID, >>>>>>>>>>>>>>> >>> > >>> nameString); >>>>>>>>>>>>>>> >>> > >>> +} >>>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>>> >>> > >>> /* >>>>>>>>>>>>>>> >>> > >>> * Prints default usage or the Xusage message, >>>>>>>>>>>>>>> see >>>>>>>>>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> So I want to add new arg to >>>>>>>>>>>>>>> JVM_SetNativeThreadName(). >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>>> However this is still a change to the exported >>>>>>>>>>>>>>> JVM >>>>>>>>>>>>>>> interface and so >>>>>>>>>>>>>>> >>> > >>>> has to be approved. >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> Thanks, >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> Yasumasa >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> [1] >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>>>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>> > >>>>> Hi David, >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = >>>>>>>>>>>>>>> false); // >>>>>>>>>>>>>>> for main >>>>>>>>>>>>>>> >>> thread and >>>>>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>>>>>>>>> >>> > >>>>> I will send review request to >>>>>>>>>>>>>>> hotspot-runtime-dev. >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>>>>> behaviour by >>>>>>>>>>>>>>> itself as >>>>>>>>>>>>>>> >>> setName >>>>>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> I know. >>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>>>>> could be >>>>>>>>>>>>>>> considered a >>>>>>>>>>>>>>> >>> > >>>> regression that setName stops setting the native >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> main, even >>>>>>>>>>>>>>> >>> > >>>> though we never really intended it to work in the >>>>>>>>>>>>>>> first place. >>>>>>>>>>>>>>> >>> :( Such >>>>>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>>>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>>>>>>>>> JDK-7098194, >>>>>>>>>>>>>>> and it is >>>>>>>>>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>> >>> > >>>> Yes this all came in as part of the OSX port in >>>>>>>>>>>>>>> 7u2. >>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>> >>> > >>>>> However, this function seems to be called from >>>>>>>>>>>>>>> >>> Thread#setNativeName() >>>>>>>>>>>>>>> >>> > >>>>> only. >>>>>>>>>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is private >>>>>>>>>>>>>>> method. >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>>>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>>>>>>>>> >>> > >>>>> for force setting. >>>>>>>>>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>>>>>>>>> >>> > >>>>> However, this function is NOT public, so I >>>>>>>>>>>>>>> think we >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>> add one >>>>>>>>>>>>>>> >>> more >>>>>>>>>>>>>>> >>> > >>>>> argument. >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>>>>>>>>> >>> > >>>>> If it is accepted, we can set native thread name >>>>>>>>>>>>>>> from Java >>>>>>>>>>>>>>> >>> launcher. >>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>> >>> > >>>> The private/public aspect of the Java API is not >>>>>>>>>>>>>>> really at >>>>>>>>>>>>>>> >>> issue. Yes >>>>>>>>>>>>>>> >>> > >>>> we would add another arg to the JVM function to >>>>>>>>>>>>>>> allow >>>>>>>>>>>>>>> it to >>>>>>>>>>>>>>> apply to >>>>>>>>>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer the arg >>>>>>>>>>>>>>> reflect that >>>>>>>>>>>>>>> >>> not just >>>>>>>>>>>>>>> >>> > >>>> "force"). However this is still a change to the >>>>>>>>>>>>>>> exported JVM >>>>>>>>>>>>>>> >>> interface >>>>>>>>>>>>>>> >>> > >>>> and so has to be approved. Further, we expect the >>>>>>>>>>>>>>> launcher to >>>>>>>>>>>>>>> >>> use the >>>>>>>>>>>>>>> >>> > >>>> supported JNI interface (as other processes >>>>>>>>>>>>>>> would), >>>>>>>>>>>>>>> not the >>>>>>>>>>>>>>> internal >>>>>>>>>>>>>>> >>> > >>>> JVM interface that exists for the JDK sources to >>>>>>>>>>>>>>> communicate >>>>>>>>>>>>>>> >>> with the >>>>>>>>>>>>>>> >>> > >>>> JVM. >>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>> >>> > >>>> David >>>>>>>>>>>>>>> >>> > >>>> ----- >>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not >>>>>>>>>>>>>>> tagged as >>>>>>>>>>>>>>> being a >>>>>>>>>>>>>>> >>> JNI-attached >>>>>>>>>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment here: >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = >>>>>>>>>>>>>>> false); // >>>>>>>>>>>>>>> for main >>>>>>>>>>>>>>> >>> thread and >>>>>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>>>>> behaviour by >>>>>>>>>>>>>>> itself as >>>>>>>>>>>>>>> >>> setName >>>>>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for the main >>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 >>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>> Apr 14 >>>>>>>>>>>>>>> 13:31:11 >>>>>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri >>>>>>>>>>>>>>> Apr 15 >>>>>>>>>>>>>>> 17:50:10 >>>>>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> // Attach the main thread to this os thread >>>>>>>>>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new JavaThread(); >>>>>>>>>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new >>>>>>>>>>>>>>> JavaThread(true); >>>>>>>>>>>>>>> >>> > >>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>>>> >>> > >>>>>>> // must do this before set_active_handles >>>>>>>>>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM >>>>>>>>>>>>>>> initialization >>>>>>>>>>>>>>> is complete >>>>>>>>>>>>>>> >>> - nop if >>>>>>>>>>>>>>> >>> > >>>>>>> no agents. >>>>>>>>>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>>>>>>>>> >>> > >>>>>>> + main_thread->set_done_attaching_via_jni(); >>>>>>>>>>>>>>> >>> > >>>>>>> + >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> I think we can do this straight after the >>>>>>>>>>>>>>> JavaThread >>>>>>>>>>>>>>> constructor. >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to start >>>>>>>>>>>>>>> tracing >>>>>>>>>>>>>>> >>> > >>>>>>> backend."); >>>>>>>>>>>>>>> >>> > >>>>>>> } >>>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> If it wants to name its native threads then >>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>> free >>>>>>>>>>>>>>> to do so, >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot >>>>>>>>>>>>>>> change >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> >>> thread name >>>>>>>>>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached thread. >>>>>>>>>>>>>>> >>> > >>>>>>> However, I think that it should be changed if >>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>> developer >>>>>>>>>>>>>>> >>> calls >>>>>>>>>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>>>>>>>>> >>> > >>>>>>> It is not the same of changing native thread >>>>>>>>>>>>>>> name at >>>>>>>>>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>>>>>>>>> SetNativeThreadName() as >>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> The decision to not change the name of >>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>> threads was a >>>>>>>>>>>>>>> >>> > >>>>>> deliberate one** - this functionality >>>>>>>>>>>>>>> originated >>>>>>>>>>>>>>> with the OSX >>>>>>>>>>>>>>> >>> port and >>>>>>>>>>>>>>> >>> > >>>>>> it was reported that the initial feedback with >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> feature was to >>>>>>>>>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that >>>>>>>>>>>>>>> had >>>>>>>>>>>>>>> been set by >>>>>>>>>>>>>>> >>> the host >>>>>>>>>>>>>>> >>> > >>>>>> process. If we do as you propose then we will >>>>>>>>>>>>>>> just >>>>>>>>>>>>>>> have an >>>>>>>>>>>>>>> >>> > >>>>>> inconsistency for people to complain about: >>>>>>>>>>>>>>> "why >>>>>>>>>>>>>>> does my >>>>>>>>>>>>>>> >>> native thread >>>>>>>>>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>>>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> ** If you follow the bugs and related >>>>>>>>>>>>>>> discussions on >>>>>>>>>>>>>>> this, the >>>>>>>>>>>>>>> >>> > >>>>>> semantics and limitations (truncation, current >>>>>>>>>>>>>>> thread only, >>>>>>>>>>>>>>> >>> non-JNI >>>>>>>>>>>>>>> >>> > >>>>>> threads only) of setting the native thread name >>>>>>>>>>>>>>> were supposed >>>>>>>>>>>>>>> >>> to be >>>>>>>>>>>>>>> >>> > >>>>>> documented in the release notes - but as far >>>>>>>>>>>>>>> as I >>>>>>>>>>>>>>> can see >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> >>> never >>>>>>>>>>>>>>> >>> > >>>>>> happened. :( >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> My position on this remains that if it is >>>>>>>>>>>>>>> desirable >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> the main >>>>>>>>>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> names >>>>>>>>>>>>>>> then the >>>>>>>>>>>>>>> >>> > >>>>>> launcher needs to be setting them using the >>>>>>>>>>>>>>> available >>>>>>>>>>>>>>> platform >>>>>>>>>>>>>>> >>> APIs. >>>>>>>>>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as >>>>>>>>>>>>>>> evidenced by >>>>>>>>>>>>>>> the VM >>>>>>>>>>>>>>> >>> code for >>>>>>>>>>>>>>> >>> > >>>>>> this - due to the need to verify API >>>>>>>>>>>>>>> availability. >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>>>>>>>>> Thread.setName would >>>>>>>>>>>>>>> >>> have to go >>>>>>>>>>>>>>> >>> > >>>>>> through our CCC process I think. But a >>>>>>>>>>>>>>> change in >>>>>>>>>>>>>>> the launcher >>>>>>>>>>>>>>> >>> would >>>>>>>>>>>>>>> >>> > >>>>>> not. >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> Sorry. >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>> David >>>>>>>>>>>>>>> >>> > >>>>>> ----- >>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu >>>>>>>>>>>>>>> Apr 14 >>>>>>>>>>>>>>> 13:31:11 >>>>>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri >>>>>>>>>>>>>>> Apr 15 >>>>>>>>>>>>>>> 17:50:10 >>>>>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>>>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>>>>>>>>> >>> > >>>>>>> // Thread naming only supported for the >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>> >>> doesn't >>>>>>>>>>>>>>> >>> > >>>>>>> work >>>>>>>>>>>>>>> >>> > >>>>>>> for >>>>>>>>>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>>>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>>>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>>>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>>>>>>>>> >>> > >>>>>>> // we don't set the name of an attached >>>>>>>>>>>>>>> thread to avoid >>>>>>>>>>>>>>> >>> stepping >>>>>>>>>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>>>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>>>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>> David, >>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>>>>> this. I >>>>>>>>>>>>>>> don't like >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>>>>>>>>> initializing VM >>>>>>>>>>>>>>> (before >>>>>>>>>>>>>>> >>> > >>>>>>>>> calling >>>>>>>>>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>>>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>>>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>>>>>>>>> AttachCurrentThread(). >>>>>>>>>>>>>>> So we >>>>>>>>>>>>>>> >>> can't >>>>>>>>>>>>>>> >>> > >>>>>>>>> set >>>>>>>>>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> Right - I came to the same realization >>>>>>>>>>>>>>> earlier >>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> morning. >>>>>>>>>>>>>>> >>> Which, >>>>>>>>>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic >>>>>>>>>>>>>>> premise >>>>>>>>>>>>>>> here that >>>>>>>>>>>>>>> >>> we don't >>>>>>>>>>>>>>> >>> > >>>>>>>> set the name of threads not created by the >>>>>>>>>>>>>>> JVM. >>>>>>>>>>>>>>> The fact >>>>>>>>>>>>>>> >>> that the >>>>>>>>>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a >>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>> thread seems >>>>>>>>>>>>>>> >>> > >>>>>>>> accidental to me - so >>>>>>>>>>>>>>> JVM_SetNativeThreadName is >>>>>>>>>>>>>>> only >>>>>>>>>>>>>>> working by >>>>>>>>>>>>>>> >>> > >>>>>>>> accident for the initial attach, and can't be >>>>>>>>>>>>>>> used for the >>>>>>>>>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the thread >>>>>>>>>>>>>>> inconsistently >>>>>>>>>>>>>>> >>> named at >>>>>>>>>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the launcher >>>>>>>>>>>>>>> has >>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>> >>> treated like >>>>>>>>>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. >>>>>>>>>>>>>>> If it >>>>>>>>>>>>>>> wants to >>>>>>>>>>>>>>> name its >>>>>>>>>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, >>>>>>>>>>>>>>> but I >>>>>>>>>>>>>>> would not be >>>>>>>>>>>>>>> >>> exporting >>>>>>>>>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it would >>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>> use the OS >>>>>>>>>>>>>>> >>> > >>>>>>>> specific API's for that on a >>>>>>>>>>>>>>> platform-by-platform >>>>>>>>>>>>>>> basis. >>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> David >>>>>>>>>>>>>>> >>> > >>>>>>>> ----- >>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too similar >>>>>>>>>>>>>>> but >>>>>>>>>>>>>>> perform >>>>>>>>>>>>>>> >>> different >>>>>>>>>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>>>>>>>>> JVM_SetNativeThreadName >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the >>>>>>>>>>>>>>> current >>>>>>>>>>>>>>> thread, the >>>>>>>>>>>>>>> >>> second >>>>>>>>>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>>>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>>>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a >>>>>>>>>>>>>>> comment >>>>>>>>>>>>>>> somewhere >>>>>>>>>>>>>>> >>> about >>>>>>>>>>>>>>> >>> > >>>>>>>>>> what >>>>>>>>>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line 408 >>>>>>>>>>>>>>> casts to >>>>>>>>>>>>>>> (void*) >>>>>>>>>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>>>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>>>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>>>>> >>> used at >>>>>>>>>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>>>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if possible >>>>>>>>>>>>>>> keep >>>>>>>>>>>>>>> the cast >>>>>>>>>>>>>>> >>> on the >>>>>>>>>>>>>>> >>> > >>>>>>>>>> same >>>>>>>>>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>> time to >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>> >>> thread >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>>>>> then my >>>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>>> >>> should >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>>>>> in our >>>>>>>>>>>>>>> treatment of >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA b112, >>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>> confirmed >>>>>>>>>>>>>>> >>> native >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) >>>>>>>>>>>>>>> throws >>>>>>>>>>>>>>> Exception{ >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>>>>> this. I >>>>>>>>>>>>>>> don't like >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing Kumar's >>>>>>>>>>>>>>> comment. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa Suenaga >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa Suenaga >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> >>> name, and JLI >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to another >>>>>>>>>>>>>>> team so >>>>>>>>>>>>>>> >>> core-libs will >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in particular >>>>>>>>>>>>>>> Kumar) - >>>>>>>>>>>>>>> now cc'd. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java >>>>>>>>>>>>>>> upcall to >>>>>>>>>>>>>>> >>> Thread.setName >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> than exporting >>>>>>>>>>>>>>> JVM_SetNativeThreadName. No >>>>>>>>>>>>>>> hotspot changes >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed to use >>>>>>>>>>>>>>> Thread#setName() in >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread >>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not >>>>>>>>>>>>>>> alive, >>>>>>>>>>>>>>> which is >>>>>>>>>>>>>>> >>> why the >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>>>>>>>>> attached thread. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question which I >>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>> time to >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is considered a >>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>> >>> thread >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>>>>> then my >>>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>>> >>> should >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>>>>> in our >>>>>>>>>>>>>>> treatment of >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks about >>>>>>>>>>>>>>> this. I >>>>>>>>>>>>>>> don't like >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to provide a >>>>>>>>>>>>>>> function to set >>>>>>>>>>>>>>> >>> native >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original >>>>>>>>>>>>>>> thread as >>>>>>>>>>>>>>> well ... >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug >>>>>>>>>>>>>>> (sorry >>>>>>>>>>>>>>> have >>>>>>>>>>>>>>> been on >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher >>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>> correct >>>>>>>>>>>>>>> as we >>>>>>>>>>>>>>> >>> do not >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via JNI, >>>>>>>>>>>>>>> which >>>>>>>>>>>>>>> includes the >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa >>>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more >>>>>>>>>>>>>>> reviewer >>>>>>>>>>>>>>> :-) >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, Robbin Ehn >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, Yasumasa >>>>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin Ehn >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, Yasumasa >>>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin Ehn" >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>>: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 "Robbin Ehn" >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>> >>>>: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you >>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>> set it: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* >>>>>>>>>>>>>>> main_thread = >>>>>>>>>>>>>>> new >>>>>>>>>>>>>>> >>> JavaThread(); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this before >>>>>>>>>>>>>>> >>> set_active_handles >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I >>>>>>>>>>>>>>> missing >>>>>>>>>>>>>>> something? >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the >>>>>>>>>>>>>>> same >>>>>>>>>>>>>>> to thread >>>>>>>>>>>>>>> >>> name in >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in >>>>>>>>>>>>>>> Thread or >>>>>>>>>>>>>>> setName(). >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new thread in >>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>> app, >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main >>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>> already >>>>>>>>>>>>>>> >>> starte >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is >>>>>>>>>>>>>>> set in >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of >>>>>>>>>>>>>>> setting >>>>>>>>>>>>>>> thrrad name >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> something like >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>> Tue >>>>>>>>>>>>>>> >>> Mar 29 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>> Wed >>>>>>>>>>>>>>> >>> Mar 30 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial >>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>>>>>>>>> create_initial_thread(Handle >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>>>>>>>>> initial_thread_name = >>>>>>>>>>>>>>> >>> "main"; >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle klass >>>>>>>>>>>>>>> (THREAD, k); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle >>>>>>>>>>>>>>> thread_oop = >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>>> >>> thread); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue result(T_VOID); >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>>>>> thread_oop, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new webrev >>>>>>>>>>>>>>> later. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem to name >>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>> 'java' and >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to >>>>>>>>>>>>>>> me. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> process >>>>>>>>>>>>>>> (and >>>>>>>>>>>>>>> >>> thus >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is >>>>>>>>>>>>>>> 'main'. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> process >>>>>>>>>>>>>>> is not >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> set_native_thread_name() is >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> >>> JavaThread. So I >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for native >>>>>>>>>>>>>>> main >>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can change it >>>>>>>>>>>>>>> anyhow, since >>>>>>>>>>>>>>> >>> we want >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> name >>>>>>>>>>>>>>> might >>>>>>>>>>>>>>> >>> have >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in e.g. >>>>>>>>>>>>>>> /proc. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid >>>>>>>>>>>>>>> comm' >>>>>>>>>>>>>>> | head -4 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with >>>>>>>>>>>>>>> something >>>>>>>>>>>>>>> like >>>>>>>>>>>>>>> 'Java Main >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not >>>>>>>>>>>>>>> be a >>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>> >>> launcher - e.g. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI >>>>>>>>>>>>>>> application, >>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native >>>>>>>>>>>>>>> main >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> name, >>>>>>>>>>>>>>> >>> I think >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new >>>>>>>>>>>>>>> webrev? >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 PM, >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>> Suenaga wrote: >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux will >>>>>>>>>>>>>>> set >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> >>> name via >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread >>>>>>>>>>>>>>> does not >>>>>>>>>>>>>>> have it. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> name, >>>>>>>>>>>>>>> and main >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, main >>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> should have >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. >>>>>>>>>>>>>>> Could >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>> review it? >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access JPRT. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> > From mikael.vidstedt at oracle.com Tue Apr 26 17:49:02 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 26 Apr 2016 10:49:02 -0700 Subject: RFR(S): 8153890: Handle unsafe access error as an asynchronous exception In-Reply-To: <570C555D.8070307@oracle.com> References: <57083055.9070802@oracle.com> <570C42E9.5040005@oracle.com> <570C555D.8070307@oracle.com> Message-ID: <571FAA0E.4050503@oracle.com> I filed JDK-8154592 to cover handling the faulting accesses completely synchronously instead (much like NPEs), and I am withdrawing this RFR in favor of that. Cheers, Mikael [1] https://bugs.openjdk.java.net/browse/JDK-8154592 On 4/11/2016 6:54 PM, David Holmes wrote: > The light is starting to shine ... :) > > On 12/04/2016 10:35 AM, David Holmes wrote: >> Looking at the test ... >> >> On 9/04/2016 8:27 AM, Mikael Vidstedt wrote: >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153890 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8153890/webrev.01/hotspot/webrev/ >>> >>> >>> >>> >>> * Note: this is patch 1 in a set of 3 all aiming to clean up and unify >>> the unsafe memory getters/setters, along with the handling of unsafe >>> access errors. The other two issues are: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8153892 - Handle unsafe access >>> error directly in signal handler instead of going through a stub >>> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >>> getters/setters to use double-register variants >>> >>> >>> * Summary (copied from the bug description) >>> >>> In certain cases, such as accessing a region of a memory mapped file >>> which has been truncated on unix-style operating systems, a SIGBUS >>> signal will be raised and the VM will process it in the signal handler. >>> Currently, as part of the handling a flag is set on the thread >>> indicating that an error has occurred: >>> >>> _special_runtime_exit_condition = _async_unsafe_access_error; >>> >>> Eventually the VM will check the flag and throw an InternalError. >>> However, the flag is not always checked promptly, which means that the >>> time between the error and the time when the InternalError is thrown >>> can >>> be very long. >>> >>> In parallel with this, there is functionality in the VM to set pending >>> asynchronous exceptions on threads. These asynchronous exceptions are >>> checked/thrown more often. >>> >>> Instead of having two mechanisms for handling these types of >>> asynchronous events the unsafe access errors should be converted to use >>> the normal asynchronous exception mechanism. >>> >>> One of the reasons why this isn't already the case is that when the >>> SIGBUS signal is raised, the thread may not be in a place where it can >>> allocate an exception - there may not be a safepoint on the instruction >>> performing the memory access. The solution to this is to preallocate >>> the >>> InternalError exception at VM start up, and have the handler code >>> simply >>> use that exception instead. The only downside of this is that the >>> exception will not have a stack trace. The flip side of that is that >>> because of the unpredictability in when the async unsafe access >>> error is >>> actually thrown today it is likely that the stack trace in the >>> exception >>> doesn't actually reflect the place where the error actually occurred >>> anyway. >>> >>> * Testing >>> >>> In addition to the JPRT smoke tests a new test has been developed for >>> testing unsafe access errors, in particular accessing data in the >>> truncated portion of a memory mapped file using the Unsafe primitives. >>> The test can be found here: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >> >> Here: >> >> } else { >> r.run(); >> >> // The operation may have raised a pending async >> // exception, make sure it's actually thrown >> forcePendingAsyncExceptionProcessing(); >> } >> >> forcePendingAsyncExceptionProcessing should not be needed. There is no >> way we should be able to return to Java without the pending exception >> being thrown from r.run()! If we can then there is a serious bug >> somewhere. > > Ah! So now I think I see what the real bug is - it isn't timeliness it > is a correctness issue. It should be impossible to return from native > to Java without converting a pending "async error" into an actual > exception. But the native call stub calls > JavaThread::check_special_condition_for_native_trans, which in turn > calls: > > thread->check_and_handle_async_exceptions(false); > > which skips the unsafe-access-error check. And that is wrong if the > Unsafe methods are called as normal native methods. But we can't do > the unsafe-access-error check while we are in a "trans" state if it > will allocate. > > The existing code seems to assume that unsafe-access will not occur > via the normal native call path. Exactly how are these unsafe accesses > performed? > > David > ----- > >> Thanks, >> David >> >>> The plan is to push it together with the final patch (JDK-8150921). >>> Note >>> though that the test fails unless the other patches mentioned above are >>> also applied. >>> >>> I am also looking for to run additional testing on this before pushing, >>> but wanted to get some early feedback. >>> >>> Cheers, >>> Mikael >>> From mikael.vidstedt at oracle.com Tue Apr 26 18:35:58 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 26 Apr 2016 11:35:58 -0700 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> <570C417F.20600@oracle.com> Message-ID: <571FB50E.6090108@oracle.com> On 4/12/2016 2:15 AM, Thomas St?fe wrote: > Hi Mikael, David, > > On Tue, Apr 12, 2016 at 2:29 AM, David Holmes > wrote: > > On 11/04/2016 10:57 AM, David Holmes wrote: > > Hi Mikael, > > I think we need to be able to answer the question as to why > the stubbed > and stubless forms of this code exist to ensure that > converting all > platforms to the same form is appropriate. > > > The more I look at this the more the stubs make no sense :) AIII a > stub is generated when we need runtime code that may be different > to that which we could write directly for compiling at build time > - ie to use CPU specific features of the actual CPU. But I see > nothing here that suggests any such usage. > > So I agree with removing the stubs. > > I'm still going through this but my initial reaction is to > wonder why we > don't use the same form of handle_unsafe_access on all > platforms and > always pass in npc? (That seems to be the only difference in > code that > otherwise seems platform independent.) > > > Futher to this and Thomas's comments I think > handle_unsafe_access(thread, pc, npc) can be defined in shared > code (where? not sure). Further, if we always pass in npc then we > don't need to pass in pc as it is unused (seems unused in original > code too for sparc). > > > I agree. We commonized ucontext_set_pc for all Posix platforms, so we > can make a common function "handle_unsafe_access(thread, npc)" and > inside use os::Posix::ucontext_set_pc to modify the context. Then we > can get rid of the special handling in the signal handlers inside > os_aix_ppc.cpp and os_linux_ppc.cpp (for both the compiled and the > interpreted case). There is definitely room for unification and simplification here. Right now the signal handling code is, sadly, different on all the different platforms, despite the fact that in many cases it should be similar or the exact same. That said, as much as a refactoring/rewrite of the signal handler code is needed, it will very quickly turn into a much larger effort... In this specific case, it would probably make more sense to pass in the full context to the handle_unsafe_access method and have it do whatever it feels is necessary to update it. However, a lot of the signal handler code assumes that a "stub" variable gets set up and only at the end of the main signal handler function does the actual context get updated. Changing how that works only for this specific case is obviously not a good idea, which means it's back to the full scale refactoring and out of scope for the bug fix. So to me the fact that the method prototypes differ depending on the exact platform is just a reflection of how the contexts differ. In lack of the full context the handler method needs to take whatever parts of the context is needed to do it's job. I could of course change the handler method to only take a single "next_pc" argument, but to me that feels like putting a key part of the logic which handles the unsafe access (specifically, the part which calculates the next pc) in the wrong place - IMHO that should really be tightly coupled with the rest of the logic needed to handle an unsafe access (updating the thread state etc.), and hence I feel that it really belongs in the handle_unsafe_access method itself. Happy to hear your thoughts, but I hope we can agree that the suggested fix, even in its current state, is still significantly better than what is there now. Unless somebody has a better suggestion, I'm going to be moving the implementations of the handle_unsafe_access methods to sharedRuntime (instead of stubRoutines) and will send out a new webrev shortly. Cheers, Mikael > > > BTW I found this comment somewhat unfathomable (both now and in > original code): > > + // pc is the instruction which we must emulate > + // doing a no-op is fine: return garbage from the load > > but finally realized that it means that after the load that raised > the signal the native code proceeds normally but the value > apparently loaded is just garbage/arbitrary, and the only sign > something went wrong is the setting of the pending > unsafe-access-error bit. This would be a potential source of bugs > I think, except that when we hit the Java level, we throw the > exception and so never actually "return" the garbage value. But it > does mean we would have to be careful if calling the unsafe > routines from native code. > > > I admit I do not understand fully how the > _special_runtime_exit_condition flag is processed later, at least not > for all cases: If I have a java method A using sun.misc.unsafe, which > gets compiled, the sun.misc.unsafe intrinsic gets inlined into that > method. So, the whole method A gets marked as "has unsafe access"? So, > any SIGBUS happening inside this method - which may be larger than the > inlined sun.misc.unsafe call - will yield an InternalError? And when > is the flag checked if that method A is called from another java method B? > > Sorry if the questions are stupid, I am not a JIT expert, but I try to > understand how much can happen between the SIGBUS and the > InternalError getting thrown. No questions are stupid here. As you may have seen in the other thread, I filed JDK-8154592[1] to cover making the handling of the faults synchronous. Hope that helps. Cheers, Mikael [1] https://bugs.openjdk.java.net/browse/JDK-8154592 > > Thanks, Thomas > > Thanks, > David > > > Thanks, > David > > On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: > > > Please review: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ > > > > > * Note: this is patch 2 in a set of 3 all aiming to clean > up and unify > the unsafe memory getters/setters, along with the handling > of unsafe > access errors. The other two issues are: > > https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle > unsafe access > error as an asynchronous exception > https://bugs.openjdk.java.net/browse/JDK-8150921 - Update > Unsafe > getters/setters to use double-register variants > > > * Summary (copied from the bug description) > > > In certain cases, such as accessing a region of a memory > mapped file > which has been truncated on unix-style operating systems, > a SIGBUS > signal will be raised and the VM will process it in the > signal handler. > > How the signal is processed differs depending on the > operating system > and/or CPU architecture, with two major alternatives: > > * "stubless" > > Do the necessary thread state updates directly in the > signal handler, > and modify the context so that the signal handler returns > to the place > where the execution should continue > > * Using a stub > > Update the context so that when the signal handler returns > the thread > will continue execution in a generated stub, which in turn > will call > some native code in the VM to update the thread state and > figure out > where execution should continue. The stub will then jump > to that new > place. > > > It should be noted that the work of updating the thread > state is very > small - it's setting a flag or two in the thread > structure, and figures > out where the next instruction starts. It should also be > noted that the > generated stubs today are broken, because they do not > preserve all the > live registers over the call into the VM. There are two > ways to address > this: > > * Preserve all the necessary registers > > This would mean implementing, in macro assembly, the > necessary logic for > preserving all the live registers, including, but not > limited to, > floating point registers, flag registers, etc. It quickly > becomes > obvious that this platform specific and error prone. > > * Leverage the fact that the operating system already does > this as part > of the signal handling > > Do the necessary work in the signal handler instead, > removing the need > for the stub alltogether > > As mentioned, on some platforms the latter model is > already in use. It > is dramatically easier and all platforms should be updated > to do it the > same way. > > > * Testing > > Just as mentioned in the RFR for JDK-8153890, a new test > was developed > to test this code path: > > http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java > > > In fact, it was when running this test I found the > register preservation > issue. JPRT also passes. Much like JDK-8153890 I wanted to > get some > feedback on this before running additional tests. > > > Cheers, > Mikael > > From robbin.ehn at oracle.com Tue Apr 26 19:47:05 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 26 Apr 2016 21:47:05 +0200 Subject: RFR: 8154719: JvmtiBreakpoint rename method print() to print_on() In-Reply-To: References: <57176C38.3000109@oracle.com> <571F2B68.90803@oracle.com> <19009225-ff51-912d-ed98-3a86ddb7bfbb@oracle.com> Message-ID: <71598589-23d1-e3b5-59f9-a29a5e5c6c41@oracle.com> Thanks Coleen! /Robbin On 04/26/2016 04:28 PM, Coleen Phillimore wrote: > Agree, looks good. Thank you for making this change. > Coleen > > On 4/26/16 4:49 AM, Robbin Ehn wrote: >> Hi Serguei, >> >> Thanks! >> >> /Robbin >> >> On 04/26/2016 10:48 AM, serguei.spitsyn at oracle.com wrote: >>> Hi Robin, >>> >>> Looks good. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 4/20/16 04:47, Robbin Ehn wrote: >>>> Hi all, please review! >>>> >>>> print() method was changed in 8154041 to have outputStream argument, >>>> this renames print to print_on. >>>> Since JvmtiBreakpoint extends GrowableElement print_on already exists >>>> as a virtual const method, hence the const changes. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154719 >>>> Webrev: http://cr.openjdk.java.net/~rehn/8154719/webrev/ >>>> >>>> Tested with: >>>> >>>> #define TraceJVMTICalls false >>>> in hotspot/src/share/vm/prims/jvmtiEnv.cpp >>>> set to true with test-set nsk.jvmti.SetBreakpoint >>>> >>>> Thanks! >>>> >>>> /Robbin >>> > From david.holmes at oracle.com Tue Apr 26 23:23:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2016 09:23:29 +1000 Subject: RFR: JDK-8152690: main thread does not have native thread name In-Reply-To: <74485460-c558-0b56-191b-07b7830834b6@gmail.com> References: <56F3F90D.9010408@gmail.com> <5710BF7E.6090206@oracle.com> <5710EA86.6010400@gmail.com> <57116A9E.9070003@oracle.com> <5711CD48.7010403@gmail.com> <5711E587.4050805@oracle.com> <57120600.6090005@gmail.com> <5715BC65.3010302@oracle.com> <571635E6.40601@gmail.com> <5719C5C8.3020705@oracle.com> <571A14ED.10901@gmail.com> <571A381E.9050605@oracle.com> <571A4DE8.8060508@oracle.com> <571B7796.8030905@gmail.com> <571DAF8F.1080305@oracle.com> <571ECF60.4060703@oracle.com> <9111da15-1b9a-a522-c072-475494577cbc@gmail.com> <571EF995.3000109@oracle.com> <571F367B.3010200@oracle.com> <571F684B.9080501@oracle.! com> <571F796F.9010301@oracle.com> <74485460-c558-0b56-191b-07b7830834b6@gmail.com> Message-ID: <571FF871.3010801@oracle.com> On 27/04/2016 12:38 AM, Yasumasa Suenaga wrote: > Hi Kumar, David, > >> simply to set a name which seems to be useful only for folks trying to >> debug >> the VM ??? besides ps and few other OS related utils it >> has no visibility of value to the JRE or the JDK APIs. > > I want to check CPU time through ps command on Linux. > Usually, I get "ps -eLf" and nid in threaddump to check > which thread spends much CPU time. > > If I can get thread name from output of ps command, > I can check it rapidly. If it is the only unnamed thread in the java process then you can infer that it is the "main" thread in one of its two forms. The tid may also give you some indication it is the first thread created by the launcher. > So I want to set "main" name at least. Sorry, but as previously discussed leaving it at "main" after it becomes the DestroyJavaVM thread will be a source of confusion (and bug reports). David ----- > > Thanks, > > Yasumasa > > > On 2016/04/26 23:21, Kumar Srinivasan wrote: >> >> On 4/26/2016 6:08 AM, David Holmes wrote: >>> On 26/04/2016 10:54 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> For this issue, I think we can approach as following: >>>> >>>> >>>> 1. Export new JVM function to set native thread name >>>> It can avoid JNI call and can handle char* value. >>>> However this plan has been rejected. >>>> >>>> 2. Call uncaught exception handler from Launcher >>>> We have to clear (process) any pending exception before >>>> DetachCurrentThread() call. (not documented?) >>>> ------ >>>>> so note that we are potentially calling DetachCurrentThread with an >>>>> exception pending - which is prohibited by JNI** >>>> >>>>> **JNI spec needs to be modified here. >>>> ------ >>>> So we can process pending exception through uncaught >>>> exception handler. >>>> However, this plan has been rejected. >>>> >>>> 3. Do not set DestroyJavaVM name when exception is occurred >>>> It disrupts consistency for native thread name. >>>> >>>> 4. Attach to JVM to set native thread name for DestroyJavaVM >>>> It does not look good. >>>> >>>> >>>> If all of them are not accepted, I guess that it is difficult. >>>> Do you have any other idea? >>> >>> Sorry I don't. The basic idea of having the launcher set the native >>> thread name is fine, but the mechanism to do that has been >>> problematic. The "real" solution (ie one that other applications >>> hosting the jvm would need to use) is for the launcher to duplicate >>> the per-platform logic for os::set_native_thread_name - but that was >>> undesirable. Instead we have tried to avoid that by finding a way to >>> use whatever is already in the JVM - but adding a new JVM interface >>> to expose it directly is not ideal; and hooking into the >>> java.lang.Thread code to avoid that has run into these other >>> problems. I really don't want to take the logic for uncaught >>> exception handling that is in Thread::exit and duplicate it in the >>> launcher. >>> >>> The effort and disruption here really does not justify the "it would >>> be nice to set the native thread name for the main thread" objective. >>> >>> I never expected this to be as problematic as it has turned out. >> >> I agree with Holmes-san, I think this needlessly complicates >> the launcher, more than I would like!, ie simply to set a name >> which seems to be useful only for folks trying to debug >> the VM ??? besides ps and few other OS related utils it >> has no visibility of value to the JRE or the JDK APIs. >> >> Thanks >> >> Kumar >> >>> >>> Sorry. >>> >>> David >>> ----- >>> >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/04/26 18:35, David Holmes wrote: >>>>> On 26/04/2016 7:22 PM, Yasumasa Suenaga wrote: >>>>>> Hi David, >>>>>> >>>>>>> I thought about being able to save/restore the original pending >>>>>>> exception but could not see a simple way to restore it - ie just by >>>>>>> poking it back into the thread's pending exception field. The >>>>>>> problem >>>>>>> with using env->Throw is that it acts like the initial throwing >>>>>>> of the >>>>>>> exception and will have a number of side-effects that then get >>>>>>> doubled >>>>>>> up: >>>>>>> - logging statements (UL and Event logging) >>>>>>> - OOM counting >>>>>> >>>>>> Thanks, I understood. >>>>>> >>>>>>>>> so note that we are potentially calling DetachCurrentThread >>>>>>>>> with an >>>>>>>>> exception pending - which is prohibited by JNI**, but which we >>>>>>>>> actually rely on for desired operation as DetachCurrentThread >>>>>>>>> calls >>>>>>>>> thread->exit() which performs uncaught exception handling (ie it >>>>>>>>> prints the exception message and stacktrace) and then clears the >>>>>>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>>>>>> exceptions.) >>>>>> >>>>>> I think we can call uncaught exception handler before calling >>>>>> DestroyJavaVM(). >>>>>> I added it in new webrev for jdk: >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/hotspot/ >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.08/jdk/ >>>>>> >>>>>> DispatchUncaughtException() in java.c emulates uncaught exception >>>>>> handler >>>>>> call in JavaThread::exit(). >>>>>> I think this patch can provide the solution for our issue. >>>>>> >>>>>> Could you check it? >>>>> >>>>> Sorry - this is getting far too disruptive. I do not support changing >>>>> the way the main thread behaves upon completion, just because we want >>>>> to set a native thread name. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2016/04/26 14:16, David Holmes wrote: >>>>>>> On 26/04/2016 1:11 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi David, Kumar, >>>>>>>> >>>>>>>> I think that we should evacuate original exception before >>>>>>>> DestroyJavaVM >>>>>>>> thread name is set. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/hotspot/ >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.07/jdk/ >>>>>>>> >>>>>>>> I added it to LEAVE macro in new webrev. >>>>>>> >>>>>>> BTW: in the LEAVE macro, stylistically all the code should be in the >>>>>>> do { } while(false); loop. I overlooked that initially. >>>>>>> >>>>>>>> I tested it with following code. It works fine. >>>>>>>> >>>>>>>> ------------- >>>>>>>> public void main(String[] args){ >>>>>>>> throw new RuntimeException("test"); >>>>>>>> } >>>>>>>> ------------- >>>>>>>> >>>>>>>> What do you think about it? >>>>>>> >>>>>>> I thought about being able to save/restore the original pending >>>>>>> exception but could not see a simple way to restore it - ie just by >>>>>>> poking it back into the thread's pending exception field. The >>>>>>> problem >>>>>>> with using env->Throw is that it acts like the initial throwing >>>>>>> of the >>>>>>> exception and will have a number of side-effects that then get >>>>>>> doubled >>>>>>> up: >>>>>>> - logging statements (UL and Event logging) >>>>>>> - OOM counting >>>>>>> >>>>>>> I'm not sure whether that is acceptable or not >>>>>>> >>>>>>> That aside you should check if orig_throwable is non-null before >>>>>>> clearing to avoid an unnecessary JNI call. >>>>>>> >>>>>>> Also "Resume original exception" -> "Restore any original exception" >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2016/04/26 11:16, David Holmes wrote: >>>>>>>>> Hi Yasumasa, Kumar, >>>>>>>>> >>>>>>>>> Turns out this change breaks the behaviour of the launcher in the >>>>>>>>> case >>>>>>>>> that main() completes by throwing an exception. >>>>>>>>> >>>>>>>>> What we have in the launcher is: >>>>>>>>> >>>>>>>>> (*env)->CallStaticVoidMethod(env, mainClass, mainID, >>>>>>>>> mainArgs); >>>>>>>>> ret = (*env)->ExceptionOccurred(env) == NULL ? 0 : 1; >>>>>>>>> LEAVE(); >>>>>>>>> >>>>>>>>> where LEAVE would have expanded to: >>>>>>>>> >>>>>>>>> if ((*vm)->DetachCurrentThread(vm) != JNI_OK) { \ >>>>>>>>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>> ret = 1; \ >>>>>>>>> } \ >>>>>>>>> if (JNI_TRUE) { \ >>>>>>>>> (*vm)->DestroyJavaVM(vm); \ >>>>>>>>> return ret; \ >>>>>>>>> } \ >>>>>>>>> >>>>>>>>> so note that we are potentially calling DetachCurrentThread >>>>>>>>> with an >>>>>>>>> exception pending - which is prohibited by JNI**, but which we >>>>>>>>> actually rely on for desired operation as DetachCurrentThread >>>>>>>>> calls >>>>>>>>> thread->exit() which performs uncaught exception handling (ie it >>>>>>>>> prints the exception message and stacktrace) and then clears the >>>>>>>>> exception! (Hence DestroyJavaVM is not called with any pending >>>>>>>>> exceptions.) >>>>>>>>> >>>>>>>>> **JNI spec needs to be modified here. >>>>>>>>> >>>>>>>>> With the current change we have now inserted the following at the >>>>>>>>> start of LEAVE: >>>>>>>>> >>>>>>>>> SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>> if ((*env)->ExceptionOccurred(env)) { \ >>>>>>>>> (*env)->ExceptionClear(env); \ >>>>>>>>> } \ >>>>>>>>> >>>>>>>>> this has two unintended consequences: >>>>>>>>> >>>>>>>>> 1. SetNativeThreadName itself calls a number of JNI methods, >>>>>>>>> with the >>>>>>>>> exception pending - which is not permitted. So straight away >>>>>>>>> where we >>>>>>>>> have: >>>>>>>>> >>>>>>>>> NULL_CHECK(cls = FindBootStrapClass(env, "java/lang/Thread")); >>>>>>>>> >>>>>>>>> FindBootStrapClass calls JVM_FindClassFromBootLoader, which make >>>>>>>>> calls >>>>>>>>> using the VM's CHECK_NULL macro - which checks for a pending >>>>>>>>> exception >>>>>>>>> (which it finds) and returns NULL. So the jli NULL_CHECK macro >>>>>>>>> then >>>>>>>>> reports a JNI error: >>>>>>>>> >>>>>>>>> Error: A JNI error has occurred, please check your installation >>>>>>>>> and >>>>>>>>> try again >>>>>>>>> >>>>>>>>> >>>>>>>>> 2. There is no longer an exception from main() for >>>>>>>>> DetachCurrentThread >>>>>>>>> to report, so we exit with a return code of 1 as required, but >>>>>>>>> don't >>>>>>>>> report the exception message/stacktrace. >>>>>>>>> >>>>>>>>> I don't see a reasonable solution for this other than >>>>>>>>> abandoning the >>>>>>>>> attempt to change the name from "main" to "DestroyJavaVM" - >>>>>>>>> which if >>>>>>>>> we can't do, I question the utility of setting the name in the >>>>>>>>> first >>>>>>>>> place (while it might be useful in some circumstances [when >>>>>>>>> main() is >>>>>>>>> running] it will cause confusion in others [when main() has >>>>>>>>> exited]). >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 25/04/2016 3:47 PM, David Holmes wrote: >>>>>>>>>> Looks good to me. >>>>>>>>>> >>>>>>>>>> I'll sponsor this "tomorrow". >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 23/04/2016 11:24 PM, Yasumasa Suenaga wrote: >>>>>>>>>>> Hi Kumar, >>>>>>>>>>> >>>>>>>>>>> Thank you for your comment! >>>>>>>>>>> I've fixed them and uploaded new webrev. Could you review again? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/hotspot/ >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.06/jdk/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2016/04/23 1:14, Kumar Srinivasan wrote: >>>>>>>>>>>> >>>>>>>>>>>> Also a couple of minor suggestions: >>>>>>>>>>>> >>>>>>>>>>>> - * Set native thread name as possible. >>>>>>>>>>>> + * Set native thread name if possible. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> + /* >>>>>>>>>>>> - * We can clear pending exception because exception >>>>>>>>>>>> at this >>>>>>>>>>>> point >>>>>>>>>>>> - * is not critical. >>>>>>>>>>>> + */ >>>>>>>>>>>> >>>>>>>>>>>> + /* >>>>>>>>>>>> + * Clear non critical pending exceptions at this point. >>>>>>>>>>>> + */ >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Kumar >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> This is in the wrong place: >>>>>>>>>>>>> >>>>>>>>>>>>> 1715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>>>>> 1716 /* >>>>>>>>>>>>> 1717 * We can clear pending exception because >>>>>>>>>>>>> exception at >>>>>>>>>>>>> this point >>>>>>>>>>>>> 1718 * is not critical. >>>>>>>>>>>>> 1719 */ >>>>>>>>>>>>> 1720 (*env)->ExceptionClear(env); >>>>>>>>>>>>> 1721 } >>>>>>>>>>>>> >>>>>>>>>>>>> This above needs to be after >>>>>>>>>>>>> 391 SetNativeThreadName(env, "main"); >>>>>>>>>>>>> 392 >>>>>>>>>>>>> >>>>>>>>>>>>> Here is why, supposing 1704 through 1711, returns a NULL, >>>>>>>>>>>>> but have also encountered an exception. In which case >>>>>>>>>>>>> the method SetNativeThreadName will return to the caller, as >>>>>>>>>>>>> if nothing has happened, because NULL_CHECK simply checks for >>>>>>>>>>>>> NULL >>>>>>>>>>>>> and returns to the caller. This will cause the caller to enter >>>>>>>>>>>>> the VM with exceptions. >>>>>>>>>>>>> >>>>>>>>>>>>> Kumar >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 4/22/2016 5:11 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>>>>>> ignore >>>>>>>>>>>>>>> it. Either way we have to clear the exception before >>>>>>>>>>>>>>> continuing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've fixed it in new webrev: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/hotspot/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.05/jdk/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016/04/22 15:33, David Holmes wrote: >>>>>>>>>>>>>>> On 22/04/2016 1:36 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have uploaded webrev.04 as below. >>>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > - hotspot: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Looks fine. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > - jdk: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As per private email (but repeated here on the record) in >>>>>>>>>>>>>>> java.c: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 715 if ((*env)->ExceptionOccurred(env)) { >>>>>>>>>>>>>>> 1716 JLI_ReportExceptionDescription(env); >>>>>>>>>>>>>>> 1717 } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't think we need to report the exception, but can just >>>>>>>>>>>>>>> ignore >>>>>>>>>>>>>>> it. Either way we have to clear the exception before >>>>>>>>>>>>>>> continuing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2016/04/19 22:43 "Yasumasa Suenaga" >>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Hi David, >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Thank you for your comment. >>>>>>>>>>>>>>>> > I uploaded new webrev. Could you review again? >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > - hotspot: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/hotspot/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > - jdk: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.04/jdk/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >> That aside I'm not sure why you do this so late in the >>>>>>>>>>>>>>>> process, I >>>>>>>>>>>>>>>> would have done it immediately after here: >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > I think that native thread name ("main") should be >>>>>>>>>>>>>>>> set just >>>>>>>>>>>>>>>> before >>>>>>>>>>>>>>>> > main method call. >>>>>>>>>>>>>>>> > However, main thread is already started, so I moved it >>>>>>>>>>>>>>>> as you >>>>>>>>>>>>>>>> suggested. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >> One thing I dislike about the current structure is >>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>> go from char* to java.lang.String to call setNativeName >>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> calls >>>>>>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back >>>>>>>>>>>>>>>> to a >>>>>>>>>>>>>>>> char* ! >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > SoI proposed to export new JVM function to set native >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> name with >>>>>>>>>>>>>>>> > const char *. >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Thanks, >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > Yasumasa >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > On 2016/04/19 14:04, David Holmes wrote: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Hi Yasumasa, >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Thanks for persevering with this to get it into the >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> form. >>>>>>>>>>>>>>>> Sorry I haven't been able to do a detailed review until >>>>>>>>>>>>>>>> now. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> On 19/04/2016 9:28 AM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Hi Gerard, >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> 2016/04/19 3:14 "Gerard Ziemski" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>> > hi Yasumasa, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>> > Nice work. I have 2 questions: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>> > ======== >>>>>>>>>>>>>>>> >>> > File: java.c >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>> > #1 Shouldn?t we be checking for >>>>>>>>>>>>>>>> ?(*env)->ExceptionOccurred(env)? >>>>>>>>>>>>>>>> >>> after every single JNI call? In this example >>>>>>>>>>>>>>>> instead of >>>>>>>>>>>>>>>> NULL_CHECK, >>>>>>>>>>>>>>>> >>> should we be using CHECK_EXCEPTION_NULL_LEAVE macro? >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> It is not critical if we encounter error at JNI >>>>>>>>>>>>>>>> function >>>>>>>>>>>>>>>> call >>>>>>>>>>>>>>>> because >>>>>>>>>>>>>>>> >>> we cannot set native thread name only. >>>>>>>>>>>>>>>> >>> So I think that we do not need to leave from launcher >>>>>>>>>>>>>>>> process. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> I agree we do not need to abort if an exception occurs >>>>>>>>>>>>>>>> (and in >>>>>>>>>>>>>>>> fact >>>>>>>>>>>>>>>> I don't think an exception is even possible from this >>>>>>>>>>>>>>>> code), >>>>>>>>>>>>>>>> but we >>>>>>>>>>>>>>>> should ensure any pending exception is cleared before any >>>>>>>>>>>>>>>> futher JNI >>>>>>>>>>>>>>>> calls might be made. Note that NULL_CHECK is already used >>>>>>>>>>>>>>>> extensively >>>>>>>>>>>>>>>> throughout the launcher code - so if this usage is wrong >>>>>>>>>>>>>>>> then it >>>>>>>>>>>>>>>> is all >>>>>>>>>>>>>>>> wrong! More on this code below ... >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Other comments: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> hotspot/src/share/vm/prims/jvm.cpp >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Please add a comment to the method now that you removed >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> internal >>>>>>>>>>>>>>>> comment: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> // Sets the native thread name for a JavaThread. If >>>>>>>>>>>>>>>> specifically >>>>>>>>>>>>>>>> >> // requested JNI-attached threads can also have their >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> name set; >>>>>>>>>>>>>>>> >> // otherwise we do not modify JNI-attached threads as >>>>>>>>>>>>>>>> it may >>>>>>>>>>>>>>>> interfere >>>>>>>>>>>>>>>> >> // with the application that created them. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> jdk/src/java.base/share/classes/java/lang/Thread.java >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Please add the following comments: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> + // Don't modify JNI-attached threads >>>>>>>>>>>>>>>> >> setNativeName(name, false); >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> + // May be called directly via JNI or reflection (when >>>>>>>>>>>>>>>> permitted) to >>>>>>>>>>>>>>>> >> + // allow JNI-attached threads to set their native >>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>> >> private native void setNativeName(String name, >>>>>>>>>>>>>>>> boolean >>>>>>>>>>>>>>>> allowAttachedThread); >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> --- >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> jd/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> 328 #define LEAVE() \ >>>>>>>>>>>>>>>> >> 329 SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> I was going to suggest this be set later, but >>>>>>>>>>>>>>>> realized we >>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>> attached to do this and that happens inside >>>>>>>>>>>>>>>> DestroyJavaVM. :) >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> + /* Set native thread name. */ >>>>>>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> The comment is redundant given the name of the method. >>>>>>>>>>>>>>>> That >>>>>>>>>>>>>>>> aside >>>>>>>>>>>>>>>> I'm not sure why you do this so late in the process, I >>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>> it immediately after here: >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> 386 if (!InitializeJVM(&vm, &env, &ifn)) { >>>>>>>>>>>>>>>> >> 387 JLI_ReportErrorMessage(JVM_ERROR1); >>>>>>>>>>>>>>>> >> 388 exit(1); >>>>>>>>>>>>>>>> >> 389 } >>>>>>>>>>>>>>>> >> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> + /** >>>>>>>>>>>>>>>> >> + * Set native thread name as possible. >>>>>>>>>>>>>>>> >> + */ >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Other than the as->if change I'm unclear where the >>>>>>>>>>>>>>>> "possible" >>>>>>>>>>>>>>>> bit >>>>>>>>>>>>>>>> comes into play - why would it not be possible? >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> 1705 NULL_CHECK(cls = FindBootStrapClass(env, >>>>>>>>>>>>>>>> "java/lang/Thread")); >>>>>>>>>>>>>>>> >> 1706 NULL_CHECK(currentThreadID = >>>>>>>>>>>>>>>> (*env)->GetStaticMethodID(env, >>>>>>>>>>>>>>>> cls, >>>>>>>>>>>>>>>> >> 1707 "currentThread", >>>>>>>>>>>>>>>> "()Ljava/lang/Thread;")); >>>>>>>>>>>>>>>> >> 1708 NULL_CHECK(currentThread = >>>>>>>>>>>>>>>> (*env)->CallStaticObjectMethod(env, cls, >>>>>>>>>>>>>>>> >> 1709 currentThreadID)); >>>>>>>>>>>>>>>> >> 1710 NULL_CHECK(setNativeNameID = >>>>>>>>>>>>>>>> (*env)->GetMethodID(env, >>>>>>>>>>>>>>>> cls, >>>>>>>>>>>>>>>> >> 1711 "setNativeName", >>>>>>>>>>>>>>>> "(Ljava/lang/String;Z)V")); >>>>>>>>>>>>>>>> >> 1712 NULL_CHECK(nameString = >>>>>>>>>>>>>>>> (*env)->NewStringUTF(env, >>>>>>>>>>>>>>>> name)); >>>>>>>>>>>>>>>> >> 1713 (*env)->CallVoidMethod(env, currentThread, >>>>>>>>>>>>>>>> setNativeNameID, >>>>>>>>>>>>>>>> >> 1714 nameString, JNI_TRUE); >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> As above NULL_CHECK is fine here, but we should >>>>>>>>>>>>>>>> check for >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> clear >>>>>>>>>>>>>>>> any pending exception after CallVoidMethod. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> One thing I dislike about the current structure is >>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>> go from char* to java.lang.String to call setNativeName >>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> calls >>>>>>>>>>>>>>>> JVM_SetNativeThreadName which converts the j.l.String back >>>>>>>>>>>>>>>> to a >>>>>>>>>>>>>>>> char* ! >>>>>>>>>>>>>>>> Overall I wonder about the affect on startup cost. But if >>>>>>>>>>>>>>>> there >>>>>>>>>>>>>>>> is an >>>>>>>>>>>>>>>> issue we can revisit this. >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>> >> David >>>>>>>>>>>>>>>> >> ----- >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > #2 Should the comment for ?SetNativeThreadName? be >>>>>>>>>>>>>>>> ?Set >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> >>> name if possible.? not "Set native thread name as >>>>>>>>>>>>>>>> possible.?? >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Sorry for my bad English :-) >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Thanks, >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> Yasumasa >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>> > cheers >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>> > > On Apr 16, 2016, at 4:29 AM, Yasumasa Suenaga >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > Hi David, >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > I uploaded new webrev: >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > - hotspot: >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/hotspot/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > - jdk: >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.03/jdk/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > >> it won't work unless you change the semantics of >>>>>>>>>>>>>>>> setName so I'm >>>>>>>>>>>>>>>> >>> not sure what you were thinking here. To take >>>>>>>>>>>>>>>> advantage >>>>>>>>>>>>>>>> of an >>>>>>>>>>>>>>>> arg >>>>>>>>>>>>>>>> taking >>>>>>>>>>>>>>>> >>> JVM_SetNativThreadName you would need to call it >>>>>>>>>>>>>>>> directly as >>>>>>>>>>>>>>>> no Java >>>>>>>>>>>>>>>> >>> code will call it . ??? >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > I added a flag for setting native thread name to >>>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>> >>> > > This change can set native thread name if main >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> changes to >>>>>>>>>>>>>>>> >>> JNI-attached thread. >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > Thanks, >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > Yasumasa >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > >>>>>>>>>>>>>>>> >>> > > On 2016/04/16 16:11, David Holmes wrote: >>>>>>>>>>>>>>>> >>> > >> On 16/04/2016 3:27 PM, Yasumasa Suenaga wrote: >>>>>>>>>>>>>>>> >>> > >>> Hi David, >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>>>>>> could be >>>>>>>>>>>>>>>> considered a >>>>>>>>>>>>>>>> >>> > >>>> regression that setName stops setting the >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> main, even >>>>>>>>>>>>>>>> >>> > >>>> though we never really intended it to work >>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>> first place. >>>>>>>>>>>>>>>> >>> :( Such >>>>>>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> I understood. >>>>>>>>>>>>>>>> >>> > >>> Can I send CCC request? >>>>>>>>>>>>>>>> >>> > >>> (I'm jdk 9 commiter, but I'm not employee at >>>>>>>>>>>>>>>> Oracle.) >>>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>>> >>> > >> Sorry you can't file a CCC request, you would >>>>>>>>>>>>>>>> need a >>>>>>>>>>>>>>>> sponsor for >>>>>>>>>>>>>>>> >>> that. But at this stage I don't think I agree with the >>>>>>>>>>>>>>>> proposed change >>>>>>>>>>>>>>>> >>> because of the change in behaviour - there's no way to >>>>>>>>>>>>>>>> restore the >>>>>>>>>>>>>>>> >>> "broken" behaviour. >>>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>>> >>> > >>> I want to continue to discuss about it on >>>>>>>>>>>>>>>> JDK-8154331 >>>>>>>>>>>>>>>> [1]. >>>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>>> >>> > >> Okay we can do that. >>>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>>> Further, we expect the launcher to use the >>>>>>>>>>>>>>>> supported >>>>>>>>>>>>>>>> JNI >>>>>>>>>>>>>>>> >>> interface (as >>>>>>>>>>>>>>>> >>> > >>>> other processes would), not the internal JVM >>>>>>>>>>>>>>>> interface that >>>>>>>>>>>>>>>> >>> exists for >>>>>>>>>>>>>>>> >>> > >>>> the JDK sources to communicate with the JVM. >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> I think that we do not use JVM interface if we >>>>>>>>>>>>>>>> add new >>>>>>>>>>>>>>>> method in >>>>>>>>>>>>>>>> >>> > >>> LauncherHelper as below: >>>>>>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>> --- >>>>>>>>>>>>>>>> a/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>> Wed Apr 13 14:19:30 2016 +0000 >>>>>>>>>>>>>>>> >>> > >>> +++ >>>>>>>>>>>>>>>> b/src/java.base/share/classes/sun/launcher/LauncherHelper.java >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>> Sat Apr 16 11:25:53 2016 +0900 >>>>>>>>>>>>>>>> >>> > >>> @@ -960,4 +960,8 @@ >>>>>>>>>>>>>>>> >>> > >>> else >>>>>>>>>>>>>>>> >>> > >>> return md.toNameAndVersion() + >>>>>>>>>>>>>>>> " (" >>>>>>>>>>>>>>>> + loc >>>>>>>>>>>>>>>> + ")"; >>>>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>>>> >>> > >>> + static void setNativeThreadName(String >>>>>>>>>>>>>>>> name) { >>>>>>>>>>>>>>>> >>> > >>> + Thread.currentThread().setName(name); >>>>>>>>>>>>>>>> >>> > >>> + } >>>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>>> >>> > >> You could also make that call via JNI >>>>>>>>>>>>>>>> directly, so >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> sure the >>>>>>>>>>>>>>>> >>> helper adds much here. But it won't work unless you >>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> semantics >>>>>>>>>>>>>>>> >>> of setName so I'm not sure what you were thinking >>>>>>>>>>>>>>>> here. To >>>>>>>>>>>>>>>> take >>>>>>>>>>>>>>>> >>> advantage of an arg taking JVM_SetNativThreadName you >>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>> need to >>>>>>>>>>>>>>>> call >>>>>>>>>>>>>>>> >>> it directly as no Java code will call it . ??? >>>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>>> >>> > >> David >>>>>>>>>>>>>>>> >>> > >> ----- >>>>>>>>>>>>>>>> >>> > >> >>>>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>>>> >>> > >>> diff -r f02139a1ac84 >>>>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>>>> >>> > >>> --- a/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>>>> Wed >>>>>>>>>>>>>>>> Apr 13 >>>>>>>>>>>>>>>> 14:19:30 >>>>>>>>>>>>>>>> >>> > >>> 2016 +0000 >>>>>>>>>>>>>>>> >>> > >>> +++ b/src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>>>> Sat >>>>>>>>>>>>>>>> Apr 16 >>>>>>>>>>>>>>>> 11:25:53 >>>>>>>>>>>>>>>> >>> > >>> 2016 +0900 >>>>>>>>>>>>>>>> >>> > >>> @@ -125,6 +125,7 @@ >>>>>>>>>>>>>>>> >>> > >>> static void PrintUsage(JNIEnv* env, jboolean >>>>>>>>>>>>>>>> doXUsage); >>>>>>>>>>>>>>>> >>> > >>> static void ShowSettings(JNIEnv* env, char >>>>>>>>>>>>>>>> *optString); >>>>>>>>>>>>>>>> >>> > >>> static void ListModules(JNIEnv* env, char >>>>>>>>>>>>>>>> *optString); >>>>>>>>>>>>>>>> >>> > >>> +static void SetNativeThreadName(JNIEnv* >>>>>>>>>>>>>>>> env, char >>>>>>>>>>>>>>>> *name); >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> static void SetPaths(int argc, char **argv); >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> @@ -325,6 +326,7 @@ >>>>>>>>>>>>>>>> >>> > >>> * mainThread.isAlive() to work as expected. >>>>>>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>>>>>> >>> > >>> #define LEAVE() \ >>>>>>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "DestroyJavaVM"); \ >>>>>>>>>>>>>>>> >>> > >>> do { \ >>>>>>>>>>>>>>>> >>> > >>> if ((*vm)->DetachCurrentThread(vm) != >>>>>>>>>>>>>>>> JNI_OK) >>>>>>>>>>>>>>>> { \ >>>>>>>>>>>>>>>> >>> > >>> JLI_ReportErrorMessage(JVM_ERROR2); \ >>>>>>>>>>>>>>>> >>> > >>> @@ -488,6 +490,9 @@ >>>>>>>>>>>>>>>> >>> > >>> mainArgs = CreateApplicationArgs(env, argv, >>>>>>>>>>>>>>>> argc); >>>>>>>>>>>>>>>> >>> > >>> CHECK_EXCEPTION_NULL_LEAVE(mainArgs); >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> + /* Set native thread name. */ >>>>>>>>>>>>>>>> >>> > >>> + SetNativeThreadName(env, "main"); >>>>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>>>> >>> > >>> /* Invoke main method. */ >>>>>>>>>>>>>>>> >>> > >>> (*env)->CallStaticVoidMethod(env, mainClass, >>>>>>>>>>>>>>>> mainID, >>>>>>>>>>>>>>>> mainArgs); >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> @@ -1686,6 +1691,22 @@ >>>>>>>>>>>>>>>> >>> > >>> joptString); >>>>>>>>>>>>>>>> >>> > >>> } >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> +/** >>>>>>>>>>>>>>>> >>> > >>> + * Set native thread name as possible. >>>>>>>>>>>>>>>> >>> > >>> + */ >>>>>>>>>>>>>>>> >>> > >>> +static void >>>>>>>>>>>>>>>> >>> > >>> +SetNativeThreadName(JNIEnv *env, char *name) >>>>>>>>>>>>>>>> >>> > >>> +{ >>>>>>>>>>>>>>>> >>> > >>> + jmethodID setNativeThreadNameID; >>>>>>>>>>>>>>>> >>> > >>> + jstring nameString; >>>>>>>>>>>>>>>> >>> > >>> + jclass cls = GetLauncherHelperClass(env); >>>>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(cls); >>>>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(setNativeThreadNameID = >>>>>>>>>>>>>>>> >>> (*env)->GetStaticMethodID(env, cls, >>>>>>>>>>>>>>>> >>> > >>> + "setNativeThreadName", >>>>>>>>>>>>>>>> "(Ljava/lang/String;)V")); >>>>>>>>>>>>>>>> >>> > >>> + NULL_CHECK(nameString = >>>>>>>>>>>>>>>> (*env)->NewStringUTF(env, >>>>>>>>>>>>>>>> name)); >>>>>>>>>>>>>>>> >>> > >>> + (*env)->CallStaticVoidMethod(env, cls, >>>>>>>>>>>>>>>> setNativeThreadNameID, >>>>>>>>>>>>>>>> >>> > >>> nameString); >>>>>>>>>>>>>>>> >>> > >>> +} >>>>>>>>>>>>>>>> >>> > >>> + >>>>>>>>>>>>>>>> >>> > >>> /* >>>>>>>>>>>>>>>> >>> > >>> * Prints default usage or the Xusage message, >>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>> >>> > >>> sun.launcher.LauncherHelper.java >>>>>>>>>>>>>>>> >>> > >>> */ >>>>>>>>>>>>>>>> >>> > >>> ---------------- >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> So I want to add new arg to >>>>>>>>>>>>>>>> JVM_SetNativeThreadName(). >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>>> However this is still a change to the exported >>>>>>>>>>>>>>>> JVM >>>>>>>>>>>>>>>> interface and so >>>>>>>>>>>>>>>> >>> > >>>> has to be approved. >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> Do you mean that this change needs CCC? >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> Thanks, >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> [1] >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019034.html >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> >>>>>>>>>>>>>>>> >>> > >>> On 2016/04/16 7:26, David Holmes wrote: >>>>>>>>>>>>>>>> >>> > >>>> On 15/04/2016 11:20 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>> Hi David, >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment >>>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = >>>>>>>>>>>>>>>> false); // >>>>>>>>>>>>>>>> for main >>>>>>>>>>>>>>>> >>> thread and >>>>>>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> I filed it to JBS as JDK-8154331. >>>>>>>>>>>>>>>> >>> > >>>>> I will send review request to >>>>>>>>>>>>>>>> hotspot-runtime-dev. >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>>>>>> behaviour by >>>>>>>>>>>>>>>> itself as >>>>>>>>>>>>>>>> >>> setName >>>>>>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for >>>>>>>>>>>>>>>> the main >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> I know. >>>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>>> >>> > >>>> That change in behaviour may be a problem, it >>>>>>>>>>>>>>>> could be >>>>>>>>>>>>>>>> considered a >>>>>>>>>>>>>>>> >>> > >>>> regression that setName stops setting the >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> main, even >>>>>>>>>>>>>>>> >>> > >>>> though we never really intended it to work >>>>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>> first place. >>>>>>>>>>>>>>>> >>> :( Such >>>>>>>>>>>>>>>> >>> > >>>> a change needs to go through CCC. >>>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>>> >>> > >>>>> I checked changeset history. >>>>>>>>>>>>>>>> >>> > >>>>> JVM_SetNativeThreadName() was introduced in >>>>>>>>>>>>>>>> JDK-7098194, >>>>>>>>>>>>>>>> and it is >>>>>>>>>>>>>>>> >>> > >>>>> backported JDK 8. >>>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>>> >>> > >>>> Yes this all came in as part of the OSX >>>>>>>>>>>>>>>> port in >>>>>>>>>>>>>>>> 7u2. >>>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>>> >>> > >>>>> However, this function seems to be called >>>>>>>>>>>>>>>> from >>>>>>>>>>>>>>>> >>> Thread#setNativeName() >>>>>>>>>>>>>>>> >>> > >>>>> only. >>>>>>>>>>>>>>>> >>> > >>>>> In addition, Thread#setNativeName() is >>>>>>>>>>>>>>>> private >>>>>>>>>>>>>>>> method. >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> Thus I think that we can add an argument to >>>>>>>>>>>>>>>> >>> JVM_SetNativeThreadName() >>>>>>>>>>>>>>>> >>> > >>>>> for force setting. >>>>>>>>>>>>>>>> >>> > >>>>> (e.g. "bool forced") >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> It makes a change of JVM API. >>>>>>>>>>>>>>>> >>> > >>>>> However, this function is NOT public, so I >>>>>>>>>>>>>>>> think we >>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> add one >>>>>>>>>>>>>>>> >>> more >>>>>>>>>>>>>>>> >>> > >>>>> argument. >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> What do you think about this? >>>>>>>>>>>>>>>> >>> > >>>>> If it is accepted, we can set native >>>>>>>>>>>>>>>> thread name >>>>>>>>>>>>>>>> from Java >>>>>>>>>>>>>>>> >>> launcher. >>>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>>> >>> > >>>> The private/public aspect of the Java API >>>>>>>>>>>>>>>> is not >>>>>>>>>>>>>>>> really at >>>>>>>>>>>>>>>> >>> issue. Yes >>>>>>>>>>>>>>>> >>> > >>>> we would add another arg to the JVM >>>>>>>>>>>>>>>> function to >>>>>>>>>>>>>>>> allow >>>>>>>>>>>>>>>> it to >>>>>>>>>>>>>>>> apply to >>>>>>>>>>>>>>>> >>> > >>>> JNI-attached threads as well (I'd prefer >>>>>>>>>>>>>>>> the arg >>>>>>>>>>>>>>>> reflect that >>>>>>>>>>>>>>>> >>> not just >>>>>>>>>>>>>>>> >>> > >>>> "force"). However this is still a change to >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> exported JVM >>>>>>>>>>>>>>>> >>> interface >>>>>>>>>>>>>>>> >>> > >>>> and so has to be approved. Further, we >>>>>>>>>>>>>>>> expect the >>>>>>>>>>>>>>>> launcher to >>>>>>>>>>>>>>>> >>> use the >>>>>>>>>>>>>>>> >>> > >>>> supported JNI interface (as other processes >>>>>>>>>>>>>>>> would), >>>>>>>>>>>>>>>> not the >>>>>>>>>>>>>>>> internal >>>>>>>>>>>>>>>> >>> > >>>> JVM interface that exists for the JDK >>>>>>>>>>>>>>>> sources to >>>>>>>>>>>>>>>> communicate >>>>>>>>>>>>>>>> >>> with the >>>>>>>>>>>>>>>> >>> > >>>> JVM. >>>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>>> >>> > >>>> David >>>>>>>>>>>>>>>> >>> > >>>> ----- >>>>>>>>>>>>>>>> >>> > >>>> >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> >>>>>>>>>>>>>>>> >>> > >>>>> On 2016/04/15 19:16, David Holmes wrote: >>>>>>>>>>>>>>>> >>> > >>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> On 15/04/2016 6:53 PM, Yasumasa Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>> Hi David, >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> The fact that the "main" thread is not >>>>>>>>>>>>>>>> tagged as >>>>>>>>>>>>>>>> being a >>>>>>>>>>>>>>>> >>> JNI-attached >>>>>>>>>>>>>>>> >>> > >>>>>>>> thread seems accidental to me >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> Should I file it to JBS? >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> I think it is a bug based on the comment >>>>>>>>>>>>>>>> here: >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> JavaThread(bool is_attaching_via_jni = >>>>>>>>>>>>>>>> false); // >>>>>>>>>>>>>>>> for main >>>>>>>>>>>>>>>> >>> thread and >>>>>>>>>>>>>>>> >>> > >>>>>> JNI attached threads >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> Though that will introduce a change in >>>>>>>>>>>>>>>> behaviour by >>>>>>>>>>>>>>>> itself as >>>>>>>>>>>>>>>> >>> setName >>>>>>>>>>>>>>>> >>> > >>>>>> will no longer set the native name for >>>>>>>>>>>>>>>> the main >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> I think that we can fix as below: >>>>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>>>> >>> > >>>>>>> diff -r 52aa0ee93b32 >>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>> Apr 14 >>>>>>>>>>>>>>>> 13:31:11 >>>>>>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/runtime/thread.cpp Fri >>>>>>>>>>>>>>>> Apr 15 >>>>>>>>>>>>>>>> 17:50:10 >>>>>>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>>>>>> >>> > >>>>>>> @@ -3592,7 +3592,7 @@ >>>>>>>>>>>>>>>> >>> > >>>>>>> #endif // INCLUDE_JVMCI >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> // Attach the main thread to this os >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> >>> > >>>>>>> - JavaThread* main_thread = new >>>>>>>>>>>>>>>> JavaThread(); >>>>>>>>>>>>>>>> >>> > >>>>>>> + JavaThread* main_thread = new >>>>>>>>>>>>>>>> JavaThread(true); >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>> >>> > >>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>> >>> > >>>>>>> // must do this before >>>>>>>>>>>>>>>> set_active_handles >>>>>>>>>>>>>>>> >>> > >>>>>>> @@ -3776,6 +3776,9 @@ >>>>>>>>>>>>>>>> >>> > >>>>>>> // Notify JVMTI agents that VM >>>>>>>>>>>>>>>> initialization >>>>>>>>>>>>>>>> is complete >>>>>>>>>>>>>>>> >>> - nop if >>>>>>>>>>>>>>>> >>> > >>>>>>> no agents. >>>>>>>>>>>>>>>> >>> > >>>>>>> JvmtiExport::post_vm_initialized(); >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> + // Change attach status to "attached" >>>>>>>>>>>>>>>> >>> > >>>>>>> + >>>>>>>>>>>>>>>> main_thread->set_done_attaching_via_jni(); >>>>>>>>>>>>>>>> >>> > >>>>>>> + >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> I think we can do this straight after the >>>>>>>>>>>>>>>> JavaThread >>>>>>>>>>>>>>>> constructor. >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> if (TRACE_START() != JNI_OK) { >>>>>>>>>>>>>>>> >>> > >>>>>>> vm_exit_during_initialization("Failed to >>>>>>>>>>>>>>>> start >>>>>>>>>>>>>>>> tracing >>>>>>>>>>>>>>>> >>> > >>>>>>> backend."); >>>>>>>>>>>>>>>> >>> > >>>>>>> } >>>>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> If it wants to name its native threads >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>>> free >>>>>>>>>>>>>>>> to do so, >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> Currently, JVM_SetNativeThreadName() cannot >>>>>>>>>>>>>>>> change >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> >>> thread name >>>>>>>>>>>>>>>> >>> > >>>>>>> when the caller thread is JNI-attached >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>> >>> > >>>>>>> However, I think that it should be >>>>>>>>>>>>>>>> changed if >>>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>>> developer >>>>>>>>>>>>>>>> >>> calls >>>>>>>>>>>>>>>> >>> > >>>>>>> Thread#setName() explicitly. >>>>>>>>>>>>>>>> >>> > >>>>>>> It is not the same of changing native >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> name at >>>>>>>>>>>>>>>> >>> > >>>>>>> Threads::create_vm(). >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> If it is allowed, I want to fix >>>>>>>>>>>>>>>> SetNativeThreadName() as >>>>>>>>>>>>>>>> below. >>>>>>>>>>>>>>>> >>> > >>>>>>> What do you think about this? >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> The decision to not change the name of >>>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>>> threads was a >>>>>>>>>>>>>>>> >>> > >>>>>> deliberate one** - this functionality >>>>>>>>>>>>>>>> originated >>>>>>>>>>>>>>>> with the OSX >>>>>>>>>>>>>>>> >>> port and >>>>>>>>>>>>>>>> >>> > >>>>>> it was reported that the initial feedback >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> feature was to >>>>>>>>>>>>>>>> >>> > >>>>>> ensure it didn't mess with thread names that >>>>>>>>>>>>>>>> had >>>>>>>>>>>>>>>> been set by >>>>>>>>>>>>>>>> >>> the host >>>>>>>>>>>>>>>> >>> > >>>>>> process. If we do as you propose then we >>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>> have an >>>>>>>>>>>>>>>> >>> > >>>>>> inconsistency for people to complain about: >>>>>>>>>>>>>>>> "why >>>>>>>>>>>>>>>> does my >>>>>>>>>>>>>>>> >>> native thread >>>>>>>>>>>>>>>> >>> > >>>>>> only have a name if I call >>>>>>>>>>>>>>>> cur.setName(cur.getName()) ?" >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> ** If you follow the bugs and related >>>>>>>>>>>>>>>> discussions on >>>>>>>>>>>>>>>> this, the >>>>>>>>>>>>>>>> >>> > >>>>>> semantics and limitations (truncation, >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> thread only, >>>>>>>>>>>>>>>> >>> non-JNI >>>>>>>>>>>>>>>> >>> > >>>>>> threads only) of setting the native >>>>>>>>>>>>>>>> thread name >>>>>>>>>>>>>>>> were supposed >>>>>>>>>>>>>>>> >>> to be >>>>>>>>>>>>>>>> >>> > >>>>>> documented in the release notes - but as far >>>>>>>>>>>>>>>> as I >>>>>>>>>>>>>>>> can see >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> >>> never >>>>>>>>>>>>>>>> >>> > >>>>>> happened. :( >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> My position on this remains that if it is >>>>>>>>>>>>>>>> desirable >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> the main >>>>>>>>>>>>>>>> >>> > >>>>>> thread (and DestroyJavaVM thread) to have >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> names >>>>>>>>>>>>>>>> then the >>>>>>>>>>>>>>>> >>> > >>>>>> launcher needs to be setting them using the >>>>>>>>>>>>>>>> available >>>>>>>>>>>>>>>> platform >>>>>>>>>>>>>>>> >>> APIs. >>>>>>>>>>>>>>>> >>> > >>>>>> Unfortunately this is complicated - as >>>>>>>>>>>>>>>> evidenced by >>>>>>>>>>>>>>>> the VM >>>>>>>>>>>>>>>> >>> code for >>>>>>>>>>>>>>>> >>> > >>>>>> this - due to the need to verify API >>>>>>>>>>>>>>>> availability. >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> Any change in behaviour in relation to >>>>>>>>>>>>>>>> Thread.setName would >>>>>>>>>>>>>>>> >>> have to go >>>>>>>>>>>>>>>> >>> > >>>>>> through our CCC process I think. But a >>>>>>>>>>>>>>>> change in >>>>>>>>>>>>>>>> the launcher >>>>>>>>>>>>>>>> >>> would >>>>>>>>>>>>>>>> >>> > >>>>>> not. >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> Sorry. >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>> David >>>>>>>>>>>>>>>> >>> > >>>>>> ----- >>>>>>>>>>>>>>>> >>> > >>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>>>> >>> > >>>>>>> --- a/src/share/vm/prims/jvm.cpp Thu >>>>>>>>>>>>>>>> Apr 14 >>>>>>>>>>>>>>>> 13:31:11 >>>>>>>>>>>>>>>> >>> 2016 +0200 >>>>>>>>>>>>>>>> >>> > >>>>>>> +++ b/src/share/vm/prims/jvm.cpp Fri >>>>>>>>>>>>>>>> Apr 15 >>>>>>>>>>>>>>>> 17:50:10 >>>>>>>>>>>>>>>> >>> 2016 +0900 >>>>>>>>>>>>>>>> >>> > >>>>>>> @@ -3187,7 +3187,7 @@ >>>>>>>>>>>>>>>> >>> > >>>>>>> JavaThread* thr = >>>>>>>>>>>>>>>> java_lang_Thread::thread(java_thread); >>>>>>>>>>>>>>>> >>> > >>>>>>> // Thread naming only supported for the >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>> >>> doesn't >>>>>>>>>>>>>>>> >>> > >>>>>>> work >>>>>>>>>>>>>>>> >>> > >>>>>>> for >>>>>>>>>>>>>>>> >>> > >>>>>>> // target threads. >>>>>>>>>>>>>>>> >>> > >>>>>>> - if (Thread::current() == thr && >>>>>>>>>>>>>>>> >>> !thr->has_attached_via_jni()) { >>>>>>>>>>>>>>>> >>> > >>>>>>> + if (Thread::current() == thr) { >>>>>>>>>>>>>>>> >>> > >>>>>>> // we don't set the name of an >>>>>>>>>>>>>>>> attached >>>>>>>>>>>>>>>> thread to avoid >>>>>>>>>>>>>>>> >>> stepping >>>>>>>>>>>>>>>> >>> > >>>>>>> // on other programs >>>>>>>>>>>>>>>> >>> > >>>>>>> const char *thread_name = >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> java_lang_String::as_utf8_string(JNIHandles::resolve_non_null(name)); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> --------------- >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>> On 2016/04/15 13:32, David Holmes wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> On 15/04/2016 1:11 AM, Yasumasa Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>> Roger, >>>>>>>>>>>>>>>> >>> > >>>>>>>>> Thanks for your comment! >>>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>> David, >>>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks >>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>>> this. I >>>>>>>>>>>>>>>> don't like >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>> I tried to call Thread#setName() after >>>>>>>>>>>>>>>> initializing VM >>>>>>>>>>>>>>>> (before >>>>>>>>>>>>>>>> >>> > >>>>>>>>> calling >>>>>>>>>>>>>>>> >>> > >>>>>>>>> main method), >>>>>>>>>>>>>>>> >>> > >>>>>>>>> I could set native thread name. >>>>>>>>>>>>>>>> >>> > >>>>>>>>> However, DestroyJavaVM() calls >>>>>>>>>>>>>>>> AttachCurrentThread(). >>>>>>>>>>>>>>>> So we >>>>>>>>>>>>>>>> >>> can't >>>>>>>>>>>>>>>> >>> > >>>>>>>>> set >>>>>>>>>>>>>>>> >>> > >>>>>>>>> native thread name for DestroyJavaVM. >>>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> Right - I came to the same realization >>>>>>>>>>>>>>>> earlier >>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> morning. >>>>>>>>>>>>>>>> >>> Which, >>>>>>>>>>>>>>>> >>> > >>>>>>>> unfortunately, takes me back to the basic >>>>>>>>>>>>>>>> premise >>>>>>>>>>>>>>>> here that >>>>>>>>>>>>>>>> >>> we don't >>>>>>>>>>>>>>>> >>> > >>>>>>>> set the name of threads not created by the >>>>>>>>>>>>>>>> JVM. >>>>>>>>>>>>>>>> The fact >>>>>>>>>>>>>>>> >>> that the >>>>>>>>>>>>>>>> >>> > >>>>>>>> "main" thread is not tagged as being a >>>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>>> thread seems >>>>>>>>>>>>>>>> >>> > >>>>>>>> accidental to me - so >>>>>>>>>>>>>>>> JVM_SetNativeThreadName is >>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>> working by >>>>>>>>>>>>>>>> >>> > >>>>>>>> accident for the initial attach, and >>>>>>>>>>>>>>>> can't be >>>>>>>>>>>>>>>> used for the >>>>>>>>>>>>>>>> >>> > >>>>>>>> DestroyJavaVM part - which leaves the >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> inconsistently >>>>>>>>>>>>>>>> >>> named at >>>>>>>>>>>>>>>> >>> > >>>>>>>> the native level. >>>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> I'm afraid my view here is that the >>>>>>>>>>>>>>>> launcher >>>>>>>>>>>>>>>> has >>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>> >>> treated like >>>>>>>>>>>>>>>> >>> > >>>>>>>> any other process that might host a JVM. >>>>>>>>>>>>>>>> If it >>>>>>>>>>>>>>>> wants to >>>>>>>>>>>>>>>> name its >>>>>>>>>>>>>>>> >>> > >>>>>>>> native threads then it is free to do so, >>>>>>>>>>>>>>>> but I >>>>>>>>>>>>>>>> would not be >>>>>>>>>>>>>>>> >>> exporting >>>>>>>>>>>>>>>> >>> > >>>>>>>> a function from the JVM to do that - it >>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>> use the OS >>>>>>>>>>>>>>>> >>> > >>>>>>>> specific API's for that on a >>>>>>>>>>>>>>>> platform-by-platform >>>>>>>>>>>>>>>> basis. >>>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> Sorry. >>>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> David >>>>>>>>>>>>>>>> >>> > >>>>>>>> ----- >>>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>> On 2016/04/14 23:24, Roger Riggs wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> Comments: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> jvm.h: The function names are too >>>>>>>>>>>>>>>> similar >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>> perform >>>>>>>>>>>>>>>> >>> different >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> functions: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> -JVM_SetNativeThreadName0 vs >>>>>>>>>>>>>>>> JVM_SetNativeThreadName >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> - The first function applies to the >>>>>>>>>>>>>>>> current >>>>>>>>>>>>>>>> thread, the >>>>>>>>>>>>>>>> >>> second >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> one a >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> specific java thread. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> It would seem useful for there to be a >>>>>>>>>>>>>>>> comment >>>>>>>>>>>>>>>> somewhere >>>>>>>>>>>>>>>> >>> about >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> what >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> the new function does. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> windows/native/libjli/java_md.c: line >>>>>>>>>>>>>>>> 408 >>>>>>>>>>>>>>>> casts to >>>>>>>>>>>>>>>> (void*) >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> instead of >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> (SetNativeThreadName0_t) >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> as is done on unix and mac. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> - macosx/native/libjli/java_md_macosx.c: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> - 737: looks wrong to >>>>>>>>>>>>>>>> overwriteifn->GetCreatedJavaVMs >>>>>>>>>>>>>>>> >>> used at >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> line 730 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> - 738 Incorrect indentation; if >>>>>>>>>>>>>>>> possible >>>>>>>>>>>>>>>> keep >>>>>>>>>>>>>>>> the cast >>>>>>>>>>>>>>>> >>> on the >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> same >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> line as dlsym... >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> $.02, Roger >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> On 4/14/2016 9:32 AM, Yasumasa Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question >>>>>>>>>>>>>>>> which I >>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>> time to >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is >>>>>>>>>>>>>>>> considered a >>>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>>> >>> thread >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>>>>>> then my >>>>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>>>> >>> should >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>>>>>> in our >>>>>>>>>>>>>>>> treatment of >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> I ran following program on JDK 9 EA >>>>>>>>>>>>>>>> b112, >>>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>>> confirmed >>>>>>>>>>>>>>>> >>> native >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> thread name (test) was set. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> public class Sleep{ >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> public static void main(String[] args) >>>>>>>>>>>>>>>> throws >>>>>>>>>>>>>>>> Exception{ >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.currentThread().setName("test"); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thread.sleep(3600000); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> } >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> --------- >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks >>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>>> this. I >>>>>>>>>>>>>>>> don't like >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> I will update webrev after hearing >>>>>>>>>>>>>>>> Kumar's >>>>>>>>>>>>>>>> comment. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>> On 2016/04/14 21:32, David Holmes >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> On 14/04/2016 1:52 PM, Yasumasa >>>>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> On 2016/04/14 9:34, David Holmes >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> On 14/04/2016 1:28 AM, Yasumasa >>>>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks for your comment. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> I exported new JVM function to set >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> >>> name, and JLI >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> uses it >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> in new webrev. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> First the launcher belongs to >>>>>>>>>>>>>>>> another >>>>>>>>>>>>>>>> team so >>>>>>>>>>>>>>>> >>> core-libs will >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> need to >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> review and approve this (in >>>>>>>>>>>>>>>> particular >>>>>>>>>>>>>>>> Kumar) - >>>>>>>>>>>>>>>> now cc'd. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> I'm waiting to review :-) >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Personally I would have used a Java >>>>>>>>>>>>>>>> upcall to >>>>>>>>>>>>>>>> >>> Thread.setName >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> rather >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> than exporting >>>>>>>>>>>>>>>> JVM_SetNativeThreadName. No >>>>>>>>>>>>>>>> hotspot changes >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> needed in >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> that case. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> As I wrote [1] in JBS, I changed >>>>>>>>>>>>>>>> to use >>>>>>>>>>>>>>>> Thread#setName() in >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thread#init(), >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> but I could not change native thread >>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> At Thread.init time the thread is not >>>>>>>>>>>>>>>> alive, >>>>>>>>>>>>>>>> which is >>>>>>>>>>>>>>>> >>> why the >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> native >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> name is not set. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> I guess that caller of main() is JNI >>>>>>>>>>>>>>>> attached thread. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> That is an interesting question >>>>>>>>>>>>>>>> which I >>>>>>>>>>>>>>>> haven't had >>>>>>>>>>>>>>>> time to >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> check - >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> sorry. If the main thread is >>>>>>>>>>>>>>>> considered a >>>>>>>>>>>>>>>> JNI-attached >>>>>>>>>>>>>>>> >>> thread >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> then >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> my suggestion wont work. If it isn't >>>>>>>>>>>>>>>> then my >>>>>>>>>>>>>>>> suggestion >>>>>>>>>>>>>>>> >>> should >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> work >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> (but it means we have an inconsistency >>>>>>>>>>>>>>>> in our >>>>>>>>>>>>>>>> treatment of >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> JNI-attached threads :( ) >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> I'll wait to see what Kumar thinks >>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>>> this. I >>>>>>>>>>>>>>>> don't like >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> exposing >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> a new JVM function this way. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thus I think that we have to >>>>>>>>>>>>>>>> provide a >>>>>>>>>>>>>>>> function to set >>>>>>>>>>>>>>>> >>> native >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> thread name. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152690?focusedCommentId=13926851&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13926851 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Could you review again? >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - hotspot: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/hotspot/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> - jdk: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.02/jdk/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>> On 2016/04/13 22:00, David Holmes >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> I'll answer on this original >>>>>>>>>>>>>>>> thread as >>>>>>>>>>>>>>>> well ... >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> Please see my updates to the bug >>>>>>>>>>>>>>>> (sorry >>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>> been on >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> vacation). >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> This >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> needs to be done in the launcher >>>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>>> correct >>>>>>>>>>>>>>>> as we >>>>>>>>>>>>>>>> >>> do not >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> set the >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> name of threads that attach via >>>>>>>>>>>>>>>> JNI, >>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>> includes the >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> "main" >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> On 31/03/2016 9:49 AM, Yasumasa >>>>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Thanks Robbin, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> I'm waiting a sponsor and more >>>>>>>>>>>>>>>> reviewer >>>>>>>>>>>>>>>> :-) >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> 2016/03/31 5:58 "Robbin Ehn" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> FYI: I'm not a Reviewer. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> On 03/30/2016 10:55 PM, >>>>>>>>>>>>>>>> Robbin Ehn >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> Thanks, looks good. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> On 03/30/2016 03:47 PM, >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> I uploaded new webrev. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Could you review it? >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.01/ >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> On 2016/03/30 19:10, Robbin >>>>>>>>>>>>>>>> Ehn >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> On 03/30/2016 11:41 AM, >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> Suenaga >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Hi Robbin, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016/03/30 18:22 "Robbin >>>>>>>>>>>>>>>> Ehn" >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>>: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Hi Yasumasa, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > On 03/25/2016 12:48 AM, >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> Suenaga wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Hi Robbin, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> 2016/03/25 1:51 >>>>>>>>>>>>>>>> "Robbin Ehn" >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>> >>>>: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Hi Yasumasa, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > I'm not sure why you >>>>>>>>>>>>>>>> don't >>>>>>>>>>>>>>>> set it: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > diff -r ded6ef79c770 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > --- >>>>>>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 13:09:16 2016 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0000 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > +++ >>>>>>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp Thu >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Mar 24 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 17:40:09 2016 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0100 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > @@ -3584,6 +3584,7 @@ >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > JavaThread* >>>>>>>>>>>>>>>> main_thread = >>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>> >>> JavaThread(); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> main_thread->set_thread_state(_thread_in_vm); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> main_thread->initialize_thread_current(); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > + >>>>>>>>>>>>>>>> >>> main_thread->set_native_thread_name("main"); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > // must do this >>>>>>>>>>>>>>>> before >>>>>>>>>>>>>>>> >>> set_active_handles >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> main_thread->record_stack_base_and_size(); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> main_thread->set_active_handles(JNIHandleBlock::allocate_block()); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > here instead? Am I >>>>>>>>>>>>>>>> missing >>>>>>>>>>>>>>>> something? >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Native thread name is the >>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>>> to thread >>>>>>>>>>>>>>>> >>> name in >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> class. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> It is set in c'tor in >>>>>>>>>>>>>>>> Thread or >>>>>>>>>>>>>>>> setName(). >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> If you create new >>>>>>>>>>>>>>>> thread in >>>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>>> app, >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> will be >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> set at >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> startup. However, main >>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>> already >>>>>>>>>>>>>>>> >>> starte >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> in VM. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thread name for "main" is >>>>>>>>>>>>>>>> set in >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> create_initial_thread(). >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> I think that the place of >>>>>>>>>>>>>>>> setting >>>>>>>>>>>>>>>> thrrad name >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> be the >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> same. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Yes, I see your point. But >>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>> something like >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this is >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> nicer, no? >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > --- >>>>>>>>>>>>>>>> a/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>> Tue >>>>>>>>>>>>>>>> >>> Mar 29 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 09:43:05 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > +++ >>>>>>>>>>>>>>>> b/src/share/vm/runtime/thread.cpp >>>>>>>>>>>>>>>> Wed >>>>>>>>>>>>>>>> >>> Mar 30 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 10:51:12 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 2016 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> +0200 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -981,6 +981,7 @@ >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > // Creates the initial >>>>>>>>>>>>>>>> Thread >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > static oop >>>>>>>>>>>>>>>> create_initial_thread(Handle >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread_group, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread* >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > TRAPS) { >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + static const char* >>>>>>>>>>>>>>>> initial_thread_name = >>>>>>>>>>>>>>>> >>> "main"; >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Klass* k = >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> SystemDictionary::resolve_or_fail(vmSymbols::java_lang_Thread(), >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> true, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceKlassHandle >>>>>>>>>>>>>>>> klass >>>>>>>>>>>>>>>> (THREAD, k); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > instanceHandle >>>>>>>>>>>>>>>> thread_oop = >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> klass->allocate_instance_handle(CHECK_NULL); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > @@ -988,8 +989,10 @@ >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> java_lang_Thread::set_thread(thread_oop(), >>>>>>>>>>>>>>>> >>> thread); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> java_lang_Thread::set_priority(thread_oop(), >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> NormPriority); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> thread->set_threadObj(thread_oop()); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > - Handle string = >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> java_lang_String::create_from_str("main", >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> thread->set_native_thread_name(initial_thread_name); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > + Handle string = >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> java_lang_String::create_from_str(initial_thread_name, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> CHECK_NULL); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > JavaValue >>>>>>>>>>>>>>>> result(T_VOID); >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> JavaCalls::call_special(&result, >>>>>>>>>>>>>>>> thread_oop, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Okay, I will upload new >>>>>>>>>>>>>>>> webrev >>>>>>>>>>>>>>>> later. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > The launcher seem >>>>>>>>>>>>>>>> to name >>>>>>>>>>>>>>>> itself >>>>>>>>>>>>>>>> 'java' and >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> naming >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > 'main' is confusing to >>>>>>>>>>>>>>>> me. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > E.g. so main thread of >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>> (and >>>>>>>>>>>>>>>> >>> thus >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> process) is >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> 'java' but >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > first JavaThread is >>>>>>>>>>>>>>>> 'main'. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> The native main thread in >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>> is not >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> waiting >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> for ending of Java main >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_join(). >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> set_native_thread_name() is >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> >>> JavaThread. So I >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> think that >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> we do >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> need to call it for >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> main >>>>>>>>>>>>>>>> thread. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Not sure if we can >>>>>>>>>>>>>>>> change it >>>>>>>>>>>>>>>> anyhow, since >>>>>>>>>>>>>>>> >>> we want >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> java and >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name to be the same and java >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>> might >>>>>>>>>>>>>>>> >>> have >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> some >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> dependents. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > The name is visible in >>>>>>>>>>>>>>>> e.g. >>>>>>>>>>>>>>>> /proc. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > $ ps H -C java -o 'pid tid >>>>>>>>>>>>>>>> comm' >>>>>>>>>>>>>>>> | head -4 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > PID TID COMMAND >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6423 java >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6424 main >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > 6423 6425 GC Thread#0 >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > It would be nice with >>>>>>>>>>>>>>>> something >>>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>> 'Java Main >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thread'. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> I do not think so. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Native main thread might not >>>>>>>>>>>>>>>> be a >>>>>>>>>>>>>>>> Java >>>>>>>>>>>>>>>> >>> launcher - e.g. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Apache >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> commons-daemon, JNI >>>>>>>>>>>>>>>> application, >>>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> If you want to change native >>>>>>>>>>>>>>>> main >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> name, >>>>>>>>>>>>>>>> >>> I think >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> that we >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> change Java launcher code. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Should I include it in new >>>>>>>>>>>>>>>> webrev? >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> No >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> /Robbin >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > Thanks >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > /Robbin >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > Thanks! >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > /Robbin >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > On 03/24/2016 03:26 >>>>>>>>>>>>>>>> PM, >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>> Suenaga wrote: >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Hi all, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > HotSpot for Linux >>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>> set >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> >>> name via >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> pthread_setname_np(). >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > However, main thread >>>>>>>>>>>>>>>> does not >>>>>>>>>>>>>>>> have it. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > All JavaThread have >>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> name, >>>>>>>>>>>>>>>> and main >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread is >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> JavaThread. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > For consistency, >>>>>>>>>>>>>>>> main >>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> should have >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> native >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> thread >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> name. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I uploaded a webrev. >>>>>>>>>>>>>>>> Could >>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>> review it? >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8152690/webrev.00/ >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > I cannot access >>>>>>>>>>>>>>>> JPRT. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > So I need a sponsor. >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Thanks, >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > Yasumasa >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> > > >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>> >>>>>>>>>>>>>>>> >>> > >>>>>>>>>>>>>>>> >>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >> From jini.george at oracle.com Wed Apr 27 03:53:51 2016 From: jini.george at oracle.com (Jini George) Date: Tue, 26 Apr 2016 20:53:51 -0700 (PDT) Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync In-Reply-To: References: Message-ID: <852083db-9e90-40b0-9f73-415580b1798e@default> Please hold off on this review (since I might have some modifications to the changes). Regds, Jini. From: Jini George Sent: Monday, April 25, 2016 2:29 PM To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: RE: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync Adding hotspot-runtime as well since this includes runtime changes. Regards, Jini. From: Jini George Sent: Monday, April 25, 2016 1:23 PM To: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net Subject: RFR: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync Hello, Please review the fix for the JVMTI bug: JDK-8043571: com/sun/jdi/RepStep.java fails in RT_Baseline on all platforms with assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync https://bugs.openjdk.java.net/browse/JDK-8043571 Webrev: http://cr.openjdk.java.net/~dsamersoff/sponsorship/jingeorg/JDK-8043571/webrev/ (Thanks to Dmitry for hosting this webrev). The changes here are built on top of the changes which were done for JDK-8041934 (https://bugs.openjdk.java.net/browse/JDK-8041934). The issue was that JVMTI's internal notion of the number of stack frames was getting messed up. While single stepping or when method entry/exit events are enabled, the compiled stack frames except for the native wrapper frames are reverted to interpreter frames. And for the exit of these native wrapper frames, there was no JVMTI method exit event generated - which, in turn messed up JVMTI's internal bookkeeping. The changes done here in addition to generating method exit events in the native wrapper frames when interpreter mode is enabled, are to: 1. Decrement the current stack depth (to keep JVMTI's bookkeeping wrt the number of stack frames correct) 2. Avoid the code which tries to read the return value from the location corresponding to the interpreter generated native stub, which is an invalid location in this case. With these changes the jdi tests which were failing with -Xcomp pass now. Since, at this point, we are not reading in the native return value, I have created the issue HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8043571"JDK-8043571 (For JVMTI method exits from native wrapper frames, read in the native results from the correct location) to do so. Testing done: JPRT testsets: hotspot and SVC (with and without -Xcomp). I will be sending the changes for the JDK8 backport for this in a while, in a separate webrev. Thanks, - Jini Susan George From thomas.stuefe at gmail.com Wed Apr 27 07:24:32 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 27 Apr 2016 09:24:32 +0200 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <571FB50E.6090108@oracle.com> References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> <570C417F.20600@oracle.com> <571FB50E.6090108@oracle.com> Message-ID: Hi Mikael, On Tue, Apr 26, 2016 at 8:35 PM, Mikael Vidstedt wrote: > > > On 4/12/2016 2:15 AM, Thomas St?fe wrote: > > Hi Mikael, David, > > On Tue, Apr 12, 2016 at 2:29 AM, David Holmes > wrote: > >> On 11/04/2016 10:57 AM, David Holmes wrote: >> >>> Hi Mikael, >>> >>> I think we need to be able to answer the question as to why the stubbed >>> and stubless forms of this code exist to ensure that converting all >>> platforms to the same form is appropriate. >>> >> >> The more I look at this the more the stubs make no sense :) AIII a stub >> is generated when we need runtime code that may be different to that which >> we could write directly for compiling at build time - ie to use CPU >> specific features of the actual CPU. But I see nothing here that suggests >> any such usage. >> >> So I agree with removing the stubs. >> >> I'm still going through this but my initial reaction is to wonder why we >>> don't use the same form of handle_unsafe_access on all platforms and >>> always pass in npc? (That seems to be the only difference in code that >>> otherwise seems platform independent.) >>> >> >> Futher to this and Thomas's comments I think handle_unsafe_access(thread, >> pc, npc) can be defined in shared code (where? not sure). Further, if we >> always pass in npc then we don't need to pass in pc as it is unused (seems >> unused in original code too for sparc). >> >> > I agree. We commonized ucontext_set_pc for all Posix platforms, so we can > make a common function "handle_unsafe_access(thread, npc)" and inside use > os::Posix::ucontext_set_pc to modify the context. Then we can get rid of > the special handling in the signal handlers inside os_aix_ppc.cpp and > os_linux_ppc.cpp (for both the compiled and the interpreted case). > > > There is definitely room for unification and simplification here. Right > now the signal handling code is, sadly, different on all the different > platforms, despite the fact that in many cases it should be similar or the > exact same. That said, as much as a refactoring/rewrite of the signal > handler code is needed, it will very quickly turn into a much larger > effort... > > In this specific case, it would probably make more sense to pass in the > full context to the handle_unsafe_access method and have it do whatever it > feels is necessary to update it. However, a lot of the signal handler code > assumes that a "stub" variable gets set up and only at the end of the main > signal handler function does the actual context get updated. Changing how > that works only for this specific case is obviously not a good idea, which > means it's back to the full scale refactoring and out of scope for the bug > fix. > > So to me the fact that the method prototypes differ depending on the exact > platform is just a reflection of how the contexts differ. In lack of the > full context the handler method needs to take whatever parts of the context > is needed to do it's job. I could of course change the handler method to > only take a single "next_pc" argument, but to me that feels like putting a > key part of the logic which handles the unsafe access (specifically, the > part which calculates the next pc) in the wrong place - IMHO that should > really be tightly coupled with the rest of the logic needed to handle an > unsafe access (updating the thread state etc.), and hence I feel that it > really belongs in the handle_unsafe_access method itself. Happy to hear > your thoughts, but I hope we can agree that the suggested fix, even in its > current state, is still significantly better than what is there now. > > > Unless somebody has a better suggestion, I'm going to be moving the > implementations of the handle_unsafe_access methods to sharedRuntime > (instead of stubRoutines) and will send out a new webrev shortly. > > I am unhappy with the fact that we factor unsafe handling out for x86 and sparc but do it inline for ppc. I know that was done before your change as well but would be happy if that could be improved. I would prefer either one of: 1) flatten out the coding into the signal handlers like it is done in os_linux_ppc.cpp and os_aix_ppc.cpp or 2) add a StubRoutines::ppc64::handle_unsafe_access() for the ppc case I would actually prefer (1) even though this would multiply the code out for all os cases into ; we are only talking about 1-2 lines of additional coding, and it would improve the readability of the signal handlers. But this is only my personal opinion, and I do not have strong emotions. I agree with you that a full cleanup of the signal coding is out of scope for this issue. > Cheers, > Mikael > > > > BTW I found this comment somewhat unfathomable (both now and in original >> code): >> >> + // pc is the instruction which we must emulate >> + // doing a no-op is fine: return garbage from the load >> >> but finally realized that it means that after the load that raised the >> signal the native code proceeds normally but the value apparently loaded is >> just garbage/arbitrary, and the only sign something went wrong is the >> setting of the pending unsafe-access-error bit. This would be a potential >> source of bugs I think, except that when we hit the Java level, we throw >> the exception and so never actually "return" the garbage value. But it does >> mean we would have to be careful if calling the unsafe routines from native >> code. >> >> > I admit I do not understand fully how the _special_runtime_exit_condition > flag is processed later, at least not for all cases: If I have a java > method A using sun.misc.unsafe, which gets compiled, the sun.misc.unsafe > intrinsic gets inlined into that method. So, the whole method A gets marked > as "has unsafe access"? So, any SIGBUS happening inside this method - which > may be larger than the inlined sun.misc.unsafe call - will yield an > InternalError? And when is the flag checked if that method A is called from > another java method B? > > Sorry if the questions are stupid, I am not a JIT expert, but I try to > understand how much can happen between the SIGBUS and the InternalError > getting thrown. > > > No questions are stupid here. As you may have seen in the other thread, I > filed JDK-8154592[1] to cover making the handling of the faults > synchronous. Hope that helps. > > Thank you! Kind Regards, Thomas > Cheers, > Mikael > > [1] https://bugs.openjdk.java.net/browse/JDK-8154592 > > > > Thanks, Thomas > > >> Thanks, >> David >> >> >> Thanks, >>> David >>> >>> On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: >>> >>>> >>>> Please review: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >>>> >>>> >>>> >>>> * Note: this is patch 2 in a set of 3 all aiming to clean up and unify >>>> the unsafe memory getters/setters, along with the handling of unsafe >>>> access errors. The other two issues are: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe access >>>> error as an asynchronous exception >>>> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >>>> getters/setters to use double-register variants >>>> >>>> >>>> * Summary (copied from the bug description) >>>> >>>> >>>> In certain cases, such as accessing a region of a memory mapped file >>>> which has been truncated on unix-style operating systems, a SIGBUS >>>> signal will be raised and the VM will process it in the signal handler. >>>> >>>> How the signal is processed differs depending on the operating system >>>> and/or CPU architecture, with two major alternatives: >>>> >>>> * "stubless" >>>> >>>> Do the necessary thread state updates directly in the signal handler, >>>> and modify the context so that the signal handler returns to the place >>>> where the execution should continue >>>> >>>> * Using a stub >>>> >>>> Update the context so that when the signal handler returns the thread >>>> will continue execution in a generated stub, which in turn will call >>>> some native code in the VM to update the thread state and figure out >>>> where execution should continue. The stub will then jump to that new >>>> place. >>>> >>>> >>>> It should be noted that the work of updating the thread state is very >>>> small - it's setting a flag or two in the thread structure, and figures >>>> out where the next instruction starts. It should also be noted that the >>>> generated stubs today are broken, because they do not preserve all the >>>> live registers over the call into the VM. There are two ways to address >>>> this: >>>> >>>> * Preserve all the necessary registers >>>> >>>> This would mean implementing, in macro assembly, the necessary logic for >>>> preserving all the live registers, including, but not limited to, >>>> floating point registers, flag registers, etc. It quickly becomes >>>> obvious that this platform specific and error prone. >>>> >>>> * Leverage the fact that the operating system already does this as part >>>> of the signal handling >>>> >>>> Do the necessary work in the signal handler instead, removing the need >>>> for the stub alltogether >>>> >>>> As mentioned, on some platforms the latter model is already in use. It >>>> is dramatically easier and all platforms should be updated to do it the >>>> same way. >>>> >>>> >>>> * Testing >>>> >>>> Just as mentioned in the RFR for JDK-8153890, a new test was developed >>>> to test this code path: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >>>> >>>> In fact, it was when running this test I found the register preservation >>>> issue. JPRT also passes. Much like JDK-8153890 I wanted to get some >>>> feedback on this before running additional tests. >>>> >>>> >>>> Cheers, >>>> Mikael >>>> >>>> > > From harold.seigel at oracle.com Wed Apr 27 12:34:53 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 27 Apr 2016 08:34:53 -0400 Subject: RFR(S) 8151342: Add module name/version to class histogram output Message-ID: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> Hi, Please review this small change to add module information to the class histogram displayed by tools such as jmap and jcmd. The module name and version will follow the class name and be enclosed in parentheses. Classes not in modules will not contain module information. For example: num #instances #bytes class name (module) ------------------------------------------------------- 1: 7892 1575952 [B (java.base at 9-internal) 2: 1783 214672 java.lang.Class (java.base at 9-internal) 3: 5749 183968 java.util.HashMap$Node (java.base at 9-internal) 4: 7081 169944 java.lang.String (java.base at 9-internal) 5: 1881 95312 [Ljava.lang.Object; (java.base at 9-internal) 6: 785 90832 [I (java.base at 9-internal) ... 16: 1024 16384 ClassHistogramTest$TestClass ... Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8151342/ JBS bug: https://bugs.openjdk.java.net/browse/JDK-8151342 The fix was tested with JCK Lang, and VM tests, the UTE colocated and non-colocated quick tests, and the JTreg jdk_svc, hotspot, JDK java/io, java/lang, java/util, and java/security tests. Thanks, Harold From george.triantafillou at oracle.com Wed Apr 27 12:58:57 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 27 Apr 2016 08:58:57 -0400 Subject: RFR(S) 8151342: Add module name/version to class histogram output In-Reply-To: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> References: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> Message-ID: <5720B791.6060208@oracle.com> Hi Harold, Looks good! -George On 4/27/2016 8:34 AM, harold seigel wrote: > Hi, > > Please review this small change to add module information to the class > histogram displayed by tools such as jmap and jcmd. The module name > and version will follow the class name and be enclosed in > parentheses. Classes not in modules will not contain module > information. For example: > > num #instances #bytes class name (module) > ------------------------------------------------------- > 1: 7892 1575952 [B (java.base at 9-internal) > 2: 1783 214672 java.lang.Class > (java.base at 9-internal) > 3: 5749 183968 java.util.HashMap$Node > (java.base at 9-internal) > 4: 7081 169944 java.lang.String > (java.base at 9-internal) > 5: 1881 95312 [Ljava.lang.Object; > (java.base at 9-internal) > 6: 785 90832 [I (java.base at 9-internal) > ... > 16: 1024 16384 ClassHistogramTest$TestClass > ... > > > Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8151342/ > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8151342 > > The fix was tested with JCK Lang, and VM tests, the UTE colocated and > non-colocated quick tests, and the JTreg jdk_svc, hotspot, JDK > java/io, java/lang, java/util, and java/security tests. > > Thanks, Harold > From HORII at jp.ibm.com Wed Apr 27 03:34:12 2016 From: HORII at jp.ibm.com (Hiroshi H Horii) Date: Wed, 27 Apr 2016 12:34:12 +0900 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79lDi013336@d19av08.sagamino.japan.ibm.com> Message-ID: <201604271338.u3RDcZ6B017507@d19av05.sagamino.japan.ibm.com> Hi Martin, > I think we shouldn?t better use an own enum (e.g. like AccessKind in > library_call.cpp). > Otherwise we?ll get trouble when we switch to C++11. Would you agree? I agree. I think, to use the enum and semantics of C++11, callers of cmpxchg need to call memory-barrier after cmpxchg when all of updates in the other processes must be available for the following instructions of the cmpxchg. Correct? > Would it be better to split this bug into 2 and discuss the cmpxchg > interface change on the runtime list and the GC change on the gc list? Do you mean that a new cmpxchg with relaxed semantics will be added and used in the GC change? Or, after the discussion of the new cmpxchg interface, will be the discussion of the GC change started? Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo "Doerr, Martin" wrote on 04/25/2016 19:25:15: > From: "Doerr, Martin" > To: Hiroshi H Horii/Japan/IBM at IBMJP, David Holmes > Cc: "hotspot-gc-dev at openjdk.java.net" dev at openjdk.java.net>, "hotspot-runtime-dev at openjdk.java.net" > , "ppc-aix-port- > dev at openjdk.java.net" , Tim > Ellison , Volker Simonis > , "Lindenmaier, Goetz" > Date: 04/25/2016 19:26 > Subject: RE: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > Hi David and Hiroshi, > > thank you very much for this interesting question and analysis. > > I think we shouldn?t better use an own enum (e.g. like AccessKind in > library_call.cpp). > Otherwise we?ll get trouble when we switch to C++11. Would you agree? > > Would it be better to split this bug into 2 and discuss the cmpxchg > interface change on the runtime list and the GC change on the gc list? > > Best regards, > Martin > > From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] > Sent: Montag, 25. April 2016 09:10 > To: David Holmes > Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Tim Ellison > ; Volker Simonis ; > Doerr, Martin ; Lindenmaier, Goetz > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > Hi David, > > Thank you for your comments and questions. > > > 1. Are the current cmpxchg semantics exactly the same as > > memory_order_seq_cst? > > This is very good question.. > > I guess, cmpxchg needs a more conservative constraint for memory ordering > than C++11, to add sync after a compare-and-exchange operation. > > Could someone give comments or thoughts? > > memory_order_seq_cst is defined as > "Any operation with this memory order is both an acquire operation and > a release operation, plus a single total order exists in which > all threads > observe all modifications (see below) in the same order." > (http://en.cppreference.com/w/cpp/atomic/memory_order) > > In my environment, g++ and xlc generate following assemblies on ppc64le. > (interestingly, they generates the same assemblies for any memory_order) > > g++ (4.9.2) > 100008a4: ac 04 00 7c sync > 100008a8: 28 50 20 7d lwarx r9,0,r10 > 100008ac: 00 18 09 7c cmpw r9,r3 > 100008b0: 0c 00 c2 40 bne- 100008bc > 100008b4: 2d 51 80 7c stwcx. r4,0,r10 > 100008b8: f0 ff c2 40 bne- 100008a8 > 100008bc: 2c 01 00 4c isync > > xlc (13.1.3) > 10000888: ac 04 00 7c sync > 1000088c: 28 28 c0 7c lwarx r6,0,r5 > 10000890: 40 00 26 7c cmpld r6,r0 > 10000894: 0c 00 82 40 bne 100008a0 > 10000898: 2d 29 80 7c stwcx. r4,0,r5 > 1000089c: f0 ff e2 40 bne+ 1000088c > 100008a0: 2c 01 00 4c isync > > On the other hand, the current OpenJDK generates following assemblies. > > 508: ac 04 00 7c sync > 50c: 00 00 5c e9 ld r10,0(r28) > 510: 00 50 3b 7c cmpd r27,r10 > 514: 1c 00 c2 40 bne- 530 > 518: a8 40 5c 7d ldarx r10,r28,r8 > 51c: 00 50 3b 7c cmpd r27,r10 > 520: 10 00 c2 40 bne- 530 > 524: ad 41 3c 7d stdcx. r9,r28,r8 > 528: f0 ff c2 40 bne- 518 > 52c: ac 04 00 7c sync > 530: 00 50 bb 7f ... > > Though we can ignore 50c-514 (because they are a duplicated guard condition), > the last sync instruction (52c) makes cmpxchg more strict than > memory_order_seq_cst. > > In some cases, the last sync is necessary when this thread must be > able to read > all of the changes in the other threads while executing from 508 to 530 > (that processes compare-and-exchange). > > > 2. Has there been a discussion already, establishing that the modified > > GC code can indeed use memory_order_relaxed? Otherwise who is > > postulating that and based on what evidence? > > Volker and his colleagues have investigated the current GC codes > according to this. > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > April/019079.html > However, I believe, we need comments of other GC experts to change > the shared codes. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > David Holmes wrote on 04/22/2016 21:57:07: > > > From: David Holmes > > To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- > > dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net > > Cc: Tim Ellison , ppc-aix-port-dev at openjdk.java.net > > Date: 04/22/2016 21:58 > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > > copy_to_survivor for ppc64 > > > > Hi Hiroshi, > > > > Two initial questions: > > > > 1. Are the current cmpxchg semantics exactly the same as > > memory_order_seq_cst? > > > > 2. Has there been a discussion already, establishing that the modified > > GC code can indeed use memory_order_relaxed? Otherwise who is > > postulating that and based on what evidence? > > > > Missing memory barriers have caused very difficult to track down bugs in > > the past - very rare race conditions. So any relaxation here has to be > > done with extreme confidence. > > > > Thanks, > > David > > > > On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: > > > Dear all: > > > > > > Can I please request reviews for the following change? > > > > > > Code change: > > > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ > > > (I initially created and Martin enhanced so much) > > > > > > This change follows the discussion started from this mail. > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > April/018960.html > > > > > > Description: > > > This change provides relaxed compare-and-exchange by introducing > > > similar semantics of C++ atomic memory operators, enum memory_order. > > > As described in atomic_linux_ppc.inline.hpp, the current implementation of > > > cmpxchg is fence_cmpxchg_acquire. This implementation is useful for > > > general purposes because twice calls of sync before and after cmpxchg will > > > provide strict consistency. However, they sometimes cause overheads > > > because > > > sync instructions are very expensive in the current POWER chip design. > > > In addition, for the other platforms, such as aarch64, this strict > > > semantics > > > may cause some overheads (according to the Andrew's mail). > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > April/019073.html > > > > > > With this change, callers can explicitly specify constraints of memory > > > ordering > > > for cmpxchg with an additional parameter, memory_order order. > > > > > > typedef enum memory_order { > > > memory_order_relaxed, > > > memory_order_consume, > > > memory_order_acquire, > > > memory_order_release, > > > memory_order_acq_rel, > > > memory_order_seq_cst > > > } memory_order; > > > > > > Because the default value of the parameter is memory_order_seq_cst, > > > existing codes can use the same semantics of cmpxchg without any > > > modification. The relaxed cmpxchg is implemented only on ppc > > > in this changeset. Therefore, the behavior on the other platforms will > > > not be changed with this changeset. > > > > > > In addition, with the new parameter of cmpxchg, this change improves > > > performance of copy_to_survivor in the parallel GC. > > > copy_to_survivor changes forward pointers by using cmpxchg. This > > > operation doesn't require any sync instructions. A pointer is changed > > > at most once in a GC and when cmpxchg fails, the latest pointer is > > > available for the caller. cas_set_mark and cas_forward_to are extended > > > with an additional memory_order parameter as cmpxchg and copy_to_survivor > > > uses memory_order_relaxed to modify the forward pointers. > > > > > > Summary of source code changes: > > > > > > * src/share/vm/runtime/atomic.hpp > > > - Defines enum memory_order and adds a parameter to cmpxchg. > > > > > > * src/share/vm/runtime/atomic.cpp > > > * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > > > * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > > > * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > > > * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > > > * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > > > * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > > > * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > > > * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > > > * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > > > - Added a parameter for each cmpxchg function to follow > > > the change of atomic.hpp. Their implementations are not changed. > > > > > > * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > > > * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > > > - Added a parameter for each cmpxchg function to follow > > > the change of atomic.hpp. In addition, implementations > > > are changed corresponding to the specified memory_order. > > > > > > * src/share/vm/oops/oop.hpp > > > * src/share/vm/oops/oop.inline.hpp > > > - Add a memory_order parameter to use relaxed cmpxchg in > > > cas_set_mark and cas_forward_to. > > > > > > * src/share/vm/gc/parallel/psPromotionManager.cpp > > > * src/share/vm/gc/parallel/psPromotionManager.inline.hpp > > > > > > Martin tested this changeset on linuxx86_64, linuxppc64le and > > > darwinintel64. > > > Though more time is needed to test on the other platform, we would like to > > > ask > > > reviews and start discussion on this changeset. > > > I also tested this changeset with SPECjbb2013 and confirmed that gc pause > > > time > > > is reduced. > > > > > > Regards, > > > Hiroshi > > > ----------------------- > > > Hiroshi Horii, Ph.D. > > > IBM Research - Tokyo > > > > > > > > From martin.doerr at sap.com Wed Apr 27 14:46:18 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 27 Apr 2016 14:46:18 +0000 Subject: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <201604271338.u3RDcRUd029939@d19av06.sagamino.japan.ibm.com> References: <201604221228.u3MCSXCL020021@d19av07.sagamino.japan.ibm.com> <571A1FA3.9030006@oracle.com> <201604250709.u3P79lDi013336@d19av08.sagamino.japan.ibm.com> <201604271338.u3RDcRUd029939@d19av06.sagamino.japan.ibm.com> Message-ID: <03ca7f623bee439885e9bdeaca5ab80b@DEWDFE13DE14.global.corp.sap> Hi Hiroshi, > I think, to use the enum and semantics of C++11, callers of cmpxchg need to call > memory-barrier after cmpxchg when all of updates in the other processes must be > available for the following instructions of the cmpxchg. Correct? I think the problem is that our current C++ code doesn?t use seq_cst semantics for volatile loads. The sync at the end of the cmpxchg is only needed if a volatile load is following which is not preceded by a sync instruction. As long as this is the case, I think we should keep the sync at the end of cmpxchg. > Do you mean that a new cmpxchg with relaxed semantics will be added and used in > the GC change? Or, after the discussion of the new cmpxchg interface, will be > the discussion of the GC change started? The second. Best regards, Martin From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] Sent: Mittwoch, 27. April 2016 05:34 To: Doerr, Martin Cc: David Holmes ; Lindenmaier, Goetz ; hotspot-gc-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Tim Ellison ; Volker Simonis Subject: RE: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 Hi Martin, > I think we shouldn?t better use an own enum (e.g. like AccessKind in > library_call.cpp). > Otherwise we?ll get trouble when we switch to C++11. Would you agree? I agree. I think, to use the enum and semantics of C++11, callers of cmpxchg need to call memory-barrier after cmpxchg when all of updates in the other processes must be available for the following instructions of the cmpxchg. Correct? > Would it be better to split this bug into 2 and discuss the cmpxchg > interface change on the runtime list and the GC change on the gc list? Do you mean that a new cmpxchg with relaxed semantics will be added and used in the GC change? Or, after the discussion of the new cmpxchg interface, will be the discussion of the GC change started? Regards, Hiroshi ----------------------- Hiroshi Horii, Ph.D. IBM Research - Tokyo "Doerr, Martin" > wrote on 04/25/2016 19:25:15: > From: "Doerr, Martin" > > To: Hiroshi H Horii/Japan/IBM at IBMJP, David Holmes > > Cc: "hotspot-gc-dev at openjdk.java.net" dev at openjdk.java.net>, "hotspot-runtime-dev at openjdk.java.net" > >, "ppc-aix-port- > dev at openjdk.java.net" >, Tim > Ellison >, Volker Simonis > >, "Lindenmaier, Goetz" > > Date: 04/25/2016 19:26 > Subject: RE: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > Hi David and Hiroshi, > > thank you very much for this interesting question and analysis. > > I think we shouldn?t better use an own enum (e.g. like AccessKind in > library_call.cpp). > Otherwise we?ll get trouble when we switch to C++11. Would you agree? > > Would it be better to split this bug into 2 and discuss the cmpxchg > interface change on the runtime list and the GC change on the gc list? > > Best regards, > Martin > > From: Hiroshi H Horii [mailto:HORII at jp.ibm.com] > Sent: Montag, 25. April 2016 09:10 > To: David Holmes > > Cc: hotspot-gc-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Tim Ellison > >; Volker Simonis >; > Doerr, Martin >; Lindenmaier, Goetz > > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > copy_to_survivor for ppc64 > > Hi David, > > Thank you for your comments and questions. > > > 1. Are the current cmpxchg semantics exactly the same as > > memory_order_seq_cst? > > This is very good question.. > > I guess, cmpxchg needs a more conservative constraint for memory ordering > than C++11, to add sync after a compare-and-exchange operation. > > Could someone give comments or thoughts? > > memory_order_seq_cst is defined as > "Any operation with this memory order is both an acquire operation and > a release operation, plus a single total order exists in which > all threads > observe all modifications (see below) in the same order." > (http://en.cppreference.com/w/cpp/atomic/memory_order) > > In my environment, g++ and xlc generate following assemblies on ppc64le. > (interestingly, they generates the same assemblies for any memory_order) > > g++ (4.9.2) > 100008a4: ac 04 00 7c sync > 100008a8: 28 50 20 7d lwarx r9,0,r10 > 100008ac: 00 18 09 7c cmpw r9,r3 > 100008b0: 0c 00 c2 40 bne- 100008bc > 100008b4: 2d 51 80 7c stwcx. r4,0,r10 > 100008b8: f0 ff c2 40 bne- 100008a8 > 100008bc: 2c 01 00 4c isync > > xlc (13.1.3) > 10000888: ac 04 00 7c sync > 1000088c: 28 28 c0 7c lwarx r6,0,r5 > 10000890: 40 00 26 7c cmpld r6,r0 > 10000894: 0c 00 82 40 bne 100008a0 > 10000898: 2d 29 80 7c stwcx. r4,0,r5 > 1000089c: f0 ff e2 40 bne+ 1000088c > 100008a0: 2c 01 00 4c isync > > On the other hand, the current OpenJDK generates following assemblies. > > 508: ac 04 00 7c sync > 50c: 00 00 5c e9 ld r10,0(r28) > 510: 00 50 3b 7c cmpd r27,r10 > 514: 1c 00 c2 40 bne- 530 > 518: a8 40 5c 7d ldarx r10,r28,r8 > 51c: 00 50 3b 7c cmpd r27,r10 > 520: 10 00 c2 40 bne- 530 > 524: ad 41 3c 7d stdcx. r9,r28,r8 > 528: f0 ff c2 40 bne- 518 > 52c: ac 04 00 7c sync > 530: 00 50 bb 7f ... > > Though we can ignore 50c-514 (because they are a duplicated guard condition), > the last sync instruction (52c) makes cmpxchg more strict than > memory_order_seq_cst. > > In some cases, the last sync is necessary when this thread must be > able to read > all of the changes in the other threads while executing from 508 to 530 > (that processes compare-and-exchange). > > > 2. Has there been a discussion already, establishing that the modified > > GC code can indeed use memory_order_relaxed? Otherwise who is > > postulating that and based on what evidence? > > Volker and his colleagues have investigated the current GC codes > according to this. > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > April/019079.html > However, I believe, we need comments of other GC experts to change > the shared codes. > > Regards, > Hiroshi > ----------------------- > Hiroshi Horii, Ph.D. > IBM Research - Tokyo > > > David Holmes > wrote on 04/22/2016 21:57:07: > > > From: David Holmes > > > To: Hiroshi H Horii/Japan/IBM at IBMJP, hotspot-runtime- > > dev at openjdk.java.net, hotspot-gc-dev at openjdk.java.net > > Cc: Tim Ellison >, ppc-aix-port-dev at openjdk.java.net > > Date: 04/22/2016 21:58 > > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and > > copy_to_survivor for ppc64 > > > > Hi Hiroshi, > > > > Two initial questions: > > > > 1. Are the current cmpxchg semantics exactly the same as > > memory_order_seq_cst? > > > > 2. Has there been a discussion already, establishing that the modified > > GC code can indeed use memory_order_relaxed? Otherwise who is > > postulating that and based on what evidence? > > > > Missing memory barriers have caused very difficult to track down bugs in > > the past - very rare race conditions. So any relaxation here has to be > > done with extreme confidence. > > > > Thanks, > > David > > > > On 22/04/2016 10:28 PM, Hiroshi H Horii wrote: > > > Dear all: > > > > > > Can I please request reviews for the following change? > > > > > > Code change: > > > http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/ > > > (I initially created and Martin enhanced so much) > > > > > > This change follows the discussion started from this mail. > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > April/018960.html > > > > > > Description: > > > This change provides relaxed compare-and-exchange by introducing > > > similar semantics of C++ atomic memory operators, enum memory_order. > > > As described in atomic_linux_ppc.inline.hpp, the current implementation of > > > cmpxchg is fence_cmpxchg_acquire. This implementation is useful for > > > general purposes because twice calls of sync before and after cmpxchg will > > > provide strict consistency. However, they sometimes cause overheads > > > because > > > sync instructions are very expensive in the current POWER chip design. > > > In addition, for the other platforms, such as aarch64, this strict > > > semantics > > > may cause some overheads (according to the Andrew's mail). > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > > April/019073.html > > > > > > With this change, callers can explicitly specify constraints of memory > > > ordering > > > for cmpxchg with an additional parameter, memory_order order. > > > > > > typedef enum memory_order { > > > memory_order_relaxed, > > > memory_order_consume, > > > memory_order_acquire, > > > memory_order_release, > > > memory_order_acq_rel, > > > memory_order_seq_cst > > > } memory_order; > > > > > > Because the default value of the parameter is memory_order_seq_cst, > > > existing codes can use the same semantics of cmpxchg without any > > > modification. The relaxed cmpxchg is implemented only on ppc > > > in this changeset. Therefore, the behavior on the other platforms will > > > not be changed with this changeset. > > > > > > In addition, with the new parameter of cmpxchg, this change improves > > > performance of copy_to_survivor in the parallel GC. > > > copy_to_survivor changes forward pointers by using cmpxchg. This > > > operation doesn't require any sync instructions. A pointer is changed > > > at most once in a GC and when cmpxchg fails, the latest pointer is > > > available for the caller. cas_set_mark and cas_forward_to are extended > > > with an additional memory_order parameter as cmpxchg and copy_to_survivor > > > uses memory_order_relaxed to modify the forward pointers. > > > > > > Summary of source code changes: > > > > > > * src/share/vm/runtime/atomic.hpp > > > - Defines enum memory_order and adds a parameter to cmpxchg. > > > > > > * src/share/vm/runtime/atomic.cpp > > > * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > > > * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > > > * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > > > * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > > > * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > > > * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > > > * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > > > * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > > > * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > > > - Added a parameter for each cmpxchg function to follow > > > the change of atomic.hpp. Their implementations are not changed. > > > > > > * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > > > * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > > > - Added a parameter for each cmpxchg function to follow > > > the change of atomic.hpp. In addition, implementations > > > are changed corresponding to the specified memory_order. > > > > > > * src/share/vm/oops/oop.hpp > > > * src/share/vm/oops/oop.inline.hpp > > > - Add a memory_order parameter to use relaxed cmpxchg in > > > cas_set_mark and cas_forward_to. > > > > > > * src/share/vm/gc/parallel/psPromotionManager.cpp > > > * src/share/vm/gc/parallel/psPromotionManager.inline.hpp > > > > > > Martin tested this changeset on linuxx86_64, linuxppc64le and > > > darwinintel64. > > > Though more time is needed to test on the other platform, we would like to > > > ask > > > reviews and start discussion on this changeset. > > > I also tested this changeset with SPECjbb2013 and confirmed that gc pause > > > time > > > is reduced. > > > > > > Regards, > > > Hiroshi > > > ----------------------- > > > Hiroshi Horii, Ph.D. > > > IBM Research - Tokyo > > > > > > > > From mikael.vidstedt at oracle.com Wed Apr 27 15:54:48 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 27 Apr 2016 08:54:48 -0700 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> <570C417F.20600@oracle.com> <571FB50E.6090108@oracle.com> Message-ID: <5720E0C8.608@oracle.com> On 4/27/2016 12:24 AM, Thomas St?fe wrote: > Hi Mikael, > > On Tue, Apr 26, 2016 at 8:35 PM, Mikael Vidstedt > > wrote: > > > > On 4/12/2016 2:15 AM, Thomas St?fe wrote: >> Hi Mikael, David, >> >> On Tue, Apr 12, 2016 at 2:29 AM, David Holmes >> > wrote: >> >> On 11/04/2016 10:57 AM, David Holmes wrote: >> >> Hi Mikael, >> >> I think we need to be able to answer the question as to >> why the stubbed >> and stubless forms of this code exist to ensure that >> converting all >> platforms to the same form is appropriate. >> >> >> The more I look at this the more the stubs make no sense :) >> AIII a stub is generated when we need runtime code that may >> be different to that which we could write directly for >> compiling at build time - ie to use CPU specific features of >> the actual CPU. But I see nothing here that suggests any such >> usage. >> >> So I agree with removing the stubs. >> >> I'm still going through this but my initial reaction is >> to wonder why we >> don't use the same form of handle_unsafe_access on all >> platforms and >> always pass in npc? (That seems to be the only difference >> in code that >> otherwise seems platform independent.) >> >> >> Futher to this and Thomas's comments I think >> handle_unsafe_access(thread, pc, npc) can be defined in >> shared code (where? not sure). Further, if we always pass in >> npc then we don't need to pass in pc as it is unused (seems >> unused in original code too for sparc). >> >> >> I agree. We commonized ucontext_set_pc for all Posix platforms, >> so we can make a common function "handle_unsafe_access(thread, >> npc)" and inside use os::Posix::ucontext_set_pc to modify the >> context. Then we can get rid of the special handling in the >> signal handlers inside os_aix_ppc.cpp and os_linux_ppc.cpp (for >> both the compiled and the interpreted case). > > There is definitely room for unification and simplification here. > Right now the signal handling code is, sadly, different on all the > different platforms, despite the fact that in many cases it should > be similar or the exact same. That said, as much as a > refactoring/rewrite of the signal handler code is needed, it will > very quickly turn into a much larger effort... > > In this specific case, it would probably make more sense to pass > in the full context to the handle_unsafe_access method and have it > do whatever it feels is necessary to update it. However, a lot of > the signal handler code assumes that a "stub" variable gets set up > and only at the end of the main signal handler function does the > actual context get updated. Changing how that works only for this > specific case is obviously not a good idea, which means it's back > to the full scale refactoring and out of scope for the bug fix. > > So to me the fact that the method prototypes differ depending on > the exact platform is just a reflection of how the contexts > differ. In lack of the full context the handler method needs to > take whatever parts of the context is needed to do it's job. I > could of course change the handler method to only take a single > "next_pc" argument, but to me that feels like putting a key part > of the logic which handles the unsafe access (specifically, the > part which calculates the next pc) in the wrong place - IMHO that > should really be tightly coupled with the rest of the logic needed > to handle an unsafe access (updating the thread state etc.), and > hence I feel that it really belongs in the handle_unsafe_access > method itself. Happy to hear your thoughts, but I hope we can > agree that the suggested fix, even in its current state, is still > significantly better than what is there now. > > > Unless somebody has a better suggestion, I'm going to be moving > the implementations of the handle_unsafe_access methods to > sharedRuntime (instead of stubRoutines) and will send out a new > webrev shortly. > > > I am unhappy with the fact that we factor unsafe handling out for x86 > and sparc but do it inline for ppc. I know that was done before your > change as well but would be happy if that could be improved. I would > prefer either one of: Fully agree - this is an example of the more general problem of logic which is /almost/ the same across different platforms, but which has been effectively copy/pasted and drifted apart over time. > > 1) flatten out the coding into the signal handlers like it is done in > os_linux_ppc.cpp and os_aix_ppc.cpp or > 2) add a StubRoutines::ppc64::handle_unsafe_access() for the ppc case > > I would actually prefer (1) even though this would multiply the code > out for all os cases into ; we are only talking about 1-2 > lines of additional coding, and it would improve the readability of > the signal handlers. > > But this is only my personal opinion, and I do not have strong > emotions. I agree with you that a full cleanup of the signal coding is > out of scope for this issue. I spent yesterday going back and forth on the various alternatives and the only thing I can say with certainty now is that apart from refactoring the whole thing everything else is ugly... For example, I agree that consistency is an important goal here, but since there's little to no consistency there today it's really hard to make a relevant dent in it. :( Flattening it out is an alternative (and a good one), but that is not something I'm willing to do as part of this change because only flattening this specific case/return will actually add to the inconstency... So ultimately yesterday I chose to do something closer to your alternative 2). Is it still ugly? Yes; lipstick on pig and all of that. Have a look at it and see how you feel about it. I try to keep in mind that what is there today is (more) broken. :) Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.02/hotspot/webrev/ Incremental from webrev.01: http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.02.incr/hotspot/webrev/ Cheers, Mikael > > > Cheers, > Mikael > >> >> >> BTW I found this comment somewhat unfathomable (both now and >> in original code): >> >> + // pc is the instruction which we must emulate >> + // doing a no-op is fine: return garbage from the load >> >> but finally realized that it means that after the load that >> raised the signal the native code proceeds normally but the >> value apparently loaded is just garbage/arbitrary, and the >> only sign something went wrong is the setting of the pending >> unsafe-access-error bit. This would be a potential source of >> bugs I think, except that when we hit the Java level, we >> throw the exception and so never actually "return" the >> garbage value. But it does mean we would have to be careful >> if calling the unsafe routines from native code. >> >> >> I admit I do not understand fully how the >> _special_runtime_exit_condition flag is processed later, at least >> not for all cases: If I have a java method A using >> sun.misc.unsafe, which gets compiled, the sun.misc.unsafe >> intrinsic gets inlined into that method. So, the whole method A >> gets marked as "has unsafe access"? So, any SIGBUS happening >> inside this method - which may be larger than the inlined >> sun.misc.unsafe call - will yield an InternalError? And when is >> the flag checked if that method A is called from another java >> method B? >> >> Sorry if the questions are stupid, I am not a JIT expert, but I >> try to understand how much can happen between the SIGBUS and the >> InternalError getting thrown. > > No questions are stupid here. As you may have seen in the other > thread, I filed JDK-8154592[1] to cover making the handling of the > faults synchronous. Hope that helps. > > > Thank you! > > Kind Regards, Thomas > > Cheers, > Mikael > > [1] https://bugs.openjdk.java.net/browse/JDK-8154592 > > >> >> Thanks, Thomas >> >> Thanks, >> David >> >> >> Thanks, >> David >> >> On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: >> >> >> Please review: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >> >> >> >> >> * Note: this is patch 2 in a set of 3 all aiming to >> clean up and unify >> the unsafe memory getters/setters, along with the >> handling of unsafe >> access errors. The other two issues are: >> >> https://bugs.openjdk.java.net/browse/JDK-8153890 - >> Handle unsafe access >> error as an asynchronous exception >> https://bugs.openjdk.java.net/browse/JDK-8150921 - >> Update Unsafe >> getters/setters to use double-register variants >> >> >> * Summary (copied from the bug description) >> >> >> In certain cases, such as accessing a region of a >> memory mapped file >> which has been truncated on unix-style operating >> systems, a SIGBUS >> signal will be raised and the VM will process it in >> the signal handler. >> >> How the signal is processed differs depending on the >> operating system >> and/or CPU architecture, with two major alternatives: >> >> * "stubless" >> >> Do the necessary thread state updates directly in the >> signal handler, >> and modify the context so that the signal handler >> returns to the place >> where the execution should continue >> >> * Using a stub >> >> Update the context so that when the signal handler >> returns the thread >> will continue execution in a generated stub, which in >> turn will call >> some native code in the VM to update the thread state >> and figure out >> where execution should continue. The stub will then >> jump to that new >> place. >> >> >> It should be noted that the work of updating the >> thread state is very >> small - it's setting a flag or two in the thread >> structure, and figures >> out where the next instruction starts. It should also >> be noted that the >> generated stubs today are broken, because they do not >> preserve all the >> live registers over the call into the VM. There are >> two ways to address >> this: >> >> * Preserve all the necessary registers >> >> This would mean implementing, in macro assembly, the >> necessary logic for >> preserving all the live registers, including, but not >> limited to, >> floating point registers, flag registers, etc. It >> quickly becomes >> obvious that this platform specific and error prone. >> >> * Leverage the fact that the operating system already >> does this as part >> of the signal handling >> >> Do the necessary work in the signal handler instead, >> removing the need >> for the stub alltogether >> >> As mentioned, on some platforms the latter model is >> already in use. It >> is dramatically easier and all platforms should be >> updated to do it the >> same way. >> >> >> * Testing >> >> Just as mentioned in the RFR for JDK-8153890, a new >> test was developed >> to test this code path: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >> >> >> In fact, it was when running this test I found the >> register preservation >> issue. JPRT also passes. Much like JDK-8153890 I >> wanted to get some >> feedback on this before running additional tests. >> >> >> Cheers, >> Mikael >> >> > > From calvin.cheung at oracle.com Wed Apr 27 17:18:30 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 27 Apr 2016 10:18:30 -0700 Subject: RFR(xs): 8154976: UseSharedSpaces error message is incomplete Message-ID: <5720F466.2010507@oracle.com> Please review this small fix for completing the error message in case there's a mapping failure when using a CDS archive. This error will be shown when the -XX:+PrintSharedSpaces option is used. Before the fix: UseSharedSpaces: Unable to map %s shared space at required address. After the fix: UseSharedSpaces: Unable to map ReadOnly shared space at required address. JBS: https://bugs.openjdk.java.net/browse/JDK-8154976 webrev: http://cr.openjdk.java.net/~ccheung/8154976/webrev.00/ Testing: JPRT manual test on windows to ensure the error message is correct. thanks, Calvin From chris.plummer at oracle.com Wed Apr 27 17:35:08 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 27 Apr 2016 10:35:08 -0700 Subject: RFR(xs): 8154976: UseSharedSpaces error message is incomplete In-Reply-To: <5720F466.2010507@oracle.com> References: <5720F466.2010507@oracle.com> Message-ID: <5720F84C.1020602@oracle.com> Hi Calvin, Looks good. Chris On 4/27/16 10:18 AM, Calvin Cheung wrote: > > Please review this small fix for completing the error message in case > there's a mapping failure when using a CDS archive. This error will be > shown when the -XX:+PrintSharedSpaces option is used. > > Before the fix: > UseSharedSpaces: Unable to map %s shared space at required address. > > After the fix: > UseSharedSpaces: Unable to map ReadOnly shared space at required address. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154976 > > webrev: http://cr.openjdk.java.net/~ccheung/8154976/webrev.00/ > > Testing: > JPRT > manual test on windows to ensure the error message is correct. > > thanks, > Calvin From harold.seigel at oracle.com Wed Apr 27 17:35:32 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 27 Apr 2016 13:35:32 -0400 Subject: RFR(S) 8151342: Add module name/version to class histogram output In-Reply-To: <4dae9adb-c85b-fc50-3936-5870c0ca1d8c@oracle.com> References: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> <4dae9adb-c85b-fc50-3936-5870c0ca1d8c@oracle.com> Message-ID: <90ede06e-7c4d-7eb3-cdcf-bd1b33e26534@oracle.com> Hi Sundar, Thanks for reviewing my change. I'm unclear about what module related work is being done in SA. If a similar change is needed in SA then I'd prefer to handle it as a separate bug. Thanks! Harold On 4/27/2016 8:41 AM, Sundararajan Athijegannathan wrote: > +1 > > PS. Don't we have to update the SA code that dumps histogram so that -F > mode output would be similar? > > -Sundar > > On 4/27/2016 6:04 PM, harold seigel wrote: >> Hi, >> >> Please review this small change to add module information to the class >> histogram displayed by tools such as jmap and jcmd. The module name >> and version will follow the class name and be enclosed in >> parentheses. Classes not in modules will not contain module >> information. For example: >> >> num #instances #bytes class name (module) >> ------------------------------------------------------- >> 1: 7892 1575952 [B (java.base at 9-internal) >> 2: 1783 214672 java.lang.Class >> (java.base at 9-internal) >> 3: 5749 183968 java.util.HashMap$Node >> (java.base at 9-internal) >> 4: 7081 169944 java.lang.String >> (java.base at 9-internal) >> 5: 1881 95312 [Ljava.lang.Object; >> (java.base at 9-internal) >> 6: 785 90832 [I (java.base at 9-internal) >> ... >> 16: 1024 16384 ClassHistogramTest$TestClass >> ... >> >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8151342/ >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8151342 >> >> The fix was tested with JCK Lang, and VM tests, the UTE colocated and >> non-colocated quick tests, and the JTreg jdk_svc, hotspot, JDK >> java/io, java/lang, java/util, and java/security tests. >> >> Thanks, Harold >> From harold.seigel at oracle.com Wed Apr 27 17:35:59 2016 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 27 Apr 2016 13:35:59 -0400 Subject: RFR(S) 8151342: Add module name/version to class histogram output In-Reply-To: <5720B791.6060208@oracle.com> References: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> <5720B791.6060208@oracle.com> Message-ID: <9117bc88-cfc3-3606-f064-dec751d3b001@oracle.com> Thanks George! Harold On 4/27/2016 8:58 AM, George Triantafillou wrote: > Hi Harold, > > Looks good! > > -George > > On 4/27/2016 8:34 AM, harold seigel wrote: >> Hi, >> >> Please review this small change to add module information to the >> class histogram displayed by tools such as jmap and jcmd. The module >> name and version will follow the class name and be enclosed in >> parentheses. Classes not in modules will not contain module >> information. For example: >> >> num #instances #bytes class name (module) >> ------------------------------------------------------- >> 1: 7892 1575952 [B (java.base at 9-internal) >> 2: 1783 214672 java.lang.Class >> (java.base at 9-internal) >> 3: 5749 183968 java.util.HashMap$Node >> (java.base at 9-internal) >> 4: 7081 169944 java.lang.String >> (java.base at 9-internal) >> 5: 1881 95312 [Ljava.lang.Object; >> (java.base at 9-internal) >> 6: 785 90832 [I (java.base at 9-internal) >> ... >> 16: 1024 16384 ClassHistogramTest$TestClass >> ... >> >> >> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8151342/ >> >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8151342 >> >> The fix was tested with JCK Lang, and VM tests, the UTE colocated and >> non-colocated quick tests, and the JTreg jdk_svc, hotspot, JDK >> java/io, java/lang, java/util, and java/security tests. >> >> Thanks, Harold >> > From calvin.cheung at oracle.com Wed Apr 27 17:51:49 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 27 Apr 2016 10:51:49 -0700 Subject: RFR(xs): 8154976: UseSharedSpaces error message is incomplete In-Reply-To: <5720F84C.1020602@oracle.com> References: <5720F466.2010507@oracle.com> <5720F84C.1020602@oracle.com> Message-ID: <5720FC35.6020006@oracle.com> Thanks for you quick review, Chris. Calvin On 4/27/16, 10:35 AM, Chris Plummer wrote: > Hi Calvin, > > Looks good. > > Chris > > On 4/27/16 10:18 AM, Calvin Cheung wrote: >> >> Please review this small fix for completing the error message in case >> there's a mapping failure when using a CDS archive. This error will >> be shown when the -XX:+PrintSharedSpaces option is used. >> >> Before the fix: >> UseSharedSpaces: Unable to map %s shared space at required address. >> >> After the fix: >> UseSharedSpaces: Unable to map ReadOnly shared space at required >> address. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8154976 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8154976/webrev.00/ >> >> Testing: >> JPRT >> manual test on windows to ensure the error message is correct. >> >> thanks, >> Calvin > From jiangli.zhou at oracle.com Wed Apr 27 18:09:59 2016 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 27 Apr 2016 11:09:59 -0700 Subject: RFR(xs): 8154976: UseSharedSpaces error message is incomplete In-Reply-To: <5720F466.2010507@oracle.com> References: <5720F466.2010507@oracle.com> Message-ID: <18ED029D-2B22-4827-B2B0-34E66E348B3C@oracle.com> Looks good. Thanks, Jiangli > On Apr 27, 2016, at 10:18 AM, Calvin Cheung wrote: > > > Please review this small fix for completing the error message in case there's a mapping failure when using a CDS archive. This error will be shown when the -XX:+PrintSharedSpaces option is used. > > Before the fix: > UseSharedSpaces: Unable to map %s shared space at required address. > > After the fix: > UseSharedSpaces: Unable to map ReadOnly shared space at required address. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154976 > > webrev: http://cr.openjdk.java.net/~ccheung/8154976/webrev.00/ > > Testing: > JPRT > manual test on windows to ensure the error message is correct. > > thanks, > Calvin From mikhailo.seledtsov at oracle.com Wed Apr 27 18:22:56 2016 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Wed, 27 Apr 2016 11:22:56 -0700 Subject: RFR(xs): 8154976: UseSharedSpaces error message is incomplete In-Reply-To: <5720F466.2010507@oracle.com> References: <5720F466.2010507@oracle.com> Message-ID: <57210380.6020207@oracle.com> Looks good to me. Misha On 04/27/2016 10:18 AM, Calvin Cheung wrote: > > Please review this small fix for completing the error message in case > there's a mapping failure when using a CDS archive. This error will be > shown when the -XX:+PrintSharedSpaces option is used. > > Before the fix: > UseSharedSpaces: Unable to map %s shared space at required address. > > After the fix: > UseSharedSpaces: Unable to map ReadOnly shared space at required address. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154976 > > webrev: http://cr.openjdk.java.net/~ccheung/8154976/webrev.00/ > > Testing: > JPRT > manual test on windows to ensure the error message is correct. > > thanks, > Calvin From calvin.cheung at oracle.com Wed Apr 27 18:33:39 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 27 Apr 2016 11:33:39 -0700 Subject: RFR(xs): 8154976: UseSharedSpaces error message is incomplete In-Reply-To: <18ED029D-2B22-4827-B2B0-34E66E348B3C@oracle.com> References: <5720F466.2010507@oracle.com> <18ED029D-2B22-4827-B2B0-34E66E348B3C@oracle.com> Message-ID: <57210603.1090602@oracle.com> Thanks, Jiangli. Calvin On 4/27/16, 11:09 AM, Jiangli Zhou wrote: > Looks good. > > Thanks, > Jiangli > >> On Apr 27, 2016, at 10:18 AM, Calvin Cheung wrote: >> >> >> Please review this small fix for completing the error message in case there's a mapping failure when using a CDS archive. This error will be shown when the -XX:+PrintSharedSpaces option is used. >> >> Before the fix: >> UseSharedSpaces: Unable to map %s shared space at required address. >> >> After the fix: >> UseSharedSpaces: Unable to map ReadOnly shared space at required address. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8154976 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8154976/webrev.00/ >> >> Testing: >> JPRT >> manual test on windows to ensure the error message is correct. >> >> thanks, >> Calvin From calvin.cheung at oracle.com Wed Apr 27 18:34:18 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 27 Apr 2016 11:34:18 -0700 Subject: RFR(xs): 8154976: UseSharedSpaces error message is incomplete In-Reply-To: <57210380.6020207@oracle.com> References: <5720F466.2010507@oracle.com> <57210380.6020207@oracle.com> Message-ID: <5721062A.2080708@oracle.com> Thanks, Misha. Calvin On 4/27/16, 11:22 AM, mikhailo wrote: > Looks good to me. > > Misha > > On 04/27/2016 10:18 AM, Calvin Cheung wrote: >> >> Please review this small fix for completing the error message in case >> there's a mapping failure when using a CDS archive. This error will >> be shown when the -XX:+PrintSharedSpaces option is used. >> >> Before the fix: >> UseSharedSpaces: Unable to map %s shared space at required address. >> >> After the fix: >> UseSharedSpaces: Unable to map ReadOnly shared space at required >> address. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8154976 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8154976/webrev.00/ >> >> Testing: >> JPRT >> manual test on windows to ensure the error message is correct. >> >> thanks, >> Calvin > From volker.simonis at gmail.com Thu Apr 28 09:39:37 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 28 Apr 2016 11:39:37 +0200 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. In-Reply-To: <1E4DB6BB-7950-4F26-B074-1CDCA8623D43@oracle.com> References: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> <077a096cb4dd406997636081fd939f92@DEWDFE13DE09.global.corp.sap> <932CC317-7EEB-49A2-A74F-6371E137F4A6@oracle.com> <1E4DB6BB-7950-4F26-B074-1CDCA8623D43@oracle.com> Message-ID: Hi Gerard, the change looks good! Regards, Volker On Mon, Apr 18, 2016 at 4:53 PM, Gerard Ziemski wrote: > Thank you for the review Goetz! > > Can I have a second review for this simple fix please? > > In this fix we set the max range value to max_jlong (and change the type to uint64_t) since it gets assigned to MaxDirectMemorySize property that is later parsed as ?java long? (in java.base/VM.java:290) > > https://bugs.openjdk.java.net/browse/JDK-8153835 > http://cr.openjdk.java.net/~gziemski/8153835_rev1/ > > Passes JPRT hotspot and RBT hotspot/test/runtime/CommandLine/OptionsValidation > > > cheers > From thomas.stuefe at gmail.com Thu Apr 28 12:25:53 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Apr 2016 14:25:53 +0200 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <5720E0C8.608@oracle.com> References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> <570C417F.20600@oracle.com> <571FB50E.6090108@oracle.com> <5720E0C8.608@oracle.com> Message-ID: Hi Mikael, On Wed, Apr 27, 2016 at 5:54 PM, Mikael Vidstedt wrote: > > > On 4/27/2016 12:24 AM, Thomas St?fe wrote: > > Hi Mikael, > > On Tue, Apr 26, 2016 at 8:35 PM, Mikael Vidstedt < > mikael.vidstedt at oracle.com> wrote: > >> >> >> On 4/12/2016 2:15 AM, Thomas St?fe wrote: >> >> Hi Mikael, David, >> >> On Tue, Apr 12, 2016 at 2:29 AM, David Holmes < >> david.holmes at oracle.com> wrote: >> >>> On 11/04/2016 10:57 AM, David Holmes wrote: >>> >>>> Hi Mikael, >>>> >>>> I think we need to be able to answer the question as to why the stubbed >>>> and stubless forms of this code exist to ensure that converting all >>>> platforms to the same form is appropriate. >>>> >>> >>> The more I look at this the more the stubs make no sense :) AIII a stub >>> is generated when we need runtime code that may be different to that which >>> we could write directly for compiling at build time - ie to use CPU >>> specific features of the actual CPU. But I see nothing here that suggests >>> any such usage. >>> >>> So I agree with removing the stubs. >>> >>> I'm still going through this but my initial reaction is to wonder why we >>>> don't use the same form of handle_unsafe_access on all platforms and >>>> always pass in npc? (That seems to be the only difference in code that >>>> otherwise seems platform independent.) >>>> >>> >>> Futher to this and Thomas's comments I think >>> handle_unsafe_access(thread, pc, npc) can be defined in shared code (where? >>> not sure). Further, if we always pass in npc then we don't need to pass in >>> pc as it is unused (seems unused in original code too for sparc). >>> >>> >> I agree. We commonized ucontext_set_pc for all Posix platforms, so we can >> make a common function "handle_unsafe_access(thread, npc)" and inside use >> os::Posix::ucontext_set_pc to modify the context. Then we can get rid of >> the special handling in the signal handlers inside os_aix_ppc.cpp and >> os_linux_ppc.cpp (for both the compiled and the interpreted case). >> >> >> There is definitely room for unification and simplification here. Right >> now the signal handling code is, sadly, different on all the different >> platforms, despite the fact that in many cases it should be similar or the >> exact same. That said, as much as a refactoring/rewrite of the signal >> handler code is needed, it will very quickly turn into a much larger >> effort... >> >> In this specific case, it would probably make more sense to pass in the >> full context to the handle_unsafe_access method and have it do whatever it >> feels is necessary to update it. However, a lot of the signal handler code >> assumes that a "stub" variable gets set up and only at the end of the main >> signal handler function does the actual context get updated. Changing how >> that works only for this specific case is obviously not a good idea, which >> means it's back to the full scale refactoring and out of scope for the bug >> fix. >> >> So to me the fact that the method prototypes differ depending on the >> exact platform is just a reflection of how the contexts differ. In lack of >> the full context the handler method needs to take whatever parts of the >> context is needed to do it's job. I could of course change the handler >> method to only take a single "next_pc" argument, but to me that feels like >> putting a key part of the logic which handles the unsafe access >> (specifically, the part which calculates the next pc) in the wrong place - >> IMHO that should really be tightly coupled with the rest of the logic >> needed to handle an unsafe access (updating the thread state etc.), and >> hence I feel that it really belongs in the handle_unsafe_access method >> itself. Happy to hear your thoughts, but I hope we can agree that the >> suggested fix, even in its current state, is still significantly better >> than what is there now. >> >> >> Unless somebody has a better suggestion, I'm going to be moving the >> implementations of the handle_unsafe_access methods to sharedRuntime >> (instead of stubRoutines) and will send out a new webrev shortly. >> >> > I am unhappy with the fact that we factor unsafe handling out for x86 and > sparc but do it inline for ppc. I know that was done before your change as > well but would be happy if that could be improved. I would prefer either > one of: > > > Fully agree - this is an example of the more general problem of logic > which is /almost/ the same across different platforms, but which has been > effectively copy/pasted and drifted apart over time. > > > 1) flatten out the coding into the signal handlers like it is done in > os_linux_ppc.cpp and os_aix_ppc.cpp or > 2) add a StubRoutines::ppc64::handle_unsafe_access() for the ppc case > > I would actually prefer (1) even though this would multiply the code out > for all os cases into ; we are only talking about 1-2 lines of > additional coding, and it would improve the readability of the signal > handlers. > > But this is only my personal opinion, and I do not have strong emotions. I > agree with you that a full cleanup of the signal coding is out of scope for > this issue. > > > I spent yesterday going back and forth on the various alternatives and the > only thing I can say with certainty now is that apart from refactoring the > whole thing everything else is ugly... For example, I agree that > consistency is an important goal here, but since there's little to no > consistency there today it's really hard to make a relevant dent in it. :( > > Flattening it out is an alternative (and a good one), but that is not > something I'm willing to do as part of this change because only flattening > this specific case/return will actually add to the inconstency... So > ultimately yesterday I chose to do something closer to your alternative 2). > Is it still ugly? Yes; lipstick on pig and all of that. Have a look at it > and see how you feel about it. I try to keep in mind that what is there > today is (more) broken. :) > > Webrev: > > > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.02/hotspot/webrev/ > > Incremental from webrev.01: > > > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.02.incr/hotspot/webrev/ > > Cheers, > Mikael > > I am fine with the changes as they are in webrev.02. Any further cleanup can be deferred to a later change. I did build your change on AIX, it did build ok. Thanks for taking my input! Kind Regards, Thomas > > > > >> Cheers, >> Mikael >> >> >> >> BTW I found this comment somewhat unfathomable (both now and in original >>> code): >>> >>> + // pc is the instruction which we must emulate >>> + // doing a no-op is fine: return garbage from the load >>> >>> but finally realized that it means that after the load that raised the >>> signal the native code proceeds normally but the value apparently loaded is >>> just garbage/arbitrary, and the only sign something went wrong is the >>> setting of the pending unsafe-access-error bit. This would be a potential >>> source of bugs I think, except that when we hit the Java level, we throw >>> the exception and so never actually "return" the garbage value. But it does >>> mean we would have to be careful if calling the unsafe routines from native >>> code. >>> >>> >> I admit I do not understand fully how the _special_runtime_exit_condition >> flag is processed later, at least not for all cases: If I have a java >> method A using sun.misc.unsafe, which gets compiled, the sun.misc.unsafe >> intrinsic gets inlined into that method. So, the whole method A gets marked >> as "has unsafe access"? So, any SIGBUS happening inside this method - which >> may be larger than the inlined sun.misc.unsafe call - will yield an >> InternalError? And when is the flag checked if that method A is called from >> another java method B? >> >> Sorry if the questions are stupid, I am not a JIT expert, but I try to >> understand how much can happen between the SIGBUS and the InternalError >> getting thrown. >> >> >> No questions are stupid here. As you may have seen in the other thread, I >> filed JDK-8154592[1] to cover making the handling of the faults >> synchronous. Hope that helps. >> >> > Thank you! > > Kind Regards, Thomas > > > >> Cheers, >> Mikael >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8154592 >> >> >> >> Thanks, Thomas >> >> >>> Thanks, >>> David >>> >>> >>> Thanks, >>>> David >>>> >>>> On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: >>>> >>>>> >>>>> Please review: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >>>>> >>>>> >>>>> >>>>> * Note: this is patch 2 in a set of 3 all aiming to clean up and unify >>>>> the unsafe memory getters/setters, along with the handling of unsafe >>>>> access errors. The other two issues are: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8153890 - Handle unsafe >>>>> access >>>>> error as an asynchronous exception >>>>> https://bugs.openjdk.java.net/browse/JDK-8150921 - Update Unsafe >>>>> getters/setters to use double-register variants >>>>> >>>>> >>>>> * Summary (copied from the bug description) >>>>> >>>>> >>>>> In certain cases, such as accessing a region of a memory mapped file >>>>> which has been truncated on unix-style operating systems, a SIGBUS >>>>> signal will be raised and the VM will process it in the signal handler. >>>>> >>>>> How the signal is processed differs depending on the operating system >>>>> and/or CPU architecture, with two major alternatives: >>>>> >>>>> * "stubless" >>>>> >>>>> Do the necessary thread state updates directly in the signal handler, >>>>> and modify the context so that the signal handler returns to the place >>>>> where the execution should continue >>>>> >>>>> * Using a stub >>>>> >>>>> Update the context so that when the signal handler returns the thread >>>>> will continue execution in a generated stub, which in turn will call >>>>> some native code in the VM to update the thread state and figure out >>>>> where execution should continue. The stub will then jump to that new >>>>> place. >>>>> >>>>> >>>>> It should be noted that the work of updating the thread state is very >>>>> small - it's setting a flag or two in the thread structure, and figures >>>>> out where the next instruction starts. It should also be noted that the >>>>> generated stubs today are broken, because they do not preserve all the >>>>> live registers over the call into the VM. There are two ways to address >>>>> this: >>>>> >>>>> * Preserve all the necessary registers >>>>> >>>>> This would mean implementing, in macro assembly, the necessary logic >>>>> for >>>>> preserving all the live registers, including, but not limited to, >>>>> floating point registers, flag registers, etc. It quickly becomes >>>>> obvious that this platform specific and error prone. >>>>> >>>>> * Leverage the fact that the operating system already does this as part >>>>> of the signal handling >>>>> >>>>> Do the necessary work in the signal handler instead, removing the need >>>>> for the stub alltogether >>>>> >>>>> As mentioned, on some platforms the latter model is already in use. It >>>>> is dramatically easier and all platforms should be updated to do it the >>>>> same way. >>>>> >>>>> >>>>> * Testing >>>>> >>>>> Just as mentioned in the RFR for JDK-8153890, a new test was developed >>>>> to test this code path: >>>>> >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >>>>> >>>>> In fact, it was when running this test I found the register >>>>> preservation >>>>> issue. JPRT also passes. Much like JDK-8153890 I wanted to get some >>>>> feedback on this before running additional tests. >>>>> >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>>> >> >> > > From david.holmes at oracle.com Thu Apr 28 12:41:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Apr 2016 22:41:57 +1000 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <5720E0C8.608@oracle.com> References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> <570C417F.20600@oracle.com> <571FB50E.6090108@oracle.com> <5720E0C8.608@oracle.com> Message-ID: <57220515.6080309@oracle.com> Hi Mikael, On 28/04/2016 1:54 AM, Mikael Vidstedt wrote: > > > On 4/27/2016 12:24 AM, Thomas St?fe wrote: >> Hi Mikael, >> >> On Tue, Apr 26, 2016 at 8:35 PM, Mikael Vidstedt >> <mikael.vidstedt at oracle.com> wrote: >> >> >> >> On 4/12/2016 2:15 AM, Thomas St?fe wrote: >>> Hi Mikael, David, >>> >>> On Tue, Apr 12, 2016 at 2:29 AM, David Holmes >>> <david.holmes at oracle.com> wrote: >>> >>> On 11/04/2016 10:57 AM, David Holmes wrote: >>> >>> Hi Mikael, >>> >>> I think we need to be able to answer the question as to >>> why the stubbed >>> and stubless forms of this code exist to ensure that >>> converting all >>> platforms to the same form is appropriate. >>> >>> >>> The more I look at this the more the stubs make no sense :) >>> AIII a stub is generated when we need runtime code that may >>> be different to that which we could write directly for >>> compiling at build time - ie to use CPU specific features of >>> the actual CPU. But I see nothing here that suggests any such >>> usage. >>> >>> So I agree with removing the stubs. >>> >>> I'm still going through this but my initial reaction is >>> to wonder why we >>> don't use the same form of handle_unsafe_access on all >>> platforms and >>> always pass in npc? (That seems to be the only difference >>> in code that >>> otherwise seems platform independent.) >>> >>> >>> Futher to this and Thomas's comments I think >>> handle_unsafe_access(thread, pc, npc) can be defined in >>> shared code (where? not sure). Further, if we always pass in >>> npc then we don't need to pass in pc as it is unused (seems >>> unused in original code too for sparc). >>> >>> >>> I agree. We commonized ucontext_set_pc for all Posix platforms, >>> so we can make a common function "handle_unsafe_access(thread, >>> npc)" and inside use os::Posix::ucontext_set_pc to modify the >>> context. Then we can get rid of the special handling in the >>> signal handlers inside os_aix_ppc.cpp and os_linux_ppc.cpp (for >>> both the compiled and the interpreted case). >> >> There is definitely room for unification and simplification here. >> Right now the signal handling code is, sadly, different on all the >> different platforms, despite the fact that in many cases it should >> be similar or the exact same. That said, as much as a >> refactoring/rewrite of the signal handler code is needed, it will >> very quickly turn into a much larger effort... >> >> In this specific case, it would probably make more sense to pass >> in the full context to the handle_unsafe_access method and have it >> do whatever it feels is necessary to update it. However, a lot of >> the signal handler code assumes that a "stub" variable gets set up >> and only at the end of the main signal handler function does the >> actual context get updated. Changing how that works only for this >> specific case is obviously not a good idea, which means it's back >> to the full scale refactoring and out of scope for the bug fix. >> >> So to me the fact that the method prototypes differ depending on >> the exact platform is just a reflection of how the contexts >> differ. In lack of the full context the handler method needs to >> take whatever parts of the context is needed to do it's job. I >> could of course change the handler method to only take a single >> "next_pc" argument, but to me that feels like putting a key part >> of the logic which handles the unsafe access (specifically, the >> part which calculates the next pc) in the wrong place - IMHO that >> should really be tightly coupled with the rest of the logic needed >> to handle an unsafe access (updating the thread state etc.), and >> hence I feel that it really belongs in the handle_unsafe_access >> method itself. Happy to hear your thoughts, but I hope we can >> agree that the suggested fix, even in its current state, is still >> significantly better than what is there now. >> >> >> Unless somebody has a better suggestion, I'm going to be moving >> the implementations of the handle_unsafe_access methods to >> sharedRuntime (instead of stubRoutines) and will send out a new >> webrev shortly. >> >> >> I am unhappy with the fact that we factor unsafe handling out for x86 >> and sparc but do it inline for ppc. I know that was done before your >> change as well but would be happy if that could be improved. I would >> prefer either one of: > > Fully agree - this is an example of the more general problem of logic > which is /almost/ the same across different platforms, but which has > been effectively copy/pasted and drifted apart over time. > >> >> 1) flatten out the coding into the signal handlers like it is done in >> os_linux_ppc.cpp and os_aix_ppc.cpp or >> 2) add a StubRoutines::ppc64::handle_unsafe_access() for the ppc case >> >> I would actually prefer (1) even though this would multiply the code >> out for all os cases into ; we are only talking about 1-2 >> lines of additional coding, and it would improve the readability of >> the signal handlers. >> >> But this is only my personal opinion, and I do not have strong >> emotions. I agree with you that a full cleanup of the signal coding is >> out of scope for this issue. > > I spent yesterday going back and forth on the various alternatives and > the only thing I can say with certainty now is that apart from > refactoring the whole thing everything else is ugly... For example, I > agree that consistency is an important goal here, but since there's > little to no consistency there today it's really hard to make a relevant > dent in it. :( > > Flattening it out is an alternative (and a good one), but that is not > something I'm willing to do as part of this change because only > flattening this specific case/return will actually add to the > inconstency... So ultimately yesterday I chose to do something closer to > your alternative 2). Is it still ugly? Yes; lipstick on pig and all of > that. Have a look at it and see how you feel about it. I try to keep in > mind that what is there today is (more) broken. :) > > Webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.02/hotspot/webrev/ Now I see this in code form I really don't understand why next_pc is passed in, unused and then returned ?? Otherwise in src/share/vm/runtime/sharedRuntime.cpp in the comment block - capitals after periods please :) Stub removal seems fine. Thanks, David > Incremental from webrev.01: > > http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.02.incr/hotspot/webrev/ > > Cheers, > Mikael > >> >> >> Cheers, >> Mikael >> >>> >>> >>> BTW I found this comment somewhat unfathomable (both now and >>> in original code): >>> >>> + // pc is the instruction which we must emulate >>> + // doing a no-op is fine: return garbage from the load >>> >>> but finally realized that it means that after the load that >>> raised the signal the native code proceeds normally but the >>> value apparently loaded is just garbage/arbitrary, and the >>> only sign something went wrong is the setting of the pending >>> unsafe-access-error bit. This would be a potential source of >>> bugs I think, except that when we hit the Java level, we >>> throw the exception and so never actually "return" the >>> garbage value. But it does mean we would have to be careful >>> if calling the unsafe routines from native code. >>> >>> >>> I admit I do not understand fully how the >>> _special_runtime_exit_condition flag is processed later, at least >>> not for all cases: If I have a java method A using >>> sun.misc.unsafe, which gets compiled, the sun.misc.unsafe >>> intrinsic gets inlined into that method. So, the whole method A >>> gets marked as "has unsafe access"? So, any SIGBUS happening >>> inside this method - which may be larger than the inlined >>> sun.misc.unsafe call - will yield an InternalError? And when is >>> the flag checked if that method A is called from another java >>> method B? >>> >>> Sorry if the questions are stupid, I am not a JIT expert, but I >>> try to understand how much can happen between the SIGBUS and the >>> InternalError getting thrown. >> >> No questions are stupid here. As you may have seen in the other >> thread, I filed JDK-8154592[1] to cover making the handling of the >> faults synchronous. Hope that helps. >> >> >> Thank you! >> >> Kind Regards, Thomas >> >> Cheers, >> Mikael >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8154592 >> >> >>> >>> Thanks, Thomas >>> >>> Thanks, >>> David >>> >>> >>> Thanks, >>> David >>> >>> On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: >>> >>> >>> Please review: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >>> >>> >>> >>> >>> * Note: this is patch 2 in a set of 3 all aiming to >>> clean up and unify >>> the unsafe memory getters/setters, along with the >>> handling of unsafe >>> access errors. The other two issues are: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8153890 - >>> Handle unsafe access >>> error as an asynchronous exception >>> https://bugs.openjdk.java.net/browse/JDK-8150921 - >>> Update Unsafe >>> getters/setters to use double-register variants >>> >>> >>> * Summary (copied from the bug description) >>> >>> >>> In certain cases, such as accessing a region of a >>> memory mapped file >>> which has been truncated on unix-style operating >>> systems, a SIGBUS >>> signal will be raised and the VM will process it in >>> the signal handler. >>> >>> How the signal is processed differs depending on the >>> operating system >>> and/or CPU architecture, with two major alternatives: >>> >>> * "stubless" >>> >>> Do the necessary thread state updates directly in the >>> signal handler, >>> and modify the context so that the signal handler >>> returns to the place >>> where the execution should continue >>> >>> * Using a stub >>> >>> Update the context so that when the signal handler >>> returns the thread >>> will continue execution in a generated stub, which in >>> turn will call >>> some native code in the VM to update the thread state >>> and figure out >>> where execution should continue. The stub will then >>> jump to that new >>> place. >>> >>> >>> It should be noted that the work of updating the >>> thread state is very >>> small - it's setting a flag or two in the thread >>> structure, and figures >>> out where the next instruction starts. It should also >>> be noted that the >>> generated stubs today are broken, because they do not >>> preserve all the >>> live registers over the call into the VM. There are >>> two ways to address >>> this: >>> >>> * Preserve all the necessary registers >>> >>> This would mean implementing, in macro assembly, the >>> necessary logic for >>> preserving all the live registers, including, but not >>> limited to, >>> floating point registers, flag registers, etc. It >>> quickly becomes >>> obvious that this platform specific and error prone. >>> >>> * Leverage the fact that the operating system already >>> does this as part >>> of the signal handling >>> >>> Do the necessary work in the signal handler instead, >>> removing the need >>> for the stub alltogether >>> >>> As mentioned, on some platforms the latter model is >>> already in use. It >>> is dramatically easier and all platforms should be >>> updated to do it the >>> same way. >>> >>> >>> * Testing >>> >>> Just as mentioned in the RFR for JDK-8153890, a new >>> test was developed >>> to test this code path: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >>> >>> >>> In fact, it was when running this test I found the >>> register preservation >>> issue. JPRT also passes. Much like JDK-8153890 I >>> wanted to get some >>> feedback on this before running additional tests. >>> >>> >>> Cheers, >>> Mikael >>> >>> >> >> > From thomas.stuefe at gmail.com Thu Apr 28 13:48:04 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Apr 2016 15:48:04 +0200 Subject: RFR(xs): 8155639: Remove STEP numbers from error reporting Message-ID: Hi, may I have reviews and a sponsor for the following small improvement? Bug: https://bugs.openjdk.java.net/browse/JDK-8155639 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8155639-STEP-number-removal/webrev.00/webrev/ Basically, this change proposes to get rid of the hand-coded STEP numbers in error reporting in favour of using the __LINE__ macro. The hand-coded step numbers are a constant source or errors, as they need to maintained in monotonous order and if they are not, error reporting steps are just quietly swallowed. Using the __LINE__ macro would be self-maintaining and thus much more robust. Thank you! Thomas From gerard.ziemski at oracle.com Thu Apr 28 14:22:49 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 28 Apr 2016 09:22:49 -0500 Subject: RFR(XS): 8153835: Fix range of flag MaxDirectMemorySize which is parsed at jlong. In-Reply-To: References: <124ef6a91e924fc7966173bdf2ad545c@DEWDFE13DE09.global.corp.sap> <077a096cb4dd406997636081fd939f92@DEWDFE13DE09.global.corp.sap> <932CC317-7EEB-49A2-A74F-6371E137F4A6@oracle.com> <1E4DB6BB-7950-4F26-B074-1CDCA8623D43@oracle.com> Message-ID: Thank you for the review! cheers > On Apr 28, 2016, at 4:39 AM, Volker Simonis wrote: > > Hi Gerard, > > the change looks good! > > Regards, > Volker > > > On Mon, Apr 18, 2016 at 4:53 PM, Gerard Ziemski > wrote: >> Thank you for the review Goetz! >> >> Can I have a second review for this simple fix please? >> >> In this fix we set the max range value to max_jlong (and change the type to uint64_t) since it gets assigned to MaxDirectMemorySize property that is later parsed as ?java long? (in java.base/VM.java:290) >> >> https://bugs.openjdk.java.net/browse/JDK-8153835 >> http://cr.openjdk.java.net/~gziemski/8153835_rev1/ >> >> Passes JPRT hotspot and RBT hotspot/test/runtime/CommandLine/OptionsValidation >> >> >> cheers >> From mikael.vidstedt at oracle.com Thu Apr 28 15:44:46 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 28 Apr 2016 08:44:46 -0700 Subject: RFR(S): 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <57220515.6080309@oracle.com> References: <570831BD.7080005@oracle.com> <570AF68B.9090707@oracle.com> <570C417F.20600@oracle.com> <571FB50E.6090108@oracle.com> <5720E0C8.608@oracle.com> <57220515.6080309@oracle.com> Message-ID: On 4/28/2016 5:41 AM, David Holmes wrote: > Hi Mikael, > > On 28/04/2016 1:54 AM, Mikael Vidstedt wrote: >> >> >> On 4/27/2016 12:24 AM, Thomas St?fe wrote: >>> Hi Mikael, >>> >>> On Tue, Apr 26, 2016 at 8:35 PM, Mikael Vidstedt >>> <mikael.vidstedt at oracle.com> wrote: >>> >>> >>> >>> On 4/12/2016 2:15 AM, Thomas St?fe wrote: >>>> Hi Mikael, David, >>>> >>>> On Tue, Apr 12, 2016 at 2:29 AM, David Holmes >>>> <david.holmes at oracle.com> wrote: >>>> >>>> On 11/04/2016 10:57 AM, David Holmes wrote: >>>> >>>> Hi Mikael, >>>> >>>> I think we need to be able to answer the question as to >>>> why the stubbed >>>> and stubless forms of this code exist to ensure that >>>> converting all >>>> platforms to the same form is appropriate. >>>> >>>> >>>> The more I look at this the more the stubs make no sense :) >>>> AIII a stub is generated when we need runtime code that may >>>> be different to that which we could write directly for >>>> compiling at build time - ie to use CPU specific features of >>>> the actual CPU. But I see nothing here that suggests any such >>>> usage. >>>> >>>> So I agree with removing the stubs. >>>> >>>> I'm still going through this but my initial reaction is >>>> to wonder why we >>>> don't use the same form of handle_unsafe_access on all >>>> platforms and >>>> always pass in npc? (That seems to be the only difference >>>> in code that >>>> otherwise seems platform independent.) >>>> >>>> >>>> Futher to this and Thomas's comments I think >>>> handle_unsafe_access(thread, pc, npc) can be defined in >>>> shared code (where? not sure). Further, if we always pass in >>>> npc then we don't need to pass in pc as it is unused (seems >>>> unused in original code too for sparc). >>>> >>>> >>>> I agree. We commonized ucontext_set_pc for all Posix platforms, >>>> so we can make a common function "handle_unsafe_access(thread, >>>> npc)" and inside use os::Posix::ucontext_set_pc to modify the >>>> context. Then we can get rid of the special handling in the >>>> signal handlers inside os_aix_ppc.cpp and os_linux_ppc.cpp (for >>>> both the compiled and the interpreted case). >>> >>> There is definitely room for unification and simplification here. >>> Right now the signal handling code is, sadly, different on all the >>> different platforms, despite the fact that in many cases it should >>> be similar or the exact same. That said, as much as a >>> refactoring/rewrite of the signal handler code is needed, it will >>> very quickly turn into a much larger effort... >>> >>> In this specific case, it would probably make more sense to pass >>> in the full context to the handle_unsafe_access method and have it >>> do whatever it feels is necessary to update it. However, a lot of >>> the signal handler code assumes that a "stub" variable gets set up >>> and only at the end of the main signal handler function does the >>> actual context get updated. Changing how that works only for this >>> specific case is obviously not a good idea, which means it's back >>> to the full scale refactoring and out of scope for the bug fix. >>> >>> So to me the fact that the method prototypes differ depending on >>> the exact platform is just a reflection of how the contexts >>> differ. In lack of the full context the handler method needs to >>> take whatever parts of the context is needed to do it's job. I >>> could of course change the handler method to only take a single >>> "next_pc" argument, but to me that feels like putting a key part >>> of the logic which handles the unsafe access (specifically, the >>> part which calculates the next pc) in the wrong place - IMHO that >>> should really be tightly coupled with the rest of the logic needed >>> to handle an unsafe access (updating the thread state etc.), and >>> hence I feel that it really belongs in the handle_unsafe_access >>> method itself. Happy to hear your thoughts, but I hope we can >>> agree that the suggested fix, even in its current state, is still >>> significantly better than what is there now. >>> >>> >>> Unless somebody has a better suggestion, I'm going to be moving >>> the implementations of the handle_unsafe_access methods to >>> sharedRuntime (instead of stubRoutines) and will send out a new >>> webrev shortly. >>> >>> >>> I am unhappy with the fact that we factor unsafe handling out for x86 >>> and sparc but do it inline for ppc. I know that was done before your >>> change as well but would be happy if that could be improved. I would >>> prefer either one of: >> >> Fully agree - this is an example of the more general problem of logic >> which is /almost/ the same across different platforms, but which has >> been effectively copy/pasted and drifted apart over time. >> >>> >>> 1) flatten out the coding into the signal handlers like it is done in >>> os_linux_ppc.cpp and os_aix_ppc.cpp or >>> 2) add a StubRoutines::ppc64::handle_unsafe_access() for the ppc case >>> >>> I would actually prefer (1) even though this would multiply the code >>> out for all os cases into ; we are only talking about 1-2 >>> lines of additional coding, and it would improve the readability of >>> the signal handlers. >>> >>> But this is only my personal opinion, and I do not have strong >>> emotions. I agree with you that a full cleanup of the signal coding is >>> out of scope for this issue. >> >> I spent yesterday going back and forth on the various alternatives and >> the only thing I can say with certainty now is that apart from >> refactoring the whole thing everything else is ugly... For example, I >> agree that consistency is an important goal here, but since there's >> little to no consistency there today it's really hard to make a relevant >> dent in it. :( >> >> Flattening it out is an alternative (and a good one), but that is not >> something I'm willing to do as part of this change because only >> flattening this specific case/return will actually add to the >> inconstency... So ultimately yesterday I chose to do something closer to >> your alternative 2). Is it still ugly? Yes; lipstick on pig and all of >> that. Have a look at it and see how you feel about it. I try to keep in >> mind that what is there today is (more) broken. :) >> >> Webrev: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.02/hotspot/webrev/ >> > > Now I see this in code form I really don't understand why next_pc is > passed in, unused and then returned ?? Given that the full context can't easily be passed in and updated (which I still think is the right, long term way of doing this), I chose to do it this way instead. It is a signal to a caller that *only* calling handle_unsafe_access is not enough, there's more to it in that the context also needs to be updated. I see it as a way to make sure the actual next_pc calculation and update is not forgotten, and make it clear that it goes hand in hand with updating the thread state. It's obviously not perfect, but I do feel like it ever so slightly helps clarify how the access fault needs to be handled. > > Otherwise in src/share/vm/runtime/sharedRuntime.cpp in the comment > block - capitals after periods please :) Fixed, I'll not post a new webrev for it though :) Cheers, Mikael > > Stub removal seems fine. > > Thanks, > David > >> Incremental from webrev.01: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.02.incr/hotspot/webrev/ >> >> >> Cheers, >> Mikael >> >>> >>> >>> Cheers, >>> Mikael >>> >>>> >>>> >>>> BTW I found this comment somewhat unfathomable (both now and >>>> in original code): >>>> >>>> + // pc is the instruction which we must emulate >>>> + // doing a no-op is fine: return garbage from the load >>>> >>>> but finally realized that it means that after the load that >>>> raised the signal the native code proceeds normally but the >>>> value apparently loaded is just garbage/arbitrary, and the >>>> only sign something went wrong is the setting of the pending >>>> unsafe-access-error bit. This would be a potential source of >>>> bugs I think, except that when we hit the Java level, we >>>> throw the exception and so never actually "return" the >>>> garbage value. But it does mean we would have to be careful >>>> if calling the unsafe routines from native code. >>>> >>>> >>>> I admit I do not understand fully how the >>>> _special_runtime_exit_condition flag is processed later, at least >>>> not for all cases: If I have a java method A using >>>> sun.misc.unsafe, which gets compiled, the sun.misc.unsafe >>>> intrinsic gets inlined into that method. So, the whole method A >>>> gets marked as "has unsafe access"? So, any SIGBUS happening >>>> inside this method - which may be larger than the inlined >>>> sun.misc.unsafe call - will yield an InternalError? And when is >>>> the flag checked if that method A is called from another java >>>> method B? >>>> >>>> Sorry if the questions are stupid, I am not a JIT expert, but I >>>> try to understand how much can happen between the SIGBUS and the >>>> InternalError getting thrown. >>> >>> No questions are stupid here. As you may have seen in the other >>> thread, I filed JDK-8154592[1] to cover making the handling of the >>> faults synchronous. Hope that helps. >>> >>> >>> Thank you! >>> >>> Kind Regards, Thomas >>> >>> Cheers, >>> Mikael >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8154592 >>> >>> >>>> >>>> Thanks, Thomas >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/04/2016 8:33 AM, Mikael Vidstedt wrote: >>>> >>>> >>>> Please review: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8153892 >>>> Webrev: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8153892/webrev.01/hotspot/webrev/ >>>> >>>> >>>> >>>> >>>> * Note: this is patch 2 in a set of 3 all aiming to >>>> clean up and unify >>>> the unsafe memory getters/setters, along with the >>>> handling of unsafe >>>> access errors. The other two issues are: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8153890 - >>>> Handle unsafe access >>>> error as an asynchronous exception >>>> https://bugs.openjdk.java.net/browse/JDK-8150921 - >>>> Update Unsafe >>>> getters/setters to use double-register variants >>>> >>>> >>>> * Summary (copied from the bug description) >>>> >>>> >>>> In certain cases, such as accessing a region of a >>>> memory mapped file >>>> which has been truncated on unix-style operating >>>> systems, a SIGBUS >>>> signal will be raised and the VM will process it in >>>> the signal handler. >>>> >>>> How the signal is processed differs depending on the >>>> operating system >>>> and/or CPU architecture, with two major alternatives: >>>> >>>> * "stubless" >>>> >>>> Do the necessary thread state updates directly in the >>>> signal handler, >>>> and modify the context so that the signal handler >>>> returns to the place >>>> where the execution should continue >>>> >>>> * Using a stub >>>> >>>> Update the context so that when the signal handler >>>> returns the thread >>>> will continue execution in a generated stub, which in >>>> turn will call >>>> some native code in the VM to update the thread state >>>> and figure out >>>> where execution should continue. The stub will then >>>> jump to that new >>>> place. >>>> >>>> >>>> It should be noted that the work of updating the >>>> thread state is very >>>> small - it's setting a flag or two in the thread >>>> structure, and figures >>>> out where the next instruction starts. It should also >>>> be noted that the >>>> generated stubs today are broken, because they do not >>>> preserve all the >>>> live registers over the call into the VM. There are >>>> two ways to address >>>> this: >>>> >>>> * Preserve all the necessary registers >>>> >>>> This would mean implementing, in macro assembly, the >>>> necessary logic for >>>> preserving all the live registers, including, but not >>>> limited to, >>>> floating point registers, flag registers, etc. It >>>> quickly becomes >>>> obvious that this platform specific and error prone. >>>> >>>> * Leverage the fact that the operating system already >>>> does this as part >>>> of the signal handling >>>> >>>> Do the necessary work in the signal handler instead, >>>> removing the need >>>> for the stub alltogether >>>> >>>> As mentioned, on some platforms the latter model is >>>> already in use. It >>>> is dramatically easier and all platforms should be >>>> updated to do it the >>>> same way. >>>> >>>> >>>> * Testing >>>> >>>> Just as mentioned in the RFR for JDK-8153890, a new >>>> test was developed >>>> to test this code path: >>>> >>>> http://cr.openjdk.java.net/~mikael/webrevs/8150921/MappedTruncated.java >>>> >>>> >>>> >>>> In fact, it was when running this test I found the >>>> register preservation >>>> issue. JPRT also passes. Much like JDK-8153890 I >>>> wanted to get some >>>> feedback on this before running additional tests. >>>> >>>> >>>> Cheers, >>>> Mikael >>>> >>>> >>> >>> >> From eric.caspole at oracle.com Thu Apr 28 21:58:02 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 28 Apr 2016 17:58:02 -0400 Subject: RFR: JDK-8155685 : Wrong indentation in ClassFileParser::post_process_parsed_stream Message-ID: Please review this small change to fix the indentation in ClassFileParser so this if-block lines up properly. http://cr.openjdk.java.net/~ecaspole/JDK-8155685/webrev/ Thanks, Eric From daniel.daugherty at oracle.com Thu Apr 28 22:28:43 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Apr 2016 16:28:43 -0600 Subject: RFR: JDK-8155685 : Wrong indentation in ClassFileParser::post_process_parsed_stream In-Reply-To: References: Message-ID: <57228E9B.60708@oracle.com> On 4/28/16 3:58 PM, Eric Caspole wrote: > Please review this small change to fix the indentation in > ClassFileParser so this if-block lines up properly. > > http://cr.openjdk.java.net/~ecaspole/JDK-8155685/webrev/ src/share/vm/classfile/classFileParser.cpp No comments. Thumbs up. Under the HotSpot Trivial Change rule, you don't have to wait 24 hours nor do you need another reviewer. Dan > > Thanks, > > Eric > From stefan.karlsson at oracle.com Fri Apr 29 08:15:07 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 29 Apr 2016 10:15:07 +0200 Subject: WeakReference cannot be GC'ed even no referent exists. In-Reply-To: References: Message-ID: <5723180B.2090300@oracle.com> Hi Yumin, On 2016-04-29 00:57, yumin qi wrote: > Hi, Runtime and GC team > > My last email with a typo on hotspot-gc-dev. So send again, sorry if > you receive multiple same content emails from me --- please add my > email in your reply since I could not see the email I sent out to open > alias. > As stated in the subject, found some weakly referenced object not > GC'ed. > > Code here is the test case we used to check for this problem. > > There are two classes AAA and AAB which are all loaded by the > TestClassLoader but different instances which are independent. > TestClassLoader extends from URLClassLoader. > > AAA has a field type of AAB which will be set to null in the test. > > public class AAA { > private AAB aab; > public AAA() { > aab = new AAB(); > } > public void clear() { > aab = null; > } > } > > public class AAB { > } > > The two class have to be in different jars(here AAA.jar contains > AAA.class, and AAB.jar contains AAB.jar), which are not in the class > path so are being loaded from different locations for the test. > > import java.net.URL; > import java.net.URLClassLoader; > import java.util.WeakHashMap; > > > public class TestLoader extends URLClassLoader { > public static WeakHashMap map=new > WeakHashMap(); > private static int count=0; > public TestLoader(URL[] urls){ > super(urls); > map.put(this, new Object()); > } > @SuppressWarnings("resource") > public Class loadClass(String name) throws > ClassNotFoundException { > if (name.equals("AAB") && count==0) { > try { > count=1; > URL[] urls = new URL[1]; > urls[0] = new > URL("file:///home/nijiaben/tmp/AAB.jar"); // You need to use your own > location for AAB.jar here!!! > return new TestLoader(urls).loadClass("AAB"); > } catch (Exception e){ > e.printStackTrace(); > } > } else { > return super.loadClass(name); > } > return null; > } > } > > TestLoader puts itself in the WeakHashMap --- upon "AAB" loading, it > uses new instance of TestLoader. the new Object is just a object as > value which has nothing to strongly or weakly to the key. > > TTest.java is the test program to start with, basically self explained. > > import java.lang.reflect.Method; > import java.net.URL; > > // Author: Jiapeng Li > > public class TTest { > private Object aaa; > public static void main(String args[]){ > try { > TTest tt = new TTest(); > //Move tt to old gen and clear aab in aaa > test(tt); > // do a final full GC, the TestLoader for aab should be > purged. > System.gc(); > System.out.println("finished"); // stop here in debugger > and dump heap > }catch (Exception e){ > e.printStackTrace(); > } > } > > @SuppressWarnings("resource") > public static void test(TTest tt){ > try { > // New instance of TestLoader which will load AAA from AAA.jar > URL[] urls = new URL[1]; > urls[0] = new URL("file:///home/nijiaben/tmp/AAA.jar"); > // You have to use your own location for AAA.jar here!!! > tt.aaa=new TestLoader(urls).loadClass("AAA").newInstance(); > // young GC will not purge the class loader, after 10 > times of full GC, it should move it to old gen > for (int i = 0; i < 10; i++) { > System.gc(); > Thread.sleep(1000); > } > // set aaa.aab= null?so next full gc will collect it > Method[] methods=tt.aaa.getClass().getDeclaredMethods(); > for (Method m : methods){ > if (m.getName().equals("clear")) { > m.invoke(tt.aaa); > break; > } > } > } catch (Exception e) { > e.printStackTrace(); > } > } > } > > After final full GC, there should be no instance of AAB exists, but > the instance of AAB's class loader (TestLoader) still not cleaned by > GC. See the stop point above, we dumped heap after final full GC. > Following is the graph for reference which still holds for the > WeakHashMap. > > Inline image 1 > > Notice that the dependency records the two instances of TestLoaders > in order that they are related, When AAA is loaded, it loads AAB and > after AAB loaded, dependency records the relationship in _dependencies. > > but we don't have 'remove' method to disengage them for GC. > When GC, _dependencies.oops_do, the is_alive Closure still marks the > TestLoader for AAB alive even though it has nothing to refer to due to > the dependency. > > void ClassLoaderData::oops_do(OopClosure* f, KlassClosure* > klass_closure, bool must_claim) { > if (must_claim && !claim()) { > return; > } > > f->do_oop(&_class_loader); > _dependencies.oops_do(f); > _handles->oops_do(f); > if (klass_closure != NULL) { > classes_do(klass_closure); > } > } > > Is this a bug or a design consideration? It's by design. The AAA class depends on the AAB class: public class AAA { private AAB aab; so AAB can't be unloaded unless AAA is also unloaded. StefanK > > Any comments are appreciated! > > Thanks From thomas.schatzl at oracle.com Fri Apr 29 08:54:44 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 29 Apr 2016 10:54:44 +0200 Subject: Does CollectedHeap::print_on() need Heap_lock? In-Reply-To: <570CFE91.1070706@gmail.com> References: <570CFE91.1070706@gmail.com> Message-ID: <1461920084.2923.40.camel@oracle.com> Hi Yasumasa, ? sorry for the long wait on this... On Tue, 2016-04-12 at 22:56 +0900, Yasumasa Suenaga wrote: > Hi all, > > I have a question about Heap_lock in Universe::print_*(). > > Universe::print_heap_at_SIGBREAK() gets Heap_lock. > However, HeapInfoDCmd::execute() and Universe::print_on() do not get > Heap_lock. > > Should we get Heap_lock when we print heap information? It is not required. The methods are only ever called at a safepoint.? > I guess that we should get this lock for consistency. That would be something that could be done, or just adding asserts/guarantees about the intended places to call (i.e. either at safepoint or heap locked - there should be some method like that somewhere actually). > > -------------------- > diff -r 87215e99d945 src/share/vm/memory/universe.cpp > --- a/src/share/vm/memory/universe.cpp??Wed Apr 06 23:42:52 2016 > +0000 > +++ b/src/share/vm/memory/universe.cpp??Tue Apr 12 22:23:17 2016 > +0900 > @@ -1069,6 +1069,7 @@ > ?} > > ?void Universe::print_on(outputStream* st) { > +??MutexLocker hl(Heap_lock); > ???st->print_cr("Heap"); > ???heap()->print_on(st); > ?} > diff -r 87215e99d945 src/share/vm/services/diagnosticCommand.cpp > --- a/src/share/vm/services/diagnosticCommand.cpp???????Wed Apr 06 > 23:42:52 2016 +0000 > +++ b/src/share/vm/services/diagnosticCommand.cpp???????Tue Apr 12 > 22:23:17 2016 +0900 > @@ -413,6 +413,7 @@ > ?} > > ?void HeapInfoDCmd::execute(DCmdSource source, TRAPS) { > +??MutexLocker hl(Heap_lock); > ???Universe::heap()->print_on(output()); > ?} > > -------------------- > > If it is correct, I file it to JBS and send review request. > Thanks, ? Thomas From yasuenag at gmail.com Fri Apr 29 12:12:19 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Apr 2016 21:12:19 +0900 Subject: Does CollectedHeap::print_on() need Heap_lock? In-Reply-To: <1461920084.2923.40.camel@oracle.com> References: <570CFE91.1070706@gmail.com> <1461920084.2923.40.camel@oracle.com> Message-ID: <40e173fa-1e27-96af-5868-cbcd1d5990f5@gmail.com> Hi Thomas, Thank you for replying. > It is not required. The methods are only ever called at a safepoint. No, it is called from Attach Listener thread. I run JDK 9 EA b112 x64 Linux on GDB, and I got call stack as below: ---------------- Breakpoint 2, 0x00007ffff659b970 in HeapInfoDCmd::execute(DCmdSource, Thread*) () from /usr/local/jdk-9/lib/amd64/server/libjvm.so (gdb) bt #0 0x00007ffff659b970 in HeapInfoDCmd::execute(DCmdSource, Thread*) () from /usr/local/jdk-9/lib/amd64/server/libjvm.so #1 0x00007ffff65a764c in DCmd::parse_and_execute(DCmdSource, outputStream*, char const*, char, Thread*) () from /usr/local/jdk-9/lib/amd64/server/libjvm.so #2 0x00007ffff633bf80 in jcmd(AttachOperation*, outputStream*) () from /usr/local/jdk-9/lib/amd64/server/libjvm.so #3 0x00007ffff633cca9 in attach_listener_thread_entry(JavaThread*, Thread*) () from /usr/local/jdk-9/lib/amd64/server/libjvm.so #4 0x00007ffff6b6f876 in JavaThread::thread_main_inner() () from /usr/local/jdk-9/lib/amd64/server/libjvm.so #5 0x00007ffff6b6f982 in JavaThread::run() () from /usr/local/jdk-9/lib/amd64/server/libjvm.so #6 0x00007ffff69faad2 in java_start(Thread*) () from /usr/local/jdk-9/lib/amd64/server/libjvm.so #7 0x00007ffff79b060a in start_thread (arg=0x7fffa490c700) at pthread_create.c:334 #8 0x00007ffff72d8a4d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 ---------------- According to you, I guess HeapInfoDCmd should enter safepoint or get Heap_lock. Is it correct? Thanks, Yasumasa On 2016/04/29 17:54, Thomas Schatzl wrote: > Hi Yasumasa, > > sorry for the long wait on this... > > On Tue, 2016-04-12 at 22:56 +0900, Yasumasa Suenaga wrote: >> Hi all, >> >> I have a question about Heap_lock in Universe::print_*(). >> >> Universe::print_heap_at_SIGBREAK() gets Heap_lock. >> However, HeapInfoDCmd::execute() and Universe::print_on() do not get >> Heap_lock. >> >> Should we get Heap_lock when we print heap information? > > It is not required. The methods are only ever called at a safepoint. > >> I guess that we should get this lock for consistency. > > That would be something that could be done, or just adding > asserts/guarantees about the intended places to call (i.e. either at > safepoint or heap locked - there should be some method like that > somewhere actually). > >> >> -------------------- >> diff -r 87215e99d945 src/share/vm/memory/universe.cpp >> --- a/src/share/vm/memory/universe.cpp Wed Apr 06 23:42:52 2016 >> +0000 >> +++ b/src/share/vm/memory/universe.cpp Tue Apr 12 22:23:17 2016 >> +0900 >> @@ -1069,6 +1069,7 @@ >> } >> >> void Universe::print_on(outputStream* st) { >> + MutexLocker hl(Heap_lock); >> st->print_cr("Heap"); >> heap()->print_on(st); >> } >> diff -r 87215e99d945 src/share/vm/services/diagnosticCommand.cpp >> --- a/src/share/vm/services/diagnosticCommand.cpp Wed Apr 06 >> 23:42:52 2016 +0000 >> +++ b/src/share/vm/services/diagnosticCommand.cpp Tue Apr 12 >> 22:23:17 2016 +0900 >> @@ -413,6 +413,7 @@ >> } >> >> void HeapInfoDCmd::execute(DCmdSource source, TRAPS) { >> + MutexLocker hl(Heap_lock); >> Universe::heap()->print_on(output()); >> } >> >> -------------------- >> >> If it is correct, I file it to JBS and send review request. >> > > Thanks, > Thomas > > From thomas.schatzl at oracle.com Fri Apr 29 12:35:19 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 29 Apr 2016 14:35:19 +0200 Subject: Does CollectedHeap::print_on() need Heap_lock? In-Reply-To: <40e173fa-1e27-96af-5868-cbcd1d5990f5@gmail.com> References: <570CFE91.1070706@gmail.com> <1461920084.2923.40.camel@oracle.com> <40e173fa-1e27-96af-5868-cbcd1d5990f5@gmail.com> Message-ID: <1461933319.2923.44.camel@oracle.com> Hi, On Fri, 2016-04-29 at 21:12 +0900, Yasumasa Suenaga wrote: > Hi Thomas, > > Thank you for replying. > > > > > It is not required. The methods are only ever called at a > > safepoint. > No, it is called from Attach Listener thread. > I run JDK 9 EA b112 x64 Linux on GDB, and I got call stack as below: > > ---------------- > Breakpoint 2, 0x00007ffff659b970 in HeapInfoDCmd::execute(DCmdSource, > Thread*) > ?????() from /usr/local/jdk-9/lib/amd64/server/libjvm.so > (gdb) bt > #0??0x00007ffff659b970 in HeapInfoDCmd::execute(DCmdSource, Thread*) > () > ????from /usr/local/jdk-9/lib/amd64/server/libjvm.so > #1??0x00007ffff65a764c in DCmd::parse_and_execute(DCmdSource, > outputStream*, char const*, char, Thread*) () from /usr/local/jdk- > 9/lib/amd64/server/libjvm.so > #2??0x00007ffff633bf80 in jcmd(AttachOperation*, outputStream*) () > ????from /usr/local/jdk-9/lib/amd64/server/libjvm.so > #3??0x00007ffff633cca9 in attach_listener_thread_entry(JavaThread*, > Thread*) () > ????from /usr/local/jdk-9/lib/amd64/server/libjvm.so > #4??0x00007ffff6b6f876 in JavaThread::thread_main_inner() () > ????from /usr/local/jdk-9/lib/amd64/server/libjvm.so > #5??0x00007ffff6b6f982 in JavaThread::run() () > ????from /usr/local/jdk-9/lib/amd64/server/libjvm.so > #6??0x00007ffff69faad2 in java_start(Thread*) () > ????from /usr/local/jdk-9/lib/amd64/server/libjvm.so > #7??0x00007ffff79b060a in start_thread (arg=0x7fffa490c700) > ?????at pthread_create.c:334 > #8??0x00007ffff72d8a4d in clone () > ?????at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > ---------------- > > According to you, I guess HeapInfoDCmd should enter safepoint or get > Heap_lock. > Is it correct? ? I always thought that DCmds doing heap operations tend to start a safepoint, but of course this is configurable. To get some kind of consistent view on the heap, print_on() should hold the heap lock or be at a safepoint. Thanks, ? Thomas From zgu at redhat.com Fri Apr 29 13:22:26 2016 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 29 Apr 2016 09:22:26 -0400 Subject: RFR(S): 8155105: Enhance guardedMemory to detect accessing released memory Message-ID: <57236012.1010005@redhat.com> This is a debug-only change that is intended to detect accessing released memory, ex. double-release a malloc'd memory. The approach is to rewrite the memory guards with "released" pattern and write the calling stack into user data area during os::free() call. As the result, verify_memory() check will result a failure if it sees "released" guards. Double-free is not obvious usually, as the memory can be reallocated before the second free(). Most of time, it appears to be a wild-pointer, -XX:TraceMemoryDoubleFree flag is intended to help to identify such scenario, by only building released guards, but not actually free the memory, so it can only help when double-free is caught before runs out of memory. When double-free is caught, the two free() call stacks are provided: ## nof_mallocs = 56722, nof_frees = 9099 ## memory stomp: GuardedMemory(0x00007f85a0a06c30) base_addr=0x00007f859af2f630 tag=0x0000000000000000 user_size=17 user_data=0x00007f859af2f650 Header guard @0x00007f859af2f630 is RELASED Trailer guard @0x00007f859af2f670 is RELASED User data appears to be releasing call stack From: [0x00007f859f150dc2] os::free(void*)+0x52 [0x00007f859ec79b5b] GuardedMemory::test_guarded_memory()+0x156b [0x00007f859ed02e44] InternalVMTests::run()+0x1d4 [0x00007f859ed58c15] JNI_CreateJavaVM+0x3e5 Memory has been released from: [0x00007f859ec79b53] GuardedMemory::test_guarded_memory()+0x1563 [0x00007f859ed02e44] InternalVMTests::run()+0x1d4 [0x00007f859ed58c15] JNI_CreateJavaVM+0x3e5 [0x00007f85a01ca753] JavaMain+0x83 Also, updated guarded memory tests to test on "base" pointer (returned by ::malloc()) vs "user" pointer (os::malloc()) to reflect real runtime scenarios. Bug:https://bugs.openjdk.java.net/browse/JDK-8155105 Webrev: http://cr.openjdk.java.net/~zgu/8155105/webrev/index.html Thanks, -Zhengyu From eric.caspole at oracle.com Fri Apr 29 13:38:13 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Fri, 29 Apr 2016 09:38:13 -0400 Subject: RFR: JDK-8155685 : Wrong indentation in ClassFileParser::post_process_parsed_stream In-Reply-To: <57228E9B.60708@oracle.com> References: <57228E9B.60708@oracle.com> Message-ID: <572363C5.8080201@oracle.com> Thanks Dan. Eric On 04/28/2016 06:28 PM, Daniel D. Daugherty wrote: > > > On 4/28/16 3:58 PM, Eric Caspole wrote: >> Please review this small change to fix the indentation in >> ClassFileParser so this if-block lines up properly. >> >> http://cr.openjdk.java.net/~ecaspole/JDK-8155685/webrev/ > > src/share/vm/classfile/classFileParser.cpp > No comments. > > Thumbs up. Under the HotSpot Trivial Change rule, you don't have > to wait 24 hours nor do you need another reviewer. > > Dan > > >> >> Thanks, >> >> Eric >> > > From yasuenag at gmail.com Fri Apr 29 14:05:35 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 29 Apr 2016 23:05:35 +0900 Subject: RFR: JDK-8155730: HeapInfoDCmd should get Heap_lock Message-ID: <955b8a22-d35c-60dc-e202-991b5a5e432d@gmail.com> Hi all, This review request is related to [1]. HeapInfoDCmd calls CollectedHeap::print_on(). However, its call does not get Heap_lock. Heap_lock should be gotten from all heap operations. I uploaded webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8155730/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019257.html From calvin.cheung at oracle.com Fri Apr 29 23:30:53 2016 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 29 Apr 2016 16:30:53 -0700 Subject: RFR(xs): 8152356: Change to -Xshare:auto for 32-bit platforms In-Reply-To: <6716B848-270C-4AF4-858F-8F1D22AA8C62@oracle.com> References: <5719CB6F.1080801@oracle.com> <5719D6A3.8070502@oracle.com> <571A9535.7040706@oracle.com> <4347ebd8-cfcf-5e41-55cf-9f9512f24073@oracle.com> <6716B848-270C-4AF4-858F-8F1D22AA8C62@oracle.com> Message-ID: <5723EEAD.4070300@oracle.com> Hi, I'm withdrawing this RFR as more investigations are required before enabling -Xshare:auto for all platforms. thanks, Calvin On 4/22/16, 5:18 PM, Jiangli Zhou wrote: > Christian, thank you for the information. It seems like INCLUD_JVMCI should be handled the same as COMPILER2 in this case. > > I agree with Vladimir?s view and prefer avoiding unnecessary complication. > > Thanks, > Jiangli > >> On Apr 22, 2016, at 4:17 PM, Vladimir Kozlov wrote: >> >>>> However the comments only explain the selection logic for 64-bit server. It would be helpful to find out why -Xshare:auto is off by default with INCLUDE_JVMCI enabled as part of your exercise. >>> There is no technical reason; INCLUDE_JVMCI was pretty much added everywhere where there is a #ifdef COMPILER2. >>> >> Note, the only one current implementation of JVMCI compiler, Graal, is available only for 64-bit VM. I don't think it will change in a future. >> >> I would more expect that we will stop supporting 32-bit Server VM on all platforms (may be except embedded) in a very near future. The only 32-bit platforms with Server VM are Win7, Win8 and Ubuntu. Win10 has only 64-bit VM. >> >> Based on this I question the need for this change only for 32-bit VM. I would prefer to see it for all configurations. It will simplify #if conditions you complain about. >> >> Note, changing from Client VM to Server VM will have much high impact on user experience on 32-bit platforms than using or not using CDS. >> >> David said: "Just because -Xshare:auto is the default, it doesn't mean we have to generate an archive as part of the install process. That is an independent action/decision. This RFE is simply asking the question "if there exists an archive should we use it by default?"" >> >> If we do 64-bit too it will not change default behavior for 64-bit VM since by default there will be no CDS archive installed. And checking if archive exists is very cheap. If needed we can say in release document that we support it only on 32-bit VM in jdk 9 (as before). >> >> And lastly I agree with complains that current condition when it is enabled it very complicated. We should just enable it by default and done with it. >> >> Thanks, >> Vladimir >> >> On 4/22/16 3:16 PM, Christian Thalinger wrote: >>>> On Apr 22, 2016, at 12:08 PM, Jiangli Zhou wrote: >>>> >>>> Hi Calvin, >>>> >>>> Please see comments below. >>>> >>>>> On Apr 22, 2016, at 2:18 PM, Calvin Cheung wrote: >>>>> >>>>> Hi David, >>>>> >>>>> Thanks for your review. >>>>> >>>>> On 4/22/16, 12:45 AM, David Holmes wrote: >>>>>> Hi Calvin, >>>>>> >>>>>> On 22/04/2016 4:57 PM, Calvin Cheung wrote: >>>>>>> Please review this small fix for enabling -Xshare:auto as the default >>>>>>> for 32-bit platforms. >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8152356 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8152356/webrev.00/ >>>>>> I find the selection logic for this to be almost unfathomable - and made worse by the conditional compilation! But looking at your changes: >>>>>> >>>>>> -#if defined(COMPILER2) || INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >>>>>> +#if INCLUDE_JVMCI || defined(_LP64) || !INCLUDE_CDS >>>>>> >>>>>> Ok - 64-bit implies compiler2 as we don't do 64-bit client, so this reduction is fine. >>>>>> >>>>>> -#if defined(COMPILER2) || INCLUDE_JVMCI >>>>>> +#if (defined(COMPILER2)&& defined(_LP64)) || INCLUDE_JVMCI >>>>>> >>>>>> Ok - we're relaxing the constraint so that we skip this code block for 32-bit compiler2. >>>>>> >>>>>> // Shared spaces work fine with other GCs but causes bytecode rewriting >>>>>> // to be disabled, which hurts interpreter performance and decreases >>>>>> - // server performance. When -server is specified, keep the default off >>>>>> - // unless it is asked for. Future work: either add bytecode rewriting >>>>>> - // at link time, or rewrite bytecodes in non-shared methods. >>>>>> + // server performance. After JDK-8074345, bytecode rewriting is enabled for >>>>>> + // non-shared classes. So share spaces should no longer affect the performance of >>>>>> + // benchmarks executed by C2. Enabling the default (-Xshare:auto) on 32-bit platforms when >>>>>> + // -server is specified. When -server is specified on a 64-bit platform, keep the default >>>>>> + // off unless it is asked for. >>>>>> >>>>>> I'm not a fan of history lessons in comments - they tend to only make sense at the time of writing. If the code works fine now then it works fine now, we don't need to document that it didn't used to work fine but bug XXX fixed it. I'd simplify the comment to just state what exactly you are checking for, because to be honest I find this: >>>>>> >>>>>> if (!DumpSharedSpaces&& !RequireSharedSpaces&& >>>>>> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >>>>>> >>>>>> very hard to unwravel. The first part is fine - not dumping. The second part indicates we are either in -Xshare:off or -Xshare:auto. But the third part is quite puzzling - and even when I think I have it figured out I can't reconcile with what I see when I use -XX:+PrintFlagsFinal. So the "what are we doing" is much more important to comment than the history. >>>>> How about the following? >>>>> >>>>> // skip the following block of code for 32-bit platforms >>>>> #if (defined(COMPILER2)&& defined(_LP64)) || INCLUDE_JVMCI >>>>> // For 64-bit compiler2 (-server), keep the default sharing off unless >>>>> // it is enabled via -Xshare:on. >>>>> if (!DumpSharedSpaces&& !RequireSharedSpaces&& >>>>> (FLAG_IS_DEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { >>>>> no_shared_spaces("COMPILER2 default: -Xshare:auto | off, have to manually setup to on."); >>>>> } >>>>> #endif >>>> I felt the same as David when looking at the code. The above simplified comment looks better. However the comments only explain the selection logic for 64-bit server. It would be helpful to find out why -Xshare:auto is off by default with INCLUDE_JVMCI enabled as part of your exercise. >>> There is no technical reason; INCLUDE_JVMCI was pretty much added everywhere where there is a #ifdef COMPILER2. >>> >>>> Thanks, >>>> >>>> Jiangli >>>> >>>>>> --- >>>>>> >>>>>> Query: In the tests, should they be @driver rather than @run ? >>>>> I think you meant the following? >>>>> @run driver >>>>> >>>>> From the jtreg documentation: >>>>>> driver[/fail][/timeout=] * >>>>>> Invoke the main method of the specified class, passing any arguments after the class name. Although superficially similar to @run main, this is for use when it is desirable to perform additional setup or configuration before running the class containing the actual test code, possibly in a child VM. >>>>>> >>>>>> The named will be compiled on demand, just as though an "@run build" action had been inserted before this action. If this action requires classes other than to be up to date, insert an appropriate build action before this action. >>>>> For the 2 tests in this change, there's no setup or configuration step required. >>>>> So I think it is unnecessary to use "driver" action. >>>>> >>>>> I did try the 2 tests with the "driver" action and they worked as well. >>>>> e.g. @run driver DefaultSharing >>>>> >>>>> Let me know if you want to see a new webrev with the changes above. >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Testing: >>>>>>> JPRT >>>>>>> jtreg tests under hotspot/test/runtime >>>>>>> >>>>>>> thanks, >>>>>>> Calvin From sundararajan.athijegannathan at oracle.com Wed Apr 27 12:42:02 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 27 Apr 2016 12:42:02 -0000 Subject: RFR(S) 8151342: Add module name/version to class histogram output In-Reply-To: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> References: <5660dade-8a16-6e52-453b-8645e13eecea@oracle.com> Message-ID: <4dae9adb-c85b-fc50-3936-5870c0ca1d8c@oracle.com> +1 PS. Don't we have to update the SA code that dumps histogram so that -F mode output would be similar? -Sundar On 4/27/2016 6:04 PM, harold seigel wrote: > Hi, > > Please review this small change to add module information to the class > histogram displayed by tools such as jmap and jcmd. The module name > and version will follow the class name and be enclosed in > parentheses. Classes not in modules will not contain module > information. For example: > > num #instances #bytes class name (module) > ------------------------------------------------------- > 1: 7892 1575952 [B (java.base at 9-internal) > 2: 1783 214672 java.lang.Class > (java.base at 9-internal) > 3: 5749 183968 java.util.HashMap$Node > (java.base at 9-internal) > 4: 7081 169944 java.lang.String > (java.base at 9-internal) > 5: 1881 95312 [Ljava.lang.Object; > (java.base at 9-internal) > 6: 785 90832 [I (java.base at 9-internal) > ... > 16: 1024 16384 ClassHistogramTest$TestClass > ... > > > Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8151342/ > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8151342 > > The fix was tested with JCK Lang, and VM tests, the UTE colocated and > non-colocated quick tests, and the JTreg jdk_svc, hotspot, JDK > java/io, java/lang, java/util, and java/security tests. > > Thanks, Harold >