From kim.barrett at oracle.com Fri Feb 1 00:44:22 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 31 Jan 2019 19:44:22 -0500 Subject: RFR: 8218164: Improve local control of compiler warnings Message-ID: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> Please review this extension to the existing support for locally disabling various compiler warnings. There are also a few updates of existing code to use the new mechanisms. (There are some additional opportunities to use these new mechanisms, but some were in code that Oracle doesn't test, like Win32, so I left them alone.) (Obviously one should not disable warnings lightly, but sometimes one does what one must.) There are several pieces to this change. First, utilities/compilerWarnings.hpp is refactored to have compiler-specific variants, similar to globalDefinitions.hpp. This hadn't been done previously because only gcc (and clang) had non-trivial definitions. Second, implemented PRAGMA_DIAG_PUSH/POP for Visual Studio. Still no implementations for xlc or solstudio though. Third, added a couple of compiler-specific warning disabling macros: PRAGMA_DISABLE_GCC_WARNING(option_string) // also applies to clang PRAGMA_DISABLE_MSVCPP_WARNING(num) They have useful implementations for the respective compilers and empty definitions otherwise. (I'm open to suggestions for better names, esp. for "MSVCPP".) CR: https://bugs.openjdk.java.net/browse/JDK-8218164 Webrev: http://cr.openjdk.java.net/~kbarrett/8218164/open.00/ Testing: mach5 tier1 From serguei.spitsyn at oracle.com Fri Feb 1 02:01:20 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jan 2019 18:01:20 -0800 Subject: RFR(T)[12] : 8218168 : clean up hotspot ProblemList In-Reply-To: References: Message-ID: <0bf5381b-8f0f-292b-3bfb-321ab0bd0277@oracle.com> Looks good. Thanks, Serguei On 1/31/19 1:42 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8218168/webrev.00/index.html >> 10 lines changed: 0 ins; 0 del; 10 mod; > Hi all, > > JDK-8208255 and JDK-8208235 got closed as a duplicate of JDK-8058176 but still referenced in the problem list, this trivial patch is to fix that. > > webrev: http://cr.openjdk.java.net/~iignatyev//8218168/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8218168 > > Thanks, > -- Igor From david.holmes at oracle.com Fri Feb 1 04:23:46 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 14:23:46 +1000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi Matthias, On 1/02/2019 12:50 am, Baesken, Matthias wrote: > Please review this small webrev . It contains a few changes for building hotspot on AIX with xlclang++ / xlc16 . > ( most likely switching to xlclang++ / xlc16 will be a must once we introduce C++11/14 features ) > > Some comments on the changes : > > > - porting_aix.cpp : workaround for demangle.h (does not work with xlclang++) Can't comment as I know nothing about it. > - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to assigning false to AllocateHeapAt which is a bad idea (and does not work with xlclang++) Good catch! > - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not have #error ... in this case Confused. Which other xlc compilers set __GNUC_ as you are changing this for all of them? Though to be honest I don't understand this whole section anyway - we have a lengthy comment saying why you can't necessarily assign NULL to an integer type and to use NULL_WORD instead but then it's defined as NULL anyway! I wonder if we used to have some other conditions there where it was something different? In any case having an if and else that do exactly the same thing seems rather pointless to me. Thanks, David > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218136 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ > > > Thanks, Matthias > From david.holmes at oracle.com Fri Feb 1 04:42:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 14:42:42 +1000 Subject: RFR(T)[12] : 8218168 : clean up hotspot ProblemList In-Reply-To: References: Message-ID: <84d3e6c9-c0c7-164c-165b-d7fa22d006ee@oracle.com> Looks good. Thanks, David On 1/02/2019 7:42 am, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8218168/webrev.00/index.html >> 10 lines changed: 0 ins; 0 del; 10 mod; > > Hi all, > > JDK-8208255 and JDK-8208235 got closed as a duplicate of JDK-8058176 but still referenced in the problem list, this trivial patch is to fix that. > > webrev: http://cr.openjdk.java.net/~iignatyev//8218168/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8218168 > > Thanks, > -- Igor > From kim.barrett at oracle.com Fri Feb 1 04:56:50 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 31 Jan 2019 23:56:50 -0500 Subject: RFR (S) 8218151: Simplify JavaThread::thread_state definition In-Reply-To: References: Message-ID: <3A324A27-CBA0-44AD-A9F5-0DAAE85AAE68@oracle.com> > On Jan 31, 2019, at 4:13 PM, Aleksey Shipilev wrote: > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8218151 > > Fix: > http://cr.openjdk.java.net/~shade/8218151/webrev.01/ > > The difference in definitions in JavaThread::thread_state in AArch64 and PPC64 is the source of > frequent build failures when someone tests only x86_64, see the linked issues for a taste. The way > out of this is to push the #if-s inside the method body, so that definition is always in one place, > and would not accidentally break the build. > > Testing: Linux {x86_64, x86_32, aarch64, arm32, ppc64el, s390x} builds, Mac OS X {x86_64} build, > Windows {x86_64} build, jdk-submit (failed windows test and macos build, but I suspect there are > infra problems, will wait and re-run; see for example mach5-one-shade-JDK-8218151-20190131-1631-233989). > > Thanks, > -Aleksey So why are the definitions different, using OrderAccess for PPC64 and AARCH64, but not for other platforms? Why not unconditionally use OrderAccess? If that's needed for some weakly ordered architectures, seems like it should be needed for all. And for TSO the OrderAccess operations shouldn't introduce any additional overhead. From david.holmes at oracle.com Fri Feb 1 05:03:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 15:03:06 +1000 Subject: RFR (S) 8218140: Build failures after JDK-8218041 (Assorted wrong/missing includes) In-Reply-To: <99330653-3685-e6ae-c092-b732480dc66d@oracle.com> References: <6dd0ada4-22bd-69ad-8118-18b805d9ed5f@redhat.com> <4e6056ad-cd9c-166c-3918-26933a5c77bd@oracle.com> <99330653-3685-e6ae-c092-b732480dc66d@oracle.com> Message-ID: <158edee0-5f7c-8d57-7285-04c7069fbac1@oracle.com> On 31/01/2019 11:09 pm, Robbin Ehn wrote: > Looks good, thanks. > > In this case I would not blame 8218041, since these file don't even had > thread.hpp included, the 'bug' is pre-existing. They got thread.inline.hpp through handles.inline.hpp But yes should be explicit. If only there was a tool that could generate the correct set of includes ... ;-) David > /Robbin > > On 1/31/19 1:40 PM, Aleksey Shipilev wrote: >> AArch64 has "special" relationship with thread.inline.hpp -- >> JavaThread::thread_state() is defined >> as such: >> >> src/hotspot/share/runtime/thread.inline.hpp: >> >> #if defined(PPC64) || defined (AARCH64) >> inline JavaThreadState JavaThread::thread_state() const??? { >> ?? return (JavaThreadState) OrderAccess::load_acquire((volatile >> jint*)&_thread_state); >> } >> >> inline void JavaThread::set_thread_state(JavaThreadState s) { >> ?? OrderAccess::release_store((volatile jint*)&_thread_state, (jint)s); >> } >> #endif >> >> Which does break aarch64 every once in a while: >> ?? https://bugs.openjdk.java.net/browse/JDK-8216591 >> ?? https://bugs.openjdk.java.net/browse/JDK-8203278 >> ?? https://bugs.openjdk.java.net/browse/JDK-8201799 >> >> ...and shared files have to include that thread.inline.hpp then. >> >> -Aleksey >> >> On 1/31/19 1:32 PM, David Holmes wrote: >>> cc'ing Robbin. >>> >>> I can understand the Aaarch64 specific file may have an issue but I >>> don't see how we can still have >>> shared files that need changing. >>> >>> ??? >>> >>> David >>> >>> On 31/01/2019 10:26 pm, Aleksey Shipilev wrote: >>>> Bug: >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8218140 >>>> >>>> Fix: >>>> ?? http://cr.openjdk.java.net/~shade/8218140/webrev.01/ >>>> >>>> Testing: Linux {x86_64, aarch64} compilation >>>> >>>> Maybe some other platforms are failing too? I would be happy to fold >>>> their fixes into this patch. So >>>> far I see only AArch64 is broken. >>>> >>>> -Aleksey >>>> >> >> From patricio.chilano.mateo at oracle.com Fri Feb 1 05:05:26 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 1 Feb 2019 00:05:26 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> Message-ID: <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> Hi David, On 1/31/19 12:54 AM, David Holmes wrote: > On 31/01/2019 7:37 am, Patricio Chilano wrote: >> Hi David, >> >> On 1/30/19 2:29 AM, David Holmes wrote: >>> Hi Patricio, >>> >>> >>> >>> First, thanks for all the many weeks of work you've put into this, >>> pulling together a number of ideas from different people to make it >>> all work! >> Thanks! Credit to you for the PlatformMonitor implementation? : ) > > :) Nothing innovative there. > >>> I've only got a few minor comments/suggestions. >>> >>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>> >>> >>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>> >>> I'm very unclear how ThreadLockBlockInVM differs from >>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>> masking the actual difference between the two wrappers to me. It >>> seems to me that an extra arg to transition_and_fence should allow >>> you to handle the new behaviour without having to duplicate so much >>> of this code. In any case the semantics of ThreadLockBlockInVM needs >>> to be described. >> I could do it with one extra argument, but I would need to add two >> extra branches in transition_and_fence(), one to decide if I'm in the >> Monitor case to avoid calling >> SafepointMechanism::block_if_requested() directly and another one to >> actually decide if I'm transitioning in or out, since the actions to >> perform are different. I think it is easier to read without adding >> new conditionals, and also we will save those extra branches, but if >> you think it's better this way I can change it. > > I would like something that tells me more clearly how this new > transition helper differs from the existing TBIVM. Sharing the code > between them and using different args would be one way. Documenting > the difference in comments would be another. Your choice. Ok, I added a description on top of TLBIVM. >>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>> refers to. I find the name quite jarring to read. >> What about changing it to ThreadBlockinMonitor? > > That's not quite conveying the semantics. The problem is that the > semantics we are changing compared to TBIVM are not evident in the > TBIVM name. If TBIVM was actually > ThreadBlockInVMWithSafepointBlocking, then this new transition would > obviously be ThreadBlockInVMWithoutSafepointBlocking - but perhaps > that lengthy, but clear name would be okay anyway? Not convinced on that name since we are blocking at safepoints in the destructor. Based on the comments I added how about ThreadBlockinVMWithDeadlockPrevention ? or ThreadBlockinVMWithPreemption? (as in eliminate one of the conditions for deadlocks). >>> On the subject of naming, do_preempt and preempt_by_safepoint don't >>> really convey to me what happens - what is being "preempted" here? I >>> would suggest a more direct Monitor::release_for_safepoint >> Changed. >> >>> --- >>> >>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>> relate to a "native" monitor?? Actually I'm not even sure if we need >>> bother at all with the one logging statement that is present. >> I added it to eventually track unbounded try locks. Not sure I follow >> you with the name, isn't that how we name this monitors? I tried to >> differentiate them from Java monitors. What about just "monitor"? > > How about vmmonitor ? Ok, changed. >>> --- >>> >>> src/hotspot/share/runtime/mutex.cpp >>> >>> void Monitor::lock_without_safepoint_check(Thread * self) { >>> ? // Ensure that the Monitor does not require or allow safepoint >>> checks. >>> >>> The comment there should only say "not require". >> Done. >> >>> void Monitor::preempt_by_safepoint() { >>> ? _lock.unlock(); >>> } >>> >>> Apart from renaming this as suggested above, aren't there any >>> suitable assertions we should have here? safepoint-in-progress or >>> handshake-in-progress? _owner == Thread::current? >> Ok, I added an assertion that owner should be NULL. Asserting >> safepoint-in-progress does not really work because _state could >> change to _not_synchronized right after you checked for it in TLBIVM. > > Okay. > >>> Nit: >>> >>> assert(_owner == Thread::current(), "should be equal: owner=" >>> INTPTR_FORMAT >>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>> p2i(Thread::current())); >>> >>> with Dan's enhanced assertions there's an indentation issue. The >>> second line should indent to the first comma, but that will make the >>> second line extend way past 80 columns. >>> >>> Also you could factor that assertion for _owner==Thread::current() >>> into its own function or macro to avoid the repetition. >> Corrected indentation based on Dan's reply to align with _owner. > > I though it should indent to the comma because it is a continuation of > the same argument being passed to the assert "function". But I'm okay > with Dan's suggestion. > > Factoring it into its own little function or macro would still be good > to avoid the repetition. Ok, added new function assert_owned_by_self(). I could change it to assert_owner(Thread*) and use it for the NULL case too unifying the printed messages to something like "invalid owner: owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>> ?OSThreadWaitState osts(self->osthread(), false /* not Object.wait() >>> */); >>> >>> This needs to be returned to its original place as per Dan's comments. >> Done. >> >>> ??? } else { >>> ????? Monitor::lock(self); >>> ??? } >>> >>> You don't need Monitor:: here >> Removed. >> >>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>> PlatformMonitor now. >>> >>> This needs to be resolved before committing. Some of the existing >>> commentary on what raw monitors are needs to be retained. Not clear >>> if we need to set the _owner field or can just skip it. >> Is it okay if I keep the following comments? >> >> // Yet another degenerate version of Monitor::lock() or >> lock_without_safepoint_check() >> // jvm_raw_lock() and _unlock() can be called by non-Java threads via >> JVM_RawMonitorEnter. >> // >> // There's no expectation that JVM_RawMonitors will interoperate >> properly with the native >> // Mutex-Monitor constructs.? We happen to implement JVM_RawMonitors >> in terms of >> // native Mutex-Monitors simply as a matter of convenience. > > Yep that's perfect. And as a future RFE we can replace them with > direct use of PlatformMonitor (or PlatformMutex). > >> >> I could keep setting the owner as _owner = Thread::current_or_null() >> in jvm_raw_lock(), at least it wouldn't hurt. > > It's useful for checking usage errors, but we won't have that if we > replace with PlatformMonitor, so may as well drop it now IMO. Ok, I added asserts that _owner should be NULL after acquiring it and before releasing it though. >>> Monitor::~Monitor() { >>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>> p2i(_owner)); >>> } >>> >>> Will this automatically result in the PlatformMonitor destructor >>> being called? >> Yes, should I add a comment to make it clear that ~PlatformMonitor() >> will be executed? > > No need - assume other people have a better understanding of C++ than > I do :) Below is version v04, which also contains a correction pointed out off-list by Robbin to do a local poll first in SafepointMechanism::callback_if_safepoint() if we are using local polls. Since the thread local poll is armed after changing _state to _synchronizing, if we only do a global poll in the TLBIVM constructor we could detect there is a safepoint in progress and callback but when coming back in the destructor SafepointMechanism::should_block() could miss detecting the safepoint in progress since that method checks first for local polls. Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ Thanks, Patricio > Thanks, > David > >> >> >> Thanks for looking into this! Waiting on your comments to send v04. >> >> Thanks, >> Patricio >>> --- >>> >>> Thanks, >>> David >>> ----- >>> >> From david.holmes at oracle.com Fri Feb 1 05:08:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 15:08:31 +1000 Subject: RFR (S) 8218151: Simplify JavaThread::thread_state definition In-Reply-To: <3A324A27-CBA0-44AD-A9F5-0DAAE85AAE68@oracle.com> References: <3A324A27-CBA0-44AD-A9F5-0DAAE85AAE68@oracle.com> Message-ID: Hi Kim, On 1/02/2019 2:56 pm, Kim Barrett wrote: >> On Jan 31, 2019, at 4:13 PM, Aleksey Shipilev wrote: >> >> RFE: >> https://bugs.openjdk.java.net/browse/JDK-8218151 >> >> Fix: >> http://cr.openjdk.java.net/~shade/8218151/webrev.01/ >> >> The difference in definitions in JavaThread::thread_state in AArch64 and PPC64 is the source of >> frequent build failures when someone tests only x86_64, see the linked issues for a taste. The way >> out of this is to push the #if-s inside the method body, so that definition is always in one place, >> and would not accidentally break the build. >> >> Testing: Linux {x86_64, x86_32, aarch64, arm32, ppc64el, s390x} builds, Mac OS X {x86_64} build, >> Windows {x86_64} build, jdk-submit (failed windows test and macos build, but I suspect there are >> infra problems, will wait and re-run; see for example mach5-one-shade-JDK-8218151-20190131-1631-233989). >> >> Thanks, >> -Aleksey > > So why are the definitions different, using OrderAccess for PPC64 and > AARCH64, but not for other platforms? Why not unconditionally use > OrderAccess? If that's needed for some weakly ordered architectures, > seems like it should be needed for all. And for TSO the OrderAccess > operations shouldn't introduce any additional overhead. The other ports put the membars in the calling code where needed, but PPC64 and Aarch64 folk wanted acquire/release semantics. At least that is my recollection. The Oracle PPC32 and ARM64 ports did not need them. Cheers, David From david.holmes at oracle.com Fri Feb 1 05:10:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 15:10:04 +1000 Subject: RFR (S) 8218151: Simplify JavaThread::thread_state definition In-Reply-To: References: Message-ID: <8abec213-1f4c-f445-ea0d-e2c7dd63fe08@oracle.com> Hi Aleksey, Looks good. Having both variants in the same place makes much more sense - even if it does make the difference of opinion on how _thread_state should be accessed more blatant :) Thanks, David On 1/02/2019 7:13 am, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8218151 > > Fix: > http://cr.openjdk.java.net/~shade/8218151/webrev.01/ > > The difference in definitions in JavaThread::thread_state in AArch64 and PPC64 is the source of > frequent build failures when someone tests only x86_64, see the linked issues for a taste. The way > out of this is to push the #if-s inside the method body, so that definition is always in one place, > and would not accidentally break the build. > > Testing: Linux {x86_64, x86_32, aarch64, arm32, ppc64el, s390x} builds, Mac OS X {x86_64} build, > Windows {x86_64} build, jdk-submit (failed windows test and macos build, but I suspect there are > infra problems, will wait and re-run; see for example mach5-one-shade-JDK-8218151-20190131-1631-233989). > > Thanks, > -Aleksey > From david.holmes at oracle.com Fri Feb 1 05:34:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 15:34:44 +1000 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> Message-ID: <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Hi Patricio, Comments on inc v4: src/hotspot/share/runtime/safepointMechanism.inline.hpp + if(!uses_thread_local_poll() || local_poll_armed(thread)) { Need space after if. I trust Robbin's judgement that this is the right way to express this, but if ordering is so critical it should be documented. --- src/hotspot/share/runtime/mutex.hpp/.cpp assert_owned_by_self doesn't need to be a member function, it can just be a file static in the .cpp file. No need to clutter the API. Using a version that takes the owner thread is a good idea for checking the NULL case too. --- src/hotspot/share/runtime/interfaceSupport.inline.hpp I like the comment block - thanks! A couple of minor things: + // are trying to acquire. This will be used to access and release the monitor in case needed to avoid s/in case/if/ + // the monitor that is in the process of being acquired (only setting the owner is missing). I think the part in parentheses can be dropped - it reads like you should be setting the owner but have chosen not to for some reason. + // The logic of this class could have been integrated into a more general ThreadBlockInVM. By using a + // separate class though, we avoid executing branches that would otherwise be needed to identify each + // case. Not necessary IMHO but up to you whether to keep or drop. In regards to the name ThreadLockBlockInVM ... I don't have a good suggestion. ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is rather unwieldy. ;-) But the "Lock" part really doesn't mean anything. So your suggestion of ThreadBlockinVMWithDeadlockPrevention seems a big improvement to me. :) Thanks, David ----- On 1/02/2019 3:05 pm, Patricio Chilano wrote: > Hi David, > > On 1/31/19 12:54 AM, David Holmes wrote: >> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>> Hi David, >>> >>> On 1/30/19 2:29 AM, David Holmes wrote: >>>> Hi Patricio, >>>> >>>> >>>> >>>> First, thanks for all the many weeks of work you've put into this, >>>> pulling together a number of ideas from different people to make it >>>> all work! >>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >> >> :) Nothing innovative there. >> >>>> I've only got a few minor comments/suggestions. >>>> >>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>> >>>> >>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>> >>>> I'm very unclear how ThreadLockBlockInVM differs from >>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>> masking the actual difference between the two wrappers to me. It >>>> seems to me that an extra arg to transition_and_fence should allow >>>> you to handle the new behaviour without having to duplicate so much >>>> of this code. In any case the semantics of ThreadLockBlockInVM needs >>>> to be described. >>> I could do it with one extra argument, but I would need to add two >>> extra branches in transition_and_fence(), one to decide if I'm in the >>> Monitor case to avoid calling >>> SafepointMechanism::block_if_requested() directly and another one to >>> actually decide if I'm transitioning in or out, since the actions to >>> perform are different. I think it is easier to read without adding >>> new conditionals, and also we will save those extra branches, but if >>> you think it's better this way I can change it. >> >> I would like something that tells me more clearly how this new >> transition helper differs from the existing TBIVM. Sharing the code >> between them and using different args would be one way. Documenting >> the difference in comments would be another. Your choice. > Ok, I added a description on top of TLBIVM. > >>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>> refers to. I find the name quite jarring to read. >>> What about changing it to ThreadBlockinMonitor? >> >> That's not quite conveying the semantics. The problem is that the >> semantics we are changing compared to TBIVM are not evident in the >> TBIVM name. If TBIVM was actually >> ThreadBlockInVMWithSafepointBlocking, then this new transition would >> obviously be ThreadBlockInVMWithoutSafepointBlocking - but perhaps >> that lengthy, but clear name would be okay anyway? > Not convinced on that name since we are blocking at safepoints in the > destructor. Based on the comments I added how about > ThreadBlockinVMWithDeadlockPrevention ? or > ThreadBlockinVMWithPreemption? (as in eliminate one of the conditions > for deadlocks). > >>>> On the subject of naming, do_preempt and preempt_by_safepoint don't >>>> really convey to me what happens - what is being "preempted" here? I >>>> would suggest a more direct Monitor::release_for_safepoint >>> Changed. >>> >>>> --- >>>> >>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>> relate to a "native" monitor?? Actually I'm not even sure if we need >>>> bother at all with the one logging statement that is present. >>> I added it to eventually track unbounded try locks. Not sure I follow >>> you with the name, isn't that how we name this monitors? I tried to >>> differentiate them from Java monitors. What about just "monitor"? >> >> How about vmmonitor ? > Ok, changed. > >>>> --- >>>> >>>> src/hotspot/share/runtime/mutex.cpp >>>> >>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>> ? // Ensure that the Monitor does not require or allow safepoint >>>> checks. >>>> >>>> The comment there should only say "not require". >>> Done. >>> >>>> void Monitor::preempt_by_safepoint() { >>>> ? _lock.unlock(); >>>> } >>>> >>>> Apart from renaming this as suggested above, aren't there any >>>> suitable assertions we should have here? safepoint-in-progress or >>>> handshake-in-progress? _owner == Thread::current? >>> Ok, I added an assertion that owner should be NULL. Asserting >>> safepoint-in-progress does not really work because _state could >>> change to _not_synchronized right after you checked for it in TLBIVM. >> >> Okay. >> >>>> Nit: >>>> >>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>> INTPTR_FORMAT >>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>> p2i(Thread::current())); >>>> >>>> with Dan's enhanced assertions there's an indentation issue. The >>>> second line should indent to the first comma, but that will make the >>>> second line extend way past 80 columns. >>>> >>>> Also you could factor that assertion for _owner==Thread::current() >>>> into its own function or macro to avoid the repetition. >>> Corrected indentation based on Dan's reply to align with _owner. >> >> I though it should indent to the comma because it is a continuation of >> the same argument being passed to the assert "function". But I'm okay >> with Dan's suggestion. >> >> Factoring it into its own little function or macro would still be good >> to avoid the repetition. > Ok, added new function assert_owned_by_self(). I could change it to > assert_owner(Thread*) and use it for the NULL case too unifying the > printed messages to something like "invalid owner: owner=" INTPTR_FORMAT > ", should be:" INTPTR_FORMAT. What do you think? > >>>> ?OSThreadWaitState osts(self->osthread(), false /* not Object.wait() >>>> */); >>>> >>>> This needs to be returned to its original place as per Dan's comments. >>> Done. >>> >>>> ??? } else { >>>> ????? Monitor::lock(self); >>>> ??? } >>>> >>>> You don't need Monitor:: here >>> Removed. >>> >>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>> PlatformMonitor now. >>>> >>>> This needs to be resolved before committing. Some of the existing >>>> commentary on what raw monitors are needs to be retained. Not clear >>>> if we need to set the _owner field or can just skip it. >>> Is it okay if I keep the following comments? >>> >>> // Yet another degenerate version of Monitor::lock() or >>> lock_without_safepoint_check() >>> // jvm_raw_lock() and _unlock() can be called by non-Java threads via >>> JVM_RawMonitorEnter. >>> // >>> // There's no expectation that JVM_RawMonitors will interoperate >>> properly with the native >>> // Mutex-Monitor constructs.? We happen to implement JVM_RawMonitors >>> in terms of >>> // native Mutex-Monitors simply as a matter of convenience. >> >> Yep that's perfect. And as a future RFE we can replace them with >> direct use of PlatformMonitor (or PlatformMutex). >> >>> >>> I could keep setting the owner as _owner = Thread::current_or_null() >>> in jvm_raw_lock(), at least it wouldn't hurt. >> >> It's useful for checking usage errors, but we won't have that if we >> replace with PlatformMonitor, so may as well drop it now IMO. > Ok, I added asserts that _owner should be NULL after acquiring it and > before releasing it though. > >>>> Monitor::~Monitor() { >>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>> p2i(_owner)); >>>> } >>>> >>>> Will this automatically result in the PlatformMonitor destructor >>>> being called? >>> Yes, should I add a comment to make it clear that ~PlatformMonitor() >>> will be executed? >> >> No need - assume other people have a better understanding of C++ than >> I do :) > > Below is version v04, which also contains a correction pointed out > off-list by Robbin to do a local poll first in > SafepointMechanism::callback_if_safepoint() if we are using local polls. > Since the thread local poll is armed after changing _state to > _synchronizing, if we only do a global poll in the TLBIVM constructor we > could detect there is a safepoint in progress and callback but when > coming back in the destructor SafepointMechanism::should_block() could > miss detecting the safepoint in progress since that method checks first > for local polls. > > > Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ > > > Thanks, > Patricio > >> Thanks, >> David >> >>> >>> >>> Thanks for looking into this! Waiting on your comments to send v04. >>> >>> Thanks, >>> Patricio >>>> --- >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>> > From kim.barrett at oracle.com Fri Feb 1 05:42:12 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Feb 2019 00:42:12 -0500 Subject: RFR (S) 8218151: Simplify JavaThread::thread_state definition In-Reply-To: References: <3A324A27-CBA0-44AD-A9F5-0DAAE85AAE68@oracle.com> Message-ID: <0841ECF9-8EDE-4BB7-B142-F34DAE53111F@oracle.com> > On Feb 1, 2019, at 12:08 AM, David Holmes wrote: > > Hi Kim, > > On 1/02/2019 2:56 pm, Kim Barrett wrote: >>> On Jan 31, 2019, at 4:13 PM, Aleksey Shipilev wrote: >>> >>> RFE: >>> https://bugs.openjdk.java.net/browse/JDK-8218151 >>> >>> Fix: >>> http://cr.openjdk.java.net/~shade/8218151/webrev.01/ >>> >>> The difference in definitions in JavaThread::thread_state in AArch64 and PPC64 is the source of >>> frequent build failures when someone tests only x86_64, see the linked issues for a taste. The way >>> out of this is to push the #if-s inside the method body, so that definition is always in one place, >>> and would not accidentally break the build. >>> >>> Testing: Linux {x86_64, x86_32, aarch64, arm32, ppc64el, s390x} builds, Mac OS X {x86_64} build, >>> Windows {x86_64} build, jdk-submit (failed windows test and macos build, but I suspect there are >>> infra problems, will wait and re-run; see for example mach5-one-shade-JDK-8218151-20190131-1631-233989). >>> >>> Thanks, >>> -Aleksey >> So why are the definitions different, using OrderAccess for PPC64 and >> AARCH64, but not for other platforms? Why not unconditionally use >> OrderAccess? If that's needed for some weakly ordered architectures, >> seems like it should be needed for all. And for TSO the OrderAccess >> operations shouldn't introduce any additional overhead. > > The other ports put the membars in the calling code where needed, but PPC64 and Aarch64 folk wanted acquire/release semantics. At least that is my recollection. The Oracle PPC32 and ARM64 ports did not need them. Thanks for the explanation. I can certainly understand the PPC64 and AARCH64 folks POV. There are lots of uses in shared code, and a quick look finds several where hardware store re-ordering seems like it could result in additional states. But I don?t know the relevant code, so don?t know if those states are actually problematic. The change certainly maintains the pre-existing behavior, so looks good. From david.holmes at oracle.com Fri Feb 1 05:50:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 15:50:59 +1000 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> Message-ID: <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> Hi Kim, On 1/02/2019 10:44 am, Kim Barrett wrote: > Please review this extension to the existing support for locally > disabling various compiler warnings. There are also a few updates of > existing code to use the new mechanisms. (There are some additional > opportunities to use these new mechanisms, but some were in code that > Oracle doesn't test, like Win32, so I left them alone.) > > (Obviously one should not disable warnings lightly, but sometimes one > does what one must.) > > There are several pieces to this change. > > First, utilities/compilerWarnings.hpp is refactored to have > compiler-specific variants, similar to globalDefinitions.hpp. This > hadn't been done previously because only gcc (and clang) had > non-trivial definitions. > > Second, implemented PRAGMA_DIAG_PUSH/POP for Visual Studio. Still no > implementations for xlc or solstudio though. > > Third, added a couple of compiler-specific warning disabling macros: > > PRAGMA_DISABLE_GCC_WARNING(option_string) // also applies to clang > PRAGMA_DISABLE_MSVCPP_WARNING(num) > > They have useful implementations for the respective compilers and > empty definitions otherwise. > > (I'm open to suggestions for better names, esp. for "MSVCPP".) This all seems quite reasonable to me. On the naming ... if the file has to use visCPP perhaps the macro should use VISCPP rather than MSVCPP ? Thanks, David > CR: > https://bugs.openjdk.java.net/browse/JDK-8218164 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8218164/open.00/ > > Testing: > mach5 tier1 > From kim.barrett at oracle.com Fri Feb 1 06:12:04 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Feb 2019 01:12:04 -0500 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> Message-ID: <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> > On Feb 1, 2019, at 12:50 AM, David Holmes wrote: > > Hi Kim, > > On 1/02/2019 10:44 am, Kim Barrett wrote: >> Please review this extension to the existing support for locally >> disabling various compiler warnings. There are also a few updates of >> existing code to use the new mechanisms. (There are some additional >> opportunities to use these new mechanisms, but some were in code that >> Oracle doesn't test, like Win32, so I left them alone.) >> (Obviously one should not disable warnings lightly, but sometimes one >> does what one must.) >> There are several pieces to this change. >> First, utilities/compilerWarnings.hpp is refactored to have >> compiler-specific variants, similar to globalDefinitions.hpp. This >> hadn't been done previously because only gcc (and clang) had >> non-trivial definitions. >> Second, implemented PRAGMA_DIAG_PUSH/POP for Visual Studio. Still no >> implementations for xlc or solstudio though. >> Third, added a couple of compiler-specific warning disabling macros: >> PRAGMA_DISABLE_GCC_WARNING(option_string) // also applies to clang >> PRAGMA_DISABLE_MSVCPP_WARNING(num) >> They have useful implementations for the respective compilers and >> empty definitions otherwise. >> (I'm open to suggestions for better names, esp. for "MSVCPP".) > > This all seems quite reasonable to me. On the naming ... if the file has to use visCPP perhaps the macro should use VISCPP rather than MSVCPP ? Thanks. I?d be okay with that too. Let?s see if anyone else has any preference. visCPP only appears a handful of times, and comes from the build system. The way we currently identify this platform for these warning controls and similar things is by looking for _MSC_VER. The actual product is Microsoft Visual C++ (?often abbreviated to MSVC? - Wikipedia). In retrospect, ?MSVC? seems like a better choice than MSVCPP. > Thanks, > David > >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8218164 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8218164/open.00/ >> Testing: >> mach5 tier1 From patricio.chilano.mateo at oracle.com Fri Feb 1 06:31:46 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 1 Feb 2019 01:31:46 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: <0c45ed83-e04c-c640-2cac-ae6581faeebf@oracle.com> Hi David, On 2/1/19 12:34 AM, David Holmes wrote: > Hi Patricio, > > Comments on inc v4: > > src/hotspot/share/runtime/safepointMechanism.inline.hpp > > +?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { > > Need space after if. > > I trust Robbin's judgement that this is the right way to express this, > but if ordering is so critical it should be documented. He didn't propose that exact line but local_poll_armed() is a load acquire so should be okay. But let's see what Robbin says. > --- > > src/hotspot/share/runtime/mutex.hpp/.cpp > > assert_owned_by_self doesn't need to be a member function, it can just > be a file static in the .cpp file. No need to clutter the API. > > Using a version that takes the owner thread is a good idea for > checking the NULL case too. Done. > --- > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > > I like the comment block - thanks! A couple of minor things: > > + // are trying to acquire. This will be used to access and release > the monitor in case needed to avoid > > s/in case/if/ Done. > + // the monitor that is in the process of being acquired (only > setting the owner is missing). > > I think the part in parentheses can be dropped - it reads like you > should be setting the owner but have chosen not to for some reason. Done. > + // The logic of this class could have been integrated into a more > general ThreadBlockInVM. By using a > + // separate class though, we avoid executing branches that would > otherwise be needed to identify each > + // case. > > Not necessary IMHO but up to you whether to keep or drop. Dropped. > In regards to the name ThreadLockBlockInVM ... I don't have a good > suggestion. > ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is rather > unwieldy. ;-) But the "Lock" part really doesn't mean anything. So > your suggestion of ThreadBlockinVMWithDeadlockPrevention seems a big > improvement to me. :) ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut was the right one, too bad it's so long =D. Ok, I''ll leave ThreadBlockInVMWithDeadlockPrevention, if anybody comes up with a better one I can change it. I'll wait for Robbin then to send v05. Thanks! Patricio > Thanks, > David > ----- > > On 1/02/2019 3:05 pm, Patricio Chilano wrote: >> Hi David, >> >> On 1/31/19 12:54 AM, David Holmes wrote: >>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>> Hi David, >>>> >>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>> Hi Patricio, >>>>> >>>>> >>>>> >>>>> First, thanks for all the many weeks of work you've put into this, >>>>> pulling together a number of ideas from different people to make >>>>> it all work! >>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>> >>> :) Nothing innovative there. >>> >>>>> I've only got a few minor comments/suggestions. >>>>> >>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>> Inc: >>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>> >>>>> >>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>> >>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>> masking the actual difference between the two wrappers to me. It >>>>> seems to me that an extra arg to transition_and_fence should allow >>>>> you to handle the new behaviour without having to duplicate so >>>>> much of this code. In any case the semantics of >>>>> ThreadLockBlockInVM needs to be described. >>>> I could do it with one extra argument, but I would need to add two >>>> extra branches in transition_and_fence(), one to decide if I'm in >>>> the Monitor case to avoid calling >>>> SafepointMechanism::block_if_requested() directly and another one >>>> to actually decide if I'm transitioning in or out, since the >>>> actions to perform are different. I think it is easier to read >>>> without adding new conditionals, and also we will save those extra >>>> branches, but if you think it's better this way I can change it. >>> >>> I would like something that tells me more clearly how this new >>> transition helper differs from the existing TBIVM. Sharing the code >>> between them and using different args would be one way. Documenting >>> the difference in comments would be another. Your choice. >> Ok, I added a description on top of TLBIVM. >> >>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>> refers to. I find the name quite jarring to read. >>>> What about changing it to ThreadBlockinMonitor? >>> >>> That's not quite conveying the semantics. The problem is that the >>> semantics we are changing compared to TBIVM are not evident in the >>> TBIVM name. If TBIVM was actually >>> ThreadBlockInVMWithSafepointBlocking, then this new transition would >>> obviously be ThreadBlockInVMWithoutSafepointBlocking - but perhaps >>> that lengthy, but clear name would be okay anyway? >> Not convinced on that name since we are blocking at safepoints in the >> destructor. Based on the comments I added how about >> ThreadBlockinVMWithDeadlockPrevention ? or >> ThreadBlockinVMWithPreemption? (as in eliminate one of the conditions >> for deadlocks). >> >>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>> don't really convey to me what happens - what is being "preempted" >>>>> here? I would suggest a more direct Monitor::release_for_safepoint >>>> Changed. >>>> >>>>> --- >>>>> >>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>> need bother at all with the one logging statement that is present. >>>> I added it to eventually track unbounded try locks. Not sure I >>>> follow you with the name, isn't that how we name this monitors? I >>>> tried to differentiate them from Java monitors. What about just >>>> "monitor"? >>> >>> How about vmmonitor ? >> Ok, changed. >> >>>>> --- >>>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> >>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>> checks. >>>>> >>>>> The comment there should only say "not require". >>>> Done. >>>> >>>>> void Monitor::preempt_by_safepoint() { >>>>> ? _lock.unlock(); >>>>> } >>>>> >>>>> Apart from renaming this as suggested above, aren't there any >>>>> suitable assertions we should have here? safepoint-in-progress or >>>>> handshake-in-progress? _owner == Thread::current? >>>> Ok, I added an assertion that owner should be NULL. Asserting >>>> safepoint-in-progress does not really work because _state could >>>> change to _not_synchronized right after you checked for it in TLBIVM. >>> >>> Okay. >>> >>>>> Nit: >>>>> >>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>> INTPTR_FORMAT >>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>> p2i(Thread::current())); >>>>> >>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>> second line should indent to the first comma, but that will make >>>>> the second line extend way past 80 columns. >>>>> >>>>> Also you could factor that assertion for _owner==Thread::current() >>>>> into its own function or macro to avoid the repetition. >>>> Corrected indentation based on Dan's reply to align with _owner. >>> >>> I though it should indent to the comma because it is a continuation >>> of the same argument being passed to the assert "function". But I'm >>> okay with Dan's suggestion. >>> >>> Factoring it into its own little function or macro would still be >>> good to avoid the repetition. >> Ok, added new function assert_owned_by_self(). I could change it to >> assert_owner(Thread*) and use it for the NULL case too unifying the >> printed messages to something like "invalid owner: owner=" >> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >> >>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>> Object.wait() */); >>>>> >>>>> This needs to be returned to its original place as per Dan's >>>>> comments. >>>> Done. >>>> >>>>> ??? } else { >>>>> ????? Monitor::lock(self); >>>>> ??? } >>>>> >>>>> You don't need Monitor:: here >>>> Removed. >>>> >>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>> PlatformMonitor now. >>>>> >>>>> This needs to be resolved before committing. Some of the existing >>>>> commentary on what raw monitors are needs to be retained. Not >>>>> clear if we need to set the _owner field or can just skip it. >>>> Is it okay if I keep the following comments? >>>> >>>> // Yet another degenerate version of Monitor::lock() or >>>> lock_without_safepoint_check() >>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>> via JVM_RawMonitorEnter. >>>> // >>>> // There's no expectation that JVM_RawMonitors will interoperate >>>> properly with the native >>>> // Mutex-Monitor constructs.? We happen to implement >>>> JVM_RawMonitors in terms of >>>> // native Mutex-Monitors simply as a matter of convenience. >>> >>> Yep that's perfect. And as a future RFE we can replace them with >>> direct use of PlatformMonitor (or PlatformMutex). >>> >>>> >>>> I could keep setting the owner as _owner = >>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>> hurt. >>> >>> It's useful for checking usage errors, but we won't have that if we >>> replace with PlatformMonitor, so may as well drop it now IMO. >> Ok, I added asserts that _owner should be NULL after acquiring it and >> before releasing it though. >> >>>>> Monitor::~Monitor() { >>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>> p2i(_owner)); >>>>> } >>>>> >>>>> Will this automatically result in the PlatformMonitor destructor >>>>> being called? >>>> Yes, should I add a comment to make it clear that >>>> ~PlatformMonitor() will be executed? >>> >>> No need - assume other people have a better understanding of C++ >>> than I do :) >> >> Below is version v04, which also contains a correction pointed out >> off-list by Robbin to do a local poll first in >> SafepointMechanism::callback_if_safepoint() if we are using local >> polls. Since the thread local poll is armed after changing _state to >> _synchronizing, if we only do a global poll in the TLBIVM constructor >> we could detect there is a safepoint in progress and callback but >> when coming back in the destructor SafepointMechanism::should_block() >> could miss detecting the safepoint in progress since that method >> checks first for local polls. >> >> >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >> >> >> Thanks, >> Patricio >> >>> Thanks, >>> David >>> >>>> >>>> >>>> Thanks for looking into this! Waiting on your comments to send v04. >>>> >>>> Thanks, >>>> Patricio >>>>> --- >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>> >> From david.holmes at oracle.com Fri Feb 1 07:55:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 17:55:50 +1000 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> Message-ID: On 1/02/2019 4:12 pm, Kim Barrett wrote: >> On Feb 1, 2019, at 12:50 AM, David Holmes wrote: >> >> Hi Kim, >> >> On 1/02/2019 10:44 am, Kim Barrett wrote: >>> Please review this extension to the existing support for locally >>> disabling various compiler warnings. There are also a few updates of >>> existing code to use the new mechanisms. (There are some additional >>> opportunities to use these new mechanisms, but some were in code that >>> Oracle doesn't test, like Win32, so I left them alone.) >>> (Obviously one should not disable warnings lightly, but sometimes one >>> does what one must.) >>> There are several pieces to this change. >>> First, utilities/compilerWarnings.hpp is refactored to have >>> compiler-specific variants, similar to globalDefinitions.hpp. This >>> hadn't been done previously because only gcc (and clang) had >>> non-trivial definitions. >>> Second, implemented PRAGMA_DIAG_PUSH/POP for Visual Studio. Still no >>> implementations for xlc or solstudio though. >>> Third, added a couple of compiler-specific warning disabling macros: >>> PRAGMA_DISABLE_GCC_WARNING(option_string) // also applies to clang >>> PRAGMA_DISABLE_MSVCPP_WARNING(num) >>> They have useful implementations for the respective compilers and >>> empty definitions otherwise. >>> (I'm open to suggestions for better names, esp. for "MSVCPP".) >> >> This all seems quite reasonable to me. On the naming ... if the file has to use visCPP perhaps the macro should use VISCPP rather than MSVCPP ? > > Thanks. > > I?d be okay with that too. Let?s see if anyone else has any preference. > visCPP only appears a handful of times, and comes from the build system. Yep. > The way we currently identify this platform for these warning controls and > similar things is by looking for _MSC_VER. Yes though that of course dates way back to the original Microsoft C compiler tools for DOS :) > The actual product is > Microsoft Visual C++ (?often abbreviated to MSVC? - Wikipedia). That's the old name, now (and for a while) it's Microsoft Visual Studio. > In retrospect, ?MSVC? seems like a better choice than MSVCPP. Agreed. David > >> Thanks, >> David >> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8218164 >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8218164/open.00/ >>> Testing: >>> mach5 tier1 > > From matthias.baesken at sap.com Fri Feb 1 10:16:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 1 Feb 2019 10:16:08 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > for all of them? Though to be honest I don't understand this whole > section anyway - we have a lengthy comment saying why you can't > necessarily assign NULL to an integer type and to use NULL_WORD instead > but then it's defined as NULL anyway! I wonder if we used to have some > other conditions there where it was something different Hi David , not sure but I guess the #ifdef __GNUC__ came from linux/gcc and was copied to the aix / xlc file when the port was done back then . See : globalDefinitions_gcc.hpp 118#ifdef __GNUC__ 119 #ifdef _LP64 120 #define NULL_WORD 0L 121 #else 122 // Cast 0 to intptr_t rather than int32_t since they are not the same type 123 // on platforms such as Mac OS X. 124 #define NULL_WORD ((intptr_t)0) 125 #endif 126#else 127 #define NULL_WORD NULL 128#endif The NULL_WORD is mostly used in x86-only coding. But also used at some (but few) places in shared coding , like : intptr_t* addr; *addr = NULL_WORD; intptr_t _callee_registers[RegisterMap::reg_count]; _callee_registers[i] = src != NULL ? *src : NULL_WORD; > In any case having an if and else that do exactly the same thing seems rather > pointless to me. > Yes I agree , I think I remove the #ifdef ... #else and just define #define NULL_WORD NULL for AIX . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 1. Februar 2019 05:24 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: 'build-dev at openjdk.java.net' > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi Matthias, > > On 1/02/2019 12:50 am, Baesken, Matthias wrote: > > Please review this small webrev . It contains a few changes for building > hotspot on AIX with xlclang++ / xlc16 . > > ( most likely switching to xlclang++ / xlc16 will be a must once we > introduce C++11/14 features ) > > > > Some comments on the changes : > > > > > > - porting_aix.cpp : workaround for demangle.h (does not work with > xlclang++) > > Can't comment as I know nothing about it. > > > - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to > assigning false to AllocateHeapAt which is a bad idea (and does not work > with xlclang++) > > Good catch! > > > - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not > have #error ... in this case > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > for all of them? Though to be honest I don't understand this whole > section anyway - we have a lengthy comment saying why you can't > necessarily assign NULL to an integer type and to use NULL_WORD instead > but then it's defined as NULL anyway! I wonder if we used to have some > other conditions there where it was something different? In any case > having an if and else that do exactly the same thing seems rather > pointless to me. > > Thanks, > David > > > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218136 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ > > > > > > Thanks, Matthias > > From goetz.lindenmaier at sap.com Fri Feb 1 11:32:54 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Feb 2019 11:32:54 +0000 Subject: RFR (S) 8218140: Build failures after JDK-8218041 (Assorted wrong/missing includes) In-Reply-To: <6bdb5705-6ac0-c0b7-3b0d-480abb5f7dc3@redhat.com> References: <6dd0ada4-22bd-69ad-8118-18b805d9ed5f@redhat.com> <402426c8-4ee1-4893-abfe-080bf330342a@redhat.com> <6bdb5705-6ac0-c0b7-3b0d-480abb5f7dc3@redhat.com> Message-ID: <3e974ebe73d7467babe35451825906cd@sap.com> Hi Aleksey, Thanks for fixing this before we popped up at work :) !! s390x and linuxppc64 builds are already green, the others will take a bit longer. Great, timely work! Best, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of > Aleksey Shipilev > Sent: Donnerstag, 31. Januar 2019 18:12 > To: Stefan Karlsson ; hotspot- > dev at openjdk.java.net > Subject: Re: RFR (S) 8218140: Build failures after JDK-8218041 (Assorted > wrong/missing includes) > > Thanks! No further comments from, say, SAP folks? > > I am going to push this to unbreak jdk/jdk then. > > -Aleksey > > On 1/31/19 5:35 PM, Stefan Karlsson wrote: > > Looks good. > > > > StefanK > > > > On 2019-01-31 16:34, Aleksey Shipilev wrote: > >> On 1/31/19 1:26 PM, Aleksey Shipilev wrote: > >> Actually, aarch64, arm32, ppc64, s390x are broken. This is the new fix: > >> ?? http://cr.openjdk.java.net/~shade/8218140/webrev.02/ > >> > >> It looks like frame_*.cpp files need to include os.inline.hpp to gain access to > >> os::uses_stack_guard_pages(). > >> > >> Testing: Linux {x86_64, aarch64, arm32, ppc64, s390x} compilation > >> > >> -Aleksey From magnus.ihse.bursie at oracle.com Fri Feb 1 11:41:53 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 1 Feb 2019 12:41:53 +0100 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: On 2019-02-01 05:23, David Holmes wrote: > Hi Matthias, > > On 1/02/2019 12:50 am, Baesken, Matthias wrote: >> Please review? this small webrev? . It contains a few changes? for? >> building hotspot?? on AIX with xlclang++? / xlc16? . >> ( most likely switching to?? xlclang++? / xlc16??? will be a must >> once? we introduce C++11/14 features ) >> >> Some comments on the changes : >> >> >> - porting_aix.cpp? :? workaround for demangle.h (does not work with >> xlclang++) > > Can't comment as I know nothing about it. > >> - arguments.cpp/hpp? :? the UNSUPPORTED_OPTON macro lead? to >> assigning false to AllocateHeapAt which is a bad idea (and does not >> work with xlclang++) > > Good catch! > >> -?? globalDefinitions_xlc.hpp?? : xlclang++ sets?? __GNUC__ so we >> must not? have #error ... in this case > > Confused. Which other xlc compilers set __GNUC_ as you are changing > this for all of them? Unfortunately, I think __GNUC__ is set by many compilers who wish to express that (they believe) they are compatible with gcc (in one way or another). I'm pretty sure it's set by solstudio, for instance. And clang. But I might be wrong, and I might be thinking about some other gcc feature macro. /Magnus > Though to be honest I don't understand this whole section anyway - we > have a lengthy comment saying why you can't necessarily assign NULL to > an integer type and to use NULL_WORD instead but then it's defined as > NULL anyway! I wonder if we used to have some other conditions there > where it was something different? In any case having an if and else > that do exactly the same thing seems rather pointless to me. > > Thanks, > David >> >> >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8218136 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ >> >> >> Thanks, Matthias >> From matthias.baesken at sap.com Fri Feb 1 12:36:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 1 Feb 2019 12:36:08 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ - adjusted globalDefinitions_xlc.hpp - fixed some copyright years Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Freitag, 1. Februar 2019 11:16 > To: 'David Holmes' ; 'hotspot- > dev at openjdk.java.net' > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > > > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > > for all of them? Though to be honest I don't understand this whole > > section anyway - we have a lengthy comment saying why you can't > > necessarily assign NULL to an integer type and to use NULL_WORD instead > > but then it's defined as NULL anyway! I wonder if we used to have some > > other conditions there where it was something different > > Hi David , not sure but I guess the #ifdef __GNUC__ came from > linux/gcc and was copied to the aix / xlc file when the port was done back > then . > See : > > globalDefinitions_gcc.hpp > > 118#ifdef __GNUC__ > 119 #ifdef _LP64 > 120 #define NULL_WORD 0L > 121 #else > 122 // Cast 0 to intptr_t rather than int32_t since they are not the same > type > 123 // on platforms such as Mac OS X. > 124 #define NULL_WORD ((intptr_t)0) > 125 #endif > 126#else > 127 #define NULL_WORD NULL > 128#endif > > The NULL_WORD is mostly used in x86-only coding. But also used at some > (but few) places in shared coding , like : > > intptr_t* addr; > *addr = NULL_WORD; > > intptr_t _callee_registers[RegisterMap::reg_count]; > _callee_registers[i] = src != NULL ? *src : NULL_WORD; > > > > In any case having an if and else that do exactly the same thing seems > rather > > pointless to me. > > > > Yes I agree , I think I remove the #ifdef ... #else and just define #define > NULL_WORD NULL for AIX . > > Best regards, Matthias > > > > -----Original Message----- > > From: David Holmes > > Sent: Freitag, 1. Februar 2019 05:24 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Cc: 'build-dev at openjdk.java.net' > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi Matthias, > > > > On 1/02/2019 12:50 am, Baesken, Matthias wrote: > > > Please review this small webrev . It contains a few changes for building > > hotspot on AIX with xlclang++ / xlc16 . > > > ( most likely switching to xlclang++ / xlc16 will be a must once we > > introduce C++11/14 features ) > > > > > > Some comments on the changes : > > > > > > > > > - porting_aix.cpp : workaround for demangle.h (does not work with > > xlclang++) > > > > Can't comment as I know nothing about it. > > > > > - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to > > assigning false to AllocateHeapAt which is a bad idea (and does not work > > with xlclang++) > > > > Good catch! > > > > > - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not > > have #error ... in this case > > > > Confused. Which other xlc compilers set __GNUC_ as you are changing this > > for all of them? Though to be honest I don't understand this whole > > section anyway - we have a lengthy comment saying why you can't > > necessarily assign NULL to an integer type and to use NULL_WORD instead > > but then it's defined as NULL anyway! I wonder if we used to have some > > other conditions there where it was something different? In any case > > having an if and else that do exactly the same thing seems rather > > pointless to me. > > > > Thanks, > > David > > > > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8218136 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ > > > > > > > > > Thanks, Matthias > > > From david.holmes at oracle.com Fri Feb 1 12:49:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 22:49:22 +1000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi Matthias, On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > - adjusted globalDefinitions_xlc.hpp I don't think it makes sense to keep the comment which was obviously copied from the gcc file: // On Linux NULL is defined as a special type '__null'. Assigning __null to // integer variable will cause gcc warning. Use NULL_WORD in places where a // pointer is stored as integer value. On some platforms, sizeof(intptr_t) > // sizeof(void*), so here we want something which is integer type, but has the // same size as a pointer. Rather something like: // Some platform/tool-chain combinations can't assign NULL to an integer // type so we define NULL_WORD to use in those contexts. For xlc they // are the same. Thanks, David > - fixed some copyright years > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Freitag, 1. Februar 2019 11:16 >> To: 'David Holmes' ; 'hotspot- >> dev at openjdk.java.net' >> Cc: 'build-dev at openjdk.java.net' >> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >> xlc16 on AIX >> >>> >>> Confused. Which other xlc compilers set __GNUC_ as you are changing this >>> for all of them? Though to be honest I don't understand this whole >>> section anyway - we have a lengthy comment saying why you can't >>> necessarily assign NULL to an integer type and to use NULL_WORD instead >>> but then it's defined as NULL anyway! I wonder if we used to have some >>> other conditions there where it was something different >> >> Hi David , not sure but I guess the #ifdef __GNUC__ came from >> linux/gcc and was copied to the aix / xlc file when the port was done back >> then . >> See : >> >> globalDefinitions_gcc.hpp >> >> 118#ifdef __GNUC__ >> 119 #ifdef _LP64 >> 120 #define NULL_WORD 0L >> 121 #else >> 122 // Cast 0 to intptr_t rather than int32_t since they are not the same >> type >> 123 // on platforms such as Mac OS X. >> 124 #define NULL_WORD ((intptr_t)0) >> 125 #endif >> 126#else >> 127 #define NULL_WORD NULL >> 128#endif >> >> The NULL_WORD is mostly used in x86-only coding. But also used at some >> (but few) places in shared coding , like : >> >> intptr_t* addr; >> *addr = NULL_WORD; >> >> intptr_t _callee_registers[RegisterMap::reg_count]; >> _callee_registers[i] = src != NULL ? *src : NULL_WORD; >> >> >>> In any case having an if and else that do exactly the same thing seems >> rather >>> pointless to me. >>> >> >> Yes I agree , I think I remove the #ifdef ... #else and just define #define >> NULL_WORD NULL for AIX . >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Freitag, 1. Februar 2019 05:24 >>> To: Baesken, Matthias ; 'hotspot- >>> dev at openjdk.java.net' >>> Cc: 'build-dev at openjdk.java.net' >>> Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>> xlc16 on AIX >>> >>> Hi Matthias, >>> >>> On 1/02/2019 12:50 am, Baesken, Matthias wrote: >>>> Please review this small webrev . It contains a few changes for building >>> hotspot on AIX with xlclang++ / xlc16 . >>>> ( most likely switching to xlclang++ / xlc16 will be a must once we >>> introduce C++11/14 features ) >>>> >>>> Some comments on the changes : >>>> >>>> >>>> - porting_aix.cpp : workaround for demangle.h (does not work with >>> xlclang++) >>> >>> Can't comment as I know nothing about it. >>> >>>> - arguments.cpp/hpp : the UNSUPPORTED_OPTON macro lead to >>> assigning false to AllocateHeapAt which is a bad idea (and does not work >>> with xlclang++) >>> >>> Good catch! >>> >>>> - globalDefinitions_xlc.hpp : xlclang++ sets __GNUC__ so we must not >>> have #error ... in this case >>> >>> Confused. Which other xlc compilers set __GNUC_ as you are changing this >>> for all of them? Though to be honest I don't understand this whole >>> section anyway - we have a lengthy comment saying why you can't >>> necessarily assign NULL to an integer type and to use NULL_WORD instead >>> but then it's defined as NULL anyway! I wonder if we used to have some >>> other conditions there where it was something different? In any case >>> having an if and else that do exactly the same thing seems rather >>> pointless to me. >>> >>> Thanks, >>> David >>>> >>>> >>>> >>>> Bug/webrev : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8218136 >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.0/ >>>> >>>> >>>> Thanks, Matthias >>>> From rwestrel at redhat.com Fri Feb 1 13:56:29 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 01 Feb 2019 14:56:29 +0100 Subject: [11u] RFR(M): 8214206: Fix for JDK-8213419 is broken on 32-bit Message-ID: <87ef8r394i.fsf@redhat.com> I'd like to backport this fix to 11u but the patch doesn't apply cleanly some I'm requesting a new review. http://cr.openjdk.java.net/~roland/8214206.11u/webrev.00/ jdk 12 fix: https://bugs.openjdk.java.net/browse/JDK-8214206 http://hg.openjdk.java.net/jdk/jdk/rev/7d3cde494494 Roland. From shade at redhat.com Fri Feb 1 15:05:07 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Feb 2019 16:05:07 +0100 Subject: RFR (S) 8218151: Simplify JavaThread::thread_state definition In-Reply-To: <0841ECF9-8EDE-4BB7-B142-F34DAE53111F@oracle.com> References: <3A324A27-CBA0-44AD-A9F5-0DAAE85AAE68@oracle.com> <0841ECF9-8EDE-4BB7-B142-F34DAE53111F@oracle.com> Message-ID: On 2/1/19 6:42 AM, Kim Barrett wrote: > The change certainly maintains the pre-existing behavior, so looks good. Yup. jdk-submit had recovered too and the patch looks clean there. I think patch is simple enough to not need further reviews. Pushed. -Aleksey From shade at redhat.com Fri Feb 1 15:05:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 1 Feb 2019 16:05:52 +0100 Subject: RFR (S) 8217879: hs_err should print more instructions in hex dump In-Reply-To: <6312e66e-2023-99a1-90f7-cf282bc96217@oracle.com> References: <58f93cfa-0c8e-d5cb-c4c4-d52b41e433f0@redhat.com> <5a5bc910-54d2-e7de-e50a-895a6b9ec38d@redhat.com> <6312e66e-2023-99a1-90f7-cf282bc96217@oracle.com> Message-ID: Thanks! And pushed. -Aleksey On 1/31/19 2:59 PM, Stefan Karlsson wrote: > Looks good. > > Thanks, > StefanK > > On 2019-01-31 13:08, Aleksey Shipilev wrote: >> On 1/28/19 5:48 PM, Aleksey Shipilev wrote: >>> RFE: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8217879 >>> >>> Fix: >>> ?? http://cr.openjdk.java.net/~shade/8217879/webrev.01/ >>> >> >> JDK-8217994 [1] is in, so we can simplify the safety logic: just print whatever around the PC, and >> let os::print_hex_dump handle it itself: >> ?? http://cr.openjdk.java.net/~shade/8217879/webrev.06/ >> >> Testing: local build, eyeballing hs_errs, jdk-submit (running) >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8217994 >> >> Thanks, >> -Aleksey >> From daniel.daugherty at oracle.com Fri Feb 1 16:10:09 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Feb 2019 11:10:09 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> Message-ID: <9ebe68f4-5b36-f998-d7b1-b419f7f7983f@oracle.com> > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ src/hotspot/share/logging/logTag.hpp ??? No comments. src/hotspot/share/runtime/interfaceSupport.inline.hpp ??? L295: // - When transitioning in (constructor), it checks for safepoints without having to block, i.e calls ??????? Perhaps: ????????? // - When transitioning in (constructor), it checks for safepoints without blocking, i.e., calls ??? L298: //?? the monitor that is in the process of being acquired (only setting the owner is missing). ??????? Perhaps: ????????? //?? the monitor that is only partially acquired. src/hotspot/share/runtime/mutex.cpp ??? L59: log_trace(vmmonitor)("JavaThread " INTPTR_FORMAT " on %d attempt trying to acquire native monitor %s", p2i(self), retry_cnt, _name); ??????? nit - s/native monitor/vmmonitor/? - for consistency. src/hotspot/share/runtime/mutex.hpp ??? No comments. src/hotspot/share/runtime/safepointMechanism.inline.hpp ??? L83: ? if(!uses_thread_local_poll() || local_poll_armed(thread)) { ??? L84: ??? if (global_poll()) { ??????? I'm having trouble with this construct: ??????? - if uses_thread_local_poll() is false, then we check global_poll() ????????? and call SafepointSynchronize::block() if global_poll() == true. ????????? That makes sense since we're not using local polling. ??????? - if uses_thread_local_poll() is true, then we check ????????? if local_poll_armed(thread) == true and then we check global_poll() ????????? and call SafepointSynchronize::block() if global_poll() == true. ????????? Huh? ??????? So we only call SafepointSynchronize::block() if global_poll() == true ??????? no matter what. It seems like the checks for local polling don't really ??????? do anything here. ??????? What am I missing? Dan On 2/1/19 12:05 AM, Patricio Chilano wrote: > Hi David, > > On 1/31/19 12:54 AM, David Holmes wrote: >> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>> Hi David, >>> >>> On 1/30/19 2:29 AM, David Holmes wrote: >>>> Hi Patricio, >>>> >>>> >>>> >>>> First, thanks for all the many weeks of work you've put into this, >>>> pulling together a number of ideas from different people to make it >>>> all work! >>> Thanks! Credit to you for the PlatformMonitor implementation : ) >> >> :) Nothing innovative there. >> >>>> I've only got a few minor comments/suggestions. >>>> >>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>> >>>> >>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>> >>>> I'm very unclear how ThreadLockBlockInVM differs from >>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>> masking the actual difference between the two wrappers to me. It >>>> seems to me that an extra arg to transition_and_fence should allow >>>> you to handle the new behaviour without having to duplicate so much >>>> of this code. In any case the semantics of ThreadLockBlockInVM >>>> needs to be described. >>> I could do it with one extra argument, but I would need to add two >>> extra branches in transition_and_fence(), one to decide if I'm in >>> the Monitor case to avoid calling >>> SafepointMechanism::block_if_requested() directly and another one to >>> actually decide if I'm transitioning in or out, since the actions to >>> perform are different. I think it is easier to read without adding >>> new conditionals, and also we will save those extra branches, but if >>> you think it's better this way I can change it. >> >> I would like something that tells me more clearly how this new >> transition helper differs from the existing TBIVM. Sharing the code >> between them and using different args would be one way. Documenting >> the difference in comments would be another. Your choice. > Ok, I added a description on top of TLBIVM. > >>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>> refers to. I find the name quite jarring to read. >>> What about changing it to ThreadBlockinMonitor? >> >> That's not quite conveying the semantics. The problem is that the >> semantics we are changing compared to TBIVM are not evident in the >> TBIVM name. If TBIVM was actually >> ThreadBlockInVMWithSafepointBlocking, then this new transition would >> obviously be ThreadBlockInVMWithoutSafepointBlocking - but perhaps >> that lengthy, but clear name would be okay anyway? > Not convinced on that name since we are blocking at safepoints in the > destructor. Based on the comments I added how about > ThreadBlockinVMWithDeadlockPrevention ? or > ThreadBlockinVMWithPreemption? (as in eliminate one of the conditions > for deadlocks). > >>>> On the subject of naming, do_preempt and preempt_by_safepoint don't >>>> really convey to me what happens - what is being "preempted" here? >>>> I would suggest a more direct Monitor::release_for_safepoint >>> Changed. >>> >>>> --- >>>> >>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>> need bother at all with the one logging statement that is present. >>> I added it to eventually track unbounded try locks. Not sure I >>> follow you with the name, isn't that how we name this monitors? I >>> tried to differentiate them from Java monitors. What about just >>> "monitor"? >> >> How about vmmonitor ? > Ok, changed. > >>>> --- >>>> >>>> src/hotspot/share/runtime/mutex.cpp >>>> >>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>> ? // Ensure that the Monitor does not require or allow safepoint >>>> checks. >>>> >>>> The comment there should only say "not require". >>> Done. >>> >>>> void Monitor::preempt_by_safepoint() { >>>> ? _lock.unlock(); >>>> } >>>> >>>> Apart from renaming this as suggested above, aren't there any >>>> suitable assertions we should have here? safepoint-in-progress or >>>> handshake-in-progress? _owner == Thread::current? >>> Ok, I added an assertion that owner should be NULL. Asserting >>> safepoint-in-progress does not really work because _state could >>> change to _not_synchronized right after you checked for it in TLBIVM. >> >> Okay. >> >>>> Nit: >>>> >>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>> INTPTR_FORMAT >>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>> p2i(Thread::current())); >>>> >>>> with Dan's enhanced assertions there's an indentation issue. The >>>> second line should indent to the first comma, but that will make >>>> the second line extend way past 80 columns. >>>> >>>> Also you could factor that assertion for _owner==Thread::current() >>>> into its own function or macro to avoid the repetition. >>> Corrected indentation based on Dan's reply to align with _owner. >> >> I though it should indent to the comma because it is a continuation >> of the same argument being passed to the assert "function". But I'm >> okay with Dan's suggestion. >> >> Factoring it into its own little function or macro would still be >> good to avoid the repetition. > Ok, added new function assert_owned_by_self(). I could change it to > assert_owner(Thread*) and use it for the NULL case too unifying the > printed messages to something like "invalid owner: owner=" > INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? > >>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>> Object.wait() */); >>>> >>>> This needs to be returned to its original place as per Dan's comments. >>> Done. >>> >>>> ??? } else { >>>> ????? Monitor::lock(self); >>>> ??? } >>>> >>>> You don't need Monitor:: here >>> Removed. >>> >>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>> PlatformMonitor now. >>>> >>>> This needs to be resolved before committing. Some of the existing >>>> commentary on what raw monitors are needs to be retained. Not clear >>>> if we need to set the _owner field or can just skip it. >>> Is it okay if I keep the following comments? >>> >>> // Yet another degenerate version of Monitor::lock() or >>> lock_without_safepoint_check() >>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>> via JVM_RawMonitorEnter. >>> // >>> // There's no expectation that JVM_RawMonitors will interoperate >>> properly with the native >>> // Mutex-Monitor constructs.? We happen to implement JVM_RawMonitors >>> in terms of >>> // native Mutex-Monitors simply as a matter of convenience. >> >> Yep that's perfect. And as a future RFE we can replace them with >> direct use of PlatformMonitor (or PlatformMutex). >> >>> >>> I could keep setting the owner as _owner = Thread::current_or_null() >>> in jvm_raw_lock(), at least it wouldn't hurt. >> >> It's useful for checking usage errors, but we won't have that if we >> replace with PlatformMonitor, so may as well drop it now IMO. > Ok, I added asserts that _owner should be NULL after acquiring it and > before releasing it though. > >>>> Monitor::~Monitor() { >>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>> p2i(_owner)); >>>> } >>>> >>>> Will this automatically result in the PlatformMonitor destructor >>>> being called? >>> Yes, should I add a comment to make it clear that ~PlatformMonitor() >>> will be executed? >> >> No need - assume other people have a better understanding of C++ than >> I do :) > > Below is version v04, which also contains a correction pointed out > off-list by Robbin to do a local poll first in > SafepointMechanism::callback_if_safepoint() if we are using local > polls. Since the thread local poll is armed after changing _state to > _synchronizing, if we only do a global poll in the TLBIVM constructor > we could detect there is a safepoint in progress and callback but when > coming back in the destructor SafepointMechanism::should_block() could > miss detecting the safepoint in progress since that method checks > first for local polls. > > > Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ > > > Thanks, > Patricio > >> Thanks, >> David >> >>> >>> >>> Thanks for looking into this! Waiting on your comments to send v04. >>> >>> Thanks, >>> Patricio >>>> --- >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>> > From patricio.chilano.mateo at oracle.com Fri Feb 1 18:01:03 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 1 Feb 2019 13:01:03 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <9ebe68f4-5b36-f998-d7b1-b419f7f7983f@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <9ebe68f4-5b36-f998-d7b1-b419f7f7983f@oracle.com> Message-ID: <922da8bc-6ba5-79df-5045-e72568cc7e1f@oracle.com> Hi Dan, On 2/1/19 11:10 AM, Daniel D. Daugherty wrote: > > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ > > src/hotspot/share/logging/logTag.hpp > ??? No comments. > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > ??? L295: // - When transitioning in (constructor), it checks for > safepoints without having to block, i.e calls > ??????? Perhaps: > ????????? // - When transitioning in (constructor), it checks for > safepoints without blocking, i.e., calls > > ??? L298: //?? the monitor that is in the process of being acquired > (only setting the owner is missing). > ??????? Perhaps: > ????????? //?? the monitor that is only partially acquired. Done. > src/hotspot/share/runtime/mutex.cpp > ??? L59: log_trace(vmmonitor)("JavaThread " INTPTR_FORMAT " on %d > attempt trying to acquire native monitor %s", p2i(self), retry_cnt, > _name); > ??????? nit - s/native monitor/vmmonitor/? - for consistency. Done. > src/hotspot/share/runtime/mutex.hpp > ??? No comments. > > src/hotspot/share/runtime/safepointMechanism.inline.hpp > ??? L83: ? if(!uses_thread_local_poll() || local_poll_armed(thread)) { > ??? L84: ??? if (global_poll()) { > ??????? I'm having trouble with this construct: > > ??????? - if uses_thread_local_poll() is false, then we check > global_poll() > ????????? and call SafepointSynchronize::block() if global_poll() == > true. > ????????? That makes sense since we're not using local polling. > > ??????? - if uses_thread_local_poll() is true, then we check > ????????? if local_poll_armed(thread) == true and then we check > global_poll() > ????????? and call SafepointSynchronize::block() if global_poll() == > true. > > ????????? Huh? > > ??????? So we only call SafepointSynchronize::block() if global_poll() > == true > ??????? no matter what. It seems like the checks for local polling > don't really > ??????? do anything here. > > ??????? What am I missing? A couple of observations before going straight to the question. The check for local poll in SafepointMechanism::should_block() (TBIVMWDP destructor) is needed because we need to check for both, pending safepoints or pending handshakes. In other words once we transition back from the _thread_blocked state, there could be either a safepoint or a handshake for that thread being processed. If SafepointMechanism::should_block() returns true, then SafepointMechanism::callback_if_safepoint() only checks for pending safepoints. After that I do the check "if (_thread->has_handshake())" for pending handshakes. I couldn't use SafepointMechanism::block_if_requested() which checks for both like in the normal TBIVM, because of two reasons: - On one hand, I need to pass the "false" parameter to SafepointSynchronize::block() to avoid blocking when transitioning in, and avoid failing the test that we have a ThreadSafepointState of _call_back when transitioing back. Without introducing SafepointMechanism::callback_if_safepoint() I would have to modify a couple of methods in SafepointMechanism to receive that extra argument. I think this was cleaner. -But even if I did add the extra argument to those functions and use SafepointMechanism::block_if_requested(), I would need also to avoid checking for handshakes in the TBIVMWDP constructor. The processing of handshakes uses its own ThreadInVMForHandshake jacket which internally calls SafepointMechanism::block_if_requested(). Since in the constructor we do not block for safepoints, executing again SafepointMechanism::block_if_requested() in a handshake would execute SS::block twice. So to solve that I just introduced SafepointMechanism::callback_if_safepoint() which only checks for safepoints and uses the extra argument in SS::block. Now, as to why I can't just check for global polls in SafepointMechanism::callback_if_safepoint() (since I only want to check/stop for safepoints), this has to do with the race found by Robbin. Since the thread local poll is armed after changing _state to _synchronizing, if I only do a global poll, SafepointMechanism::callback_if_safepoint(in the TBIVMWDP constructor) could detect there is a safepoint in progress and callback but when coming back in the destructor SafepointMechanism::should_block() could miss detecting the safepoint in progress since that method checks for local polls first (it cares about both safepoints and handshakes). So I need to match the order of checks done by SafepointMechanism::should_block(). Any of this makes sense? Thanks, Patricio > Dan > > On 2/1/19 12:05 AM, Patricio Chilano wrote: >> Hi David, >> >> On 1/31/19 12:54 AM, David Holmes wrote: >>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>> Hi David, >>>> >>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>> Hi Patricio, >>>>> >>>>> >>>>> >>>>> First, thanks for all the many weeks of work you've put into this, >>>>> pulling together a number of ideas from different people to make >>>>> it all work! >>>> Thanks! Credit to you for the PlatformMonitor implementation : ) >>> >>> :) Nothing innovative there. >>> >>>>> I've only got a few minor comments/suggestions. >>>>> >>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>> Inc: >>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>> >>>>> >>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>> >>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>> masking the actual difference between the two wrappers to me. It >>>>> seems to me that an extra arg to transition_and_fence should allow >>>>> you to handle the new behaviour without having to duplicate so >>>>> much of this code. In any case the semantics of >>>>> ThreadLockBlockInVM needs to be described. >>>> I could do it with one extra argument, but I would need to add two >>>> extra branches in transition_and_fence(), one to decide if I'm in >>>> the Monitor case to avoid calling >>>> SafepointMechanism::block_if_requested() directly and another one >>>> to actually decide if I'm transitioning in or out, since the >>>> actions to perform are different. I think it is easier to read >>>> without adding new conditionals, and also we will save those extra >>>> branches, but if you think it's better this way I can change it. >>> >>> I would like something that tells me more clearly how this new >>> transition helper differs from the existing TBIVM. Sharing the code >>> between them and using different args would be one way. Documenting >>> the difference in comments would be another. Your choice. >> Ok, I added a description on top of TLBIVM. >> >>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>> refers to. I find the name quite jarring to read. >>>> What about changing it to ThreadBlockinMonitor? >>> >>> That's not quite conveying the semantics. The problem is that the >>> semantics we are changing compared to TBIVM are not evident in the >>> TBIVM name. If TBIVM was actually >>> ThreadBlockInVMWithSafepointBlocking, then this new transition would >>> obviously be ThreadBlockInVMWithoutSafepointBlocking - but perhaps >>> that lengthy, but clear name would be okay anyway? >> Not convinced on that name since we are blocking at safepoints in the >> destructor. Based on the comments I added how about >> ThreadBlockinVMWithDeadlockPrevention ? or >> ThreadBlockinVMWithPreemption? (as in eliminate one of the conditions >> for deadlocks). >> >>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>> don't really convey to me what happens - what is being "preempted" >>>>> here? I would suggest a more direct Monitor::release_for_safepoint >>>> Changed. >>>> >>>>> --- >>>>> >>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>> need bother at all with the one logging statement that is present. >>>> I added it to eventually track unbounded try locks. Not sure I >>>> follow you with the name, isn't that how we name this monitors? I >>>> tried to differentiate them from Java monitors. What about just >>>> "monitor"? >>> >>> How about vmmonitor ? >> Ok, changed. >> >>>>> --- >>>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> >>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>> checks. >>>>> >>>>> The comment there should only say "not require". >>>> Done. >>>> >>>>> void Monitor::preempt_by_safepoint() { >>>>> ? _lock.unlock(); >>>>> } >>>>> >>>>> Apart from renaming this as suggested above, aren't there any >>>>> suitable assertions we should have here? safepoint-in-progress or >>>>> handshake-in-progress? _owner == Thread::current? >>>> Ok, I added an assertion that owner should be NULL. Asserting >>>> safepoint-in-progress does not really work because _state could >>>> change to _not_synchronized right after you checked for it in TLBIVM. >>> >>> Okay. >>> >>>>> Nit: >>>>> >>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>> INTPTR_FORMAT >>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>> p2i(Thread::current())); >>>>> >>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>> second line should indent to the first comma, but that will make >>>>> the second line extend way past 80 columns. >>>>> >>>>> Also you could factor that assertion for _owner==Thread::current() >>>>> into its own function or macro to avoid the repetition. >>>> Corrected indentation based on Dan's reply to align with _owner. >>> >>> I though it should indent to the comma because it is a continuation >>> of the same argument being passed to the assert "function". But I'm >>> okay with Dan's suggestion. >>> >>> Factoring it into its own little function or macro would still be >>> good to avoid the repetition. >> Ok, added new function assert_owned_by_self(). I could change it to >> assert_owner(Thread*) and use it for the NULL case too unifying the >> printed messages to something like "invalid owner: owner=" >> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >> >>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>> Object.wait() */); >>>>> >>>>> This needs to be returned to its original place as per Dan's >>>>> comments. >>>> Done. >>>> >>>>> ??? } else { >>>>> ????? Monitor::lock(self); >>>>> ??? } >>>>> >>>>> You don't need Monitor:: here >>>> Removed. >>>> >>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>> PlatformMonitor now. >>>>> >>>>> This needs to be resolved before committing. Some of the existing >>>>> commentary on what raw monitors are needs to be retained. Not >>>>> clear if we need to set the _owner field or can just skip it. >>>> Is it okay if I keep the following comments? >>>> >>>> // Yet another degenerate version of Monitor::lock() or >>>> lock_without_safepoint_check() >>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>> via JVM_RawMonitorEnter. >>>> // >>>> // There's no expectation that JVM_RawMonitors will interoperate >>>> properly with the native >>>> // Mutex-Monitor constructs.? We happen to implement >>>> JVM_RawMonitors in terms of >>>> // native Mutex-Monitors simply as a matter of convenience. >>> >>> Yep that's perfect. And as a future RFE we can replace them with >>> direct use of PlatformMonitor (or PlatformMutex). >>> >>>> >>>> I could keep setting the owner as _owner = >>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>> hurt. >>> >>> It's useful for checking usage errors, but we won't have that if we >>> replace with PlatformMonitor, so may as well drop it now IMO. >> Ok, I added asserts that _owner should be NULL after acquiring it and >> before releasing it though. >> >>>>> Monitor::~Monitor() { >>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>> p2i(_owner)); >>>>> } >>>>> >>>>> Will this automatically result in the PlatformMonitor destructor >>>>> being called? >>>> Yes, should I add a comment to make it clear that >>>> ~PlatformMonitor() will be executed? >>> >>> No need - assume other people have a better understanding of C++ >>> than I do :) >> >> Below is version v04, which also contains a correction pointed out >> off-list by Robbin to do a local poll first in >> SafepointMechanism::callback_if_safepoint() if we are using local >> polls. Since the thread local poll is armed after changing _state to >> _synchronizing, if we only do a global poll in the TLBIVM constructor >> we could detect there is a safepoint in progress and callback but >> when coming back in the destructor SafepointMechanism::should_block() >> could miss detecting the safepoint in progress since that method >> checks first for local polls. >> >> >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >> >> >> Thanks, >> Patricio >> >>> Thanks, >>> David >>> >>>> >>>> >>>> Thanks for looking into this! Waiting on your comments to send v04. >>>> >>>> Thanks, >>>> Patricio >>>>> --- >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>> >> > From daniel.daugherty at oracle.com Fri Feb 1 19:22:32 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Feb 2019 14:22:32 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <922da8bc-6ba5-79df-5045-e72568cc7e1f@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <9ebe68f4-5b36-f998-d7b1-b419f7f7983f@oracle.com> <922da8bc-6ba5-79df-5045-e72568cc7e1f@oracle.com> Message-ID: <6affcf41-321c-9a94-028f-43d1102ded90@oracle.com> On 2/1/19 1:01 PM, Patricio Chilano wrote: > Hi Dan, > > On 2/1/19 11:10 AM, Daniel D. Daugherty wrote: >> > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >> >> src/hotspot/share/logging/logTag.hpp >> ??? No comments. >> >> src/hotspot/share/runtime/interfaceSupport.inline.hpp >> ??? L295: // - When transitioning in (constructor), it checks for >> safepoints without having to block, i.e calls >> ??????? Perhaps: >> ????????? // - When transitioning in (constructor), it checks for >> safepoints without blocking, i.e., calls >> >> ??? L298: //?? the monitor that is in the process of being acquired >> (only setting the owner is missing). >> ??????? Perhaps: >> ????????? //?? the monitor that is only partially acquired. > Done. >> src/hotspot/share/runtime/mutex.cpp >> ??? L59: log_trace(vmmonitor)("JavaThread " INTPTR_FORMAT " on %d >> attempt trying to acquire native monitor %s", p2i(self), retry_cnt, >> _name); >> ??????? nit - s/native monitor/vmmonitor/? - for consistency. > Done. > >> src/hotspot/share/runtime/mutex.hpp >> ??? No comments. >> >> src/hotspot/share/runtime/safepointMechanism.inline.hpp >> ??? L83: ? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >> ??? L84: ??? if (global_poll()) { >> ??????? I'm having trouble with this construct: >> >> ??????? - if uses_thread_local_poll() is false, then we check >> global_poll() >> ????????? and call SafepointSynchronize::block() if global_poll() == >> true. >> ????????? That makes sense since we're not using local polling. >> >> ??????? - if uses_thread_local_poll() is true, then we check >> ????????? if local_poll_armed(thread) == true and then we check >> global_poll() >> ????????? and call SafepointSynchronize::block() if global_poll() == >> true. >> >> ????????? Huh? >> >> ??????? So we only call SafepointSynchronize::block() if >> global_poll() == true >> ??????? no matter what. It seems like the checks for local polling >> don't really >> ??????? do anything here. >> >> ??????? What am I missing? > A couple of observations before going straight to the question. The > check for local poll in SafepointMechanism::should_block() (TBIVMWDP > destructor) is needed because we need to check for both, pending > safepoints or pending handshakes. In other words once we transition > back from the _thread_blocked state, there could be either a safepoint > or a handshake for that thread being processed. If > SafepointMechanism::should_block() returns true, then > SafepointMechanism::callback_if_safepoint() only checks for pending > safepoints. After that I do the check "if (_thread->has_handshake())" > for pending handshakes. I couldn't use > SafepointMechanism::block_if_requested() which checks for both like in > the normal TBIVM, because of two reasons: > - On one hand, I need to pass the "false" parameter to > SafepointSynchronize::block() to avoid blocking when transitioning in, > and avoid failing the test that we have a ThreadSafepointState of > _call_back when transitioing back. Without introducing > SafepointMechanism::callback_if_safepoint() I would have to modify a > couple of methods in SafepointMechanism to receive that extra > argument. I think this was cleaner. > -But even if I did add the extra argument to those functions and use > SafepointMechanism::block_if_requested(), I would need also to avoid > checking for handshakes in the TBIVMWDP constructor. The processing of > handshakes uses its own ThreadInVMForHandshake jacket which internally > calls SafepointMechanism::block_if_requested(). Since in the > constructor we do not block for safepoints, executing again > SafepointMechanism::block_if_requested() in a handshake would execute > SS::block twice. > So to solve that I just introduced > SafepointMechanism::callback_if_safepoint() which only checks for > safepoints and uses the extra argument in SS::block. > > Now, as to why I can't just check for global polls in > SafepointMechanism::callback_if_safepoint() (since I only want to > check/stop for safepoints), this has to do with the race found by > Robbin. Since the thread local poll is armed after changing _state to > _synchronizing, if I only do a global poll, > SafepointMechanism::callback_if_safepoint(in the TBIVMWDP constructor) > could detect there is a safepoint in progress and callback but when > coming back in the destructor SafepointMechanism::should_block() could > miss detecting the safepoint in progress since that method checks for > local polls first (it cares about both safepoints and handshakes). So > I need to match the order of checks done by > SafepointMechanism::should_block(). > > Any of this makes sense? Not really, but now I have a better way to ask about this. Here's should_block(): ? 50 bool SafepointMechanism::should_block(Thread* thread) { ? 51?? if (uses_thread_local_poll()) { ? 52???? return local_poll(thread); ? 53?? } else { ? 54???? return global_poll(); ? 55?? } ? 56 } If uses_thread_local_poll() == true, then we return the result of local_poll(thread) and skip calling global_poll(). Here's callback_if_safepoint(): ? 82 void SafepointMechanism::callback_if_safepoint(JavaThread* thread) { ? 83?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { ? 84???? if (global_poll()) { ? 85?????? SafepointSynchronize::block(thread, false); ? 86???? } ? 87?? } ? 88 } If uses_thread_local_poll() == false and global_poll() == true, then we call block(). If uses_thread_local_poll() == true and local_poll_armed() == true and global_poll() == true, then we call block(). Since we always check global_poll() == true before calling block(), then preceding expressions are moot. They do not affect whether we call block() at all. Dan > > > Thanks, > Patricio > >> Dan >> >> On 2/1/19 12:05 AM, Patricio Chilano wrote: >>> Hi David, >>> >>> On 1/31/19 12:54 AM, David Holmes wrote: >>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>> Hi David, >>>>> >>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>> Hi Patricio, >>>>>> >>>>>> >>>>>> >>>>>> First, thanks for all the many weeks of work you've put into >>>>>> this, pulling together a number of ideas from different people to >>>>>> make it all work! >>>>> Thanks! Credit to you for the PlatformMonitor implementation : ) >>>> >>>> :) Nothing innovative there. >>>> >>>>>> I've only got a few minor comments/suggestions. >>>>>> >>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>> Inc: >>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>> >>>>>> >>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>> >>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>>> masking the actual difference between the two wrappers to me. It >>>>>> seems to me that an extra arg to transition_and_fence should >>>>>> allow you to handle the new behaviour without having to duplicate >>>>>> so much of this code. In any case the semantics of >>>>>> ThreadLockBlockInVM needs to be described. >>>>> I could do it with one extra argument, but I would need to add two >>>>> extra branches in transition_and_fence(), one to decide if I'm in >>>>> the Monitor case to avoid calling >>>>> SafepointMechanism::block_if_requested() directly and another one >>>>> to actually decide if I'm transitioning in or out, since the >>>>> actions to perform are different. I think it is easier to read >>>>> without adding new conditionals, and also we will save those extra >>>>> branches, but if you think it's better this way I can change it. >>>> >>>> I would like something that tells me more clearly how this new >>>> transition helper differs from the existing TBIVM. Sharing the code >>>> between them and using different args would be one way. Documenting >>>> the difference in comments would be another. Your choice. >>> Ok, I added a description on top of TLBIVM. >>> >>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>>> refers to. I find the name quite jarring to read. >>>>> What about changing it to ThreadBlockinMonitor? >>>> >>>> That's not quite conveying the semantics. The problem is that the >>>> semantics we are changing compared to TBIVM are not evident in the >>>> TBIVM name. If TBIVM was actually >>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>> perhaps that lengthy, but clear name would be okay anyway? >>> Not convinced on that name since we are blocking at safepoints in >>> the destructor. Based on the comments I added how about >>> ThreadBlockinVMWithDeadlockPrevention ? or >>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>> conditions for deadlocks). >>> >>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>> don't really convey to me what happens - what is being >>>>>> "preempted" here? I would suggest a more direct >>>>>> Monitor::release_for_safepoint >>>>> Changed. >>>>> >>>>>> --- >>>>>> >>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>> need bother at all with the one logging statement that is present. >>>>> I added it to eventually track unbounded try locks. Not sure I >>>>> follow you with the name, isn't that how we name this monitors? I >>>>> tried to differentiate them from Java monitors. What about just >>>>> "monitor"? >>>> >>>> How about vmmonitor ? >>> Ok, changed. >>> >>>>>> --- >>>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> >>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>>> checks. >>>>>> >>>>>> The comment there should only say "not require". >>>>> Done. >>>>> >>>>>> void Monitor::preempt_by_safepoint() { >>>>>> ? _lock.unlock(); >>>>>> } >>>>>> >>>>>> Apart from renaming this as suggested above, aren't there any >>>>>> suitable assertions we should have here? safepoint-in-progress or >>>>>> handshake-in-progress? _owner == Thread::current? >>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>> safepoint-in-progress does not really work because _state could >>>>> change to _not_synchronized right after you checked for it in TLBIVM. >>>> >>>> Okay. >>>> >>>>>> Nit: >>>>>> >>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>> INTPTR_FORMAT >>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>> p2i(Thread::current())); >>>>>> >>>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>>> second line should indent to the first comma, but that will make >>>>>> the second line extend way past 80 columns. >>>>>> >>>>>> Also you could factor that assertion for >>>>>> _owner==Thread::current() into its own function or macro to avoid >>>>>> the repetition. >>>>> Corrected indentation based on Dan's reply to align with _owner. >>>> >>>> I though it should indent to the comma because it is a continuation >>>> of the same argument being passed to the assert "function". But I'm >>>> okay with Dan's suggestion. >>>> >>>> Factoring it into its own little function or macro would still be >>>> good to avoid the repetition. >>> Ok, added new function assert_owned_by_self(). I could change it to >>> assert_owner(Thread*) and use it for the NULL case too unifying the >>> printed messages to something like "invalid owner: owner=" >>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>> >>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>> Object.wait() */); >>>>>> >>>>>> This needs to be returned to its original place as per Dan's >>>>>> comments. >>>>> Done. >>>>> >>>>>> ??? } else { >>>>>> ????? Monitor::lock(self); >>>>>> ??? } >>>>>> >>>>>> You don't need Monitor:: here >>>>> Removed. >>>>> >>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>>> PlatformMonitor now. >>>>>> >>>>>> This needs to be resolved before committing. Some of the existing >>>>>> commentary on what raw monitors are needs to be retained. Not >>>>>> clear if we need to set the _owner field or can just skip it. >>>>> Is it okay if I keep the following comments? >>>>> >>>>> // Yet another degenerate version of Monitor::lock() or >>>>> lock_without_safepoint_check() >>>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>>> via JVM_RawMonitorEnter. >>>>> // >>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>> properly with the native >>>>> // Mutex-Monitor constructs.? We happen to implement >>>>> JVM_RawMonitors in terms of >>>>> // native Mutex-Monitors simply as a matter of convenience. >>>> >>>> Yep that's perfect. And as a future RFE we can replace them with >>>> direct use of PlatformMonitor (or PlatformMutex). >>>> >>>>> >>>>> I could keep setting the owner as _owner = >>>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>>> hurt. >>>> >>>> It's useful for checking usage errors, but we won't have that if we >>>> replace with PlatformMonitor, so may as well drop it now IMO. >>> Ok, I added asserts that _owner should be NULL after acquiring it >>> and before releasing it though. >>> >>>>>> Monitor::~Monitor() { >>>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>>> p2i(_owner)); >>>>>> } >>>>>> >>>>>> Will this automatically result in the PlatformMonitor destructor >>>>>> being called? >>>>> Yes, should I add a comment to make it clear that >>>>> ~PlatformMonitor() will be executed? >>>> >>>> No need - assume other people have a better understanding of C++ >>>> than I do :) >>> >>> Below is version v04, which also contains a correction pointed out >>> off-list by Robbin to do a local poll first in >>> SafepointMechanism::callback_if_safepoint() if we are using local >>> polls. Since the thread local poll is armed after changing _state to >>> _synchronizing, if we only do a global poll in the TLBIVM >>> constructor we could detect there is a safepoint in progress and >>> callback but when coming back in the destructor >>> SafepointMechanism::should_block() could miss detecting the >>> safepoint in progress since that method checks first for local polls. >>> >>> >>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>> >>> >>> Thanks, >>> Patricio >>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>> >>>>> Thanks, >>>>> Patricio >>>>>> --- >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>> >>> >> > From patricio.chilano.mateo at oracle.com Fri Feb 1 20:20:28 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 1 Feb 2019 15:20:28 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <6affcf41-321c-9a94-028f-43d1102ded90@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <9ebe68f4-5b36-f998-d7b1-b419f7f7983f@oracle.com> <922da8bc-6ba5-79df-5045-e72568cc7e1f@oracle.com> <6affcf41-321c-9a94-028f-43d1102ded90@oracle.com> Message-ID: Hi Dan, On 2/1/19 2:22 PM, Daniel D. Daugherty wrote: > On 2/1/19 1:01 PM, Patricio Chilano wrote: >> Hi Dan, >> >> On 2/1/19 11:10 AM, Daniel D. Daugherty wrote: >>> > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>> >>> src/hotspot/share/logging/logTag.hpp >>> ??? No comments. >>> >>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>> ??? L295: // - When transitioning in (constructor), it checks for >>> safepoints without having to block, i.e calls >>> ??????? Perhaps: >>> ????????? // - When transitioning in (constructor), it checks for >>> safepoints without blocking, i.e., calls >>> >>> ??? L298: //?? the monitor that is in the process of being acquired >>> (only setting the owner is missing). >>> ??????? Perhaps: >>> ????????? //?? the monitor that is only partially acquired. >> Done. >>> src/hotspot/share/runtime/mutex.cpp >>> ??? L59: log_trace(vmmonitor)("JavaThread " INTPTR_FORMAT " on %d >>> attempt trying to acquire native monitor %s", p2i(self), retry_cnt, >>> _name); >>> ??????? nit - s/native monitor/vmmonitor/? - for consistency. >> Done. >> >>> src/hotspot/share/runtime/mutex.hpp >>> ??? No comments. >>> >>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>> ??? L83: ? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >>> ??? L84: ??? if (global_poll()) { >>> ??????? I'm having trouble with this construct: >>> >>> ??????? - if uses_thread_local_poll() is false, then we check >>> global_poll() >>> ????????? and call SafepointSynchronize::block() if global_poll() == >>> true. >>> ????????? That makes sense since we're not using local polling. >>> >>> ??????? - if uses_thread_local_poll() is true, then we check >>> ????????? if local_poll_armed(thread) == true and then we check >>> global_poll() >>> ????????? and call SafepointSynchronize::block() if global_poll() == >>> true. >>> >>> ????????? Huh? >>> >>> ??????? So we only call SafepointSynchronize::block() if >>> global_poll() == true >>> ??????? no matter what. It seems like the checks for local polling >>> don't really >>> ??????? do anything here. >>> >>> ??????? What am I missing? >> A couple of observations before going straight to the question. The >> check for local poll in SafepointMechanism::should_block() (TBIVMWDP >> destructor) is needed because we need to check for both, pending >> safepoints or pending handshakes. In other words once we transition >> back from the _thread_blocked state, there could be either a >> safepoint or a handshake for that thread being processed. If >> SafepointMechanism::should_block() returns true, then >> SafepointMechanism::callback_if_safepoint() only checks for pending >> safepoints. After that I do the check "if (_thread->has_handshake())" >> for pending handshakes. I couldn't use >> SafepointMechanism::block_if_requested() which checks for both like >> in the normal TBIVM, because of two reasons: >> - On one hand, I need to pass the "false" parameter to >> SafepointSynchronize::block() to avoid blocking when transitioning >> in, and avoid failing the test that we have a ThreadSafepointState of >> _call_back when transitioing back. Without introducing >> SafepointMechanism::callback_if_safepoint() I would have to modify a >> couple of methods in SafepointMechanism to receive that extra >> argument. I think this was cleaner. >> -But even if I did add the extra argument to those functions and use >> SafepointMechanism::block_if_requested(), I would need also to avoid >> checking for handshakes in the TBIVMWDP constructor. The processing >> of handshakes uses its own ThreadInVMForHandshake jacket which >> internally calls SafepointMechanism::block_if_requested(). Since in >> the constructor we do not block for safepoints, executing again >> SafepointMechanism::block_if_requested() in a handshake would execute >> SS::block twice. >> So to solve that I just introduced >> SafepointMechanism::callback_if_safepoint() which only checks for >> safepoints and uses the extra argument in SS::block. >> >> Now, as to why I can't just check for global polls in >> SafepointMechanism::callback_if_safepoint() (since I only want to >> check/stop for safepoints), this has to do with the race found by >> Robbin. Since the thread local poll is armed after changing _state to >> _synchronizing, if I only do a global poll, >> SafepointMechanism::callback_if_safepoint(in the TBIVMWDP >> constructor) could detect there is a safepoint in progress and >> callback but when coming back in the destructor >> SafepointMechanism::should_block() could miss detecting the safepoint >> in progress since that method checks for local polls first (it cares >> about both safepoints and handshakes). So I need to match the order >> of checks done by SafepointMechanism::should_block(). >> >> Any of this makes sense? > > Not really, but now I have a better way to ask about this. > > Here's should_block(): > > ? 50 bool SafepointMechanism::should_block(Thread* thread) { > ? 51?? if (uses_thread_local_poll()) { > ? 52???? return local_poll(thread); > ? 53?? } else { > ? 54???? return global_poll(); > ? 55?? } > ? 56 } > > If uses_thread_local_poll() == true, then we return the result > of local_poll(thread) and skip calling global_poll(). > > Here's callback_if_safepoint(): > > ? 82 void SafepointMechanism::callback_if_safepoint(JavaThread* thread) { > ? 83?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { > ? 84???? if (global_poll()) { > ? 85?????? SafepointSynchronize::block(thread, false); > ? 86???? } > ? 87?? } > ? 88 } > > If uses_thread_local_poll() == false and global_poll() == true, > then we call block(). > If uses_thread_local_poll() == true and local_poll_armed() == true > and global_poll() == true, then we call block(). > > Since we always check global_poll() == true before calling block(), > then preceding expressions are moot. They do not affect whether we > call block() at all. It's true that those checks for local poll are not actually needed if you get to execute SafepointMechanism::callback_if_safepoint() in the TBIVMWDP destructor. At that point I could just check for global_poll(). But because I'm previously executing SafepointMechanism::should_block() to first decide whether or not I need to block for a safepoint or handshake, that forces me to add the local polls checks when executing SafepointMechanism::callback_if_safepoint() in the TBIVMWDP constructor. Otherwise let's say I removed them: 1- VMThread in SafepointSynchronize::begin() executes? "_state = _synchronizing;" and gets context switched by the OS. 2 - JavaThread executes SafepointMechanism::callback_if_safepoint() in TBIVMWDP constructor, checks global_poll() which returns true, and callsback for safepoint without blocking. 3- JavaThread goes into the _thread_blocked state and blocks, let's say in "_lock.lock();" in Monitor::lock(). 4- JavaThread acquires the lock and transitions back. In the TBIVMWDP destructor calls SafepointMechanism::should_block(). If we are using local polls, should_block() will check local_poll_armed(). That will return false since the VMThread didn't armed the local poll yet. 5- JavaThread continues to execute in VM. 6- VMThread is scheduled again, and arms local polls. At this point you can have serveral problems, either the JavaThread could try to callback again(i.e twice) at some point later, or not and the safepoint will start while that JavaThread is executing in the VM. I could add another argument in SafepointMechanism::callback_if_safepoint() to skip checking local polls in the destructor if that's what you mean. Patricio > Dan > > >> >> >> Thanks, >> Patricio >> >>> Dan >>> >>> On 2/1/19 12:05 AM, Patricio Chilano wrote: >>>> Hi David, >>>> >>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>> Hi David, >>>>>> >>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>> Hi Patricio, >>>>>>> >>>>>>> >>>>>>> >>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>> this, pulling together a number of ideas from different people >>>>>>> to make it all work! >>>>>> Thanks! Credit to you for the PlatformMonitor implementation : ) >>>>> >>>>> :) Nothing innovative there. >>>>> >>>>>>> I've only got a few minor comments/suggestions. >>>>>>> >>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>> Inc: >>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>> >>>>>>> >>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>> >>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which >>>>>>> is masking the actual difference between the two wrappers to me. >>>>>>> It seems to me that an extra arg to transition_and_fence should >>>>>>> allow you to handle the new behaviour without having to >>>>>>> duplicate so much of this code. In any case the semantics of >>>>>>> ThreadLockBlockInVM needs to be described. >>>>>> I could do it with one extra argument, but I would need to add >>>>>> two extra branches in transition_and_fence(), one to decide if >>>>>> I'm in the Monitor case to avoid calling >>>>>> SafepointMechanism::block_if_requested() directly and another one >>>>>> to actually decide if I'm transitioning in or out, since the >>>>>> actions to perform are different. I think it is easier to read >>>>>> without adding new conditionals, and also we will save those >>>>>> extra branches, but if you think it's better this way I can >>>>>> change it. >>>>> >>>>> I would like something that tells me more clearly how this new >>>>> transition helper differs from the existing TBIVM. Sharing the >>>>> code between them and using different args would be one way. >>>>> Documenting the difference in comments would be another. Your choice. >>>> Ok, I added a description on top of TLBIVM. >>>> >>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>>>> refers to. I find the name quite jarring to read. >>>>>> What about changing it to ThreadBlockinMonitor? >>>>> >>>>> That's not quite conveying the semantics. The problem is that the >>>>> semantics we are changing compared to TBIVM are not evident in the >>>>> TBIVM name. If TBIVM was actually >>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>> perhaps that lengthy, but clear name would be okay anyway? >>>> Not convinced on that name since we are blocking at safepoints in >>>> the destructor. Based on the comments I added how about >>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>> conditions for deadlocks). >>>> >>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>> don't really convey to me what happens - what is being >>>>>>> "preempted" here? I would suggest a more direct >>>>>>> Monitor::release_for_safepoint >>>>>> Changed. >>>>>> >>>>>>> --- >>>>>>> >>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>>> need bother at all with the one logging statement that is present. >>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>> follow you with the name, isn't that how we name this monitors? I >>>>>> tried to differentiate them from Java monitors. What about just >>>>>> "monitor"? >>>>> >>>>> How about vmmonitor ? >>>> Ok, changed. >>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> >>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>>>> checks. >>>>>>> >>>>>>> The comment there should only say "not require". >>>>>> Done. >>>>>> >>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>> ? _lock.unlock(); >>>>>>> } >>>>>>> >>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>> suitable assertions we should have here? safepoint-in-progress >>>>>>> or handshake-in-progress? _owner == Thread::current? >>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>> safepoint-in-progress does not really work because _state could >>>>>> change to _not_synchronized right after you checked for it in >>>>>> TLBIVM. >>>>> >>>>> Okay. >>>>> >>>>>>> Nit: >>>>>>> >>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>> INTPTR_FORMAT >>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>> p2i(Thread::current())); >>>>>>> >>>>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>>>> second line should indent to the first comma, but that will make >>>>>>> the second line extend way past 80 columns. >>>>>>> >>>>>>> Also you could factor that assertion for >>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>> avoid the repetition. >>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>> >>>>> I though it should indent to the comma because it is a >>>>> continuation of the same argument being passed to the assert >>>>> "function". But I'm okay with Dan's suggestion. >>>>> >>>>> Factoring it into its own little function or macro would still be >>>>> good to avoid the repetition. >>>> Ok, added new function assert_owned_by_self(). I could change it to >>>> assert_owner(Thread*) and use it for the NULL case too unifying the >>>> printed messages to something like "invalid owner: owner=" >>>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>>> >>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>> Object.wait() */); >>>>>>> >>>>>>> This needs to be returned to its original place as per Dan's >>>>>>> comments. >>>>>> Done. >>>>>> >>>>>>> ??? } else { >>>>>>> ????? Monitor::lock(self); >>>>>>> ??? } >>>>>>> >>>>>>> You don't need Monitor:: here >>>>>> Removed. >>>>>> >>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be >>>>>>> a PlatformMonitor now. >>>>>>> >>>>>>> This needs to be resolved before committing. Some of the >>>>>>> existing commentary on what raw monitors are needs to be >>>>>>> retained. Not clear if we need to set the _owner field or can >>>>>>> just skip it. >>>>>> Is it okay if I keep the following comments? >>>>>> >>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>> lock_without_safepoint_check() >>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>>>> via JVM_RawMonitorEnter. >>>>>> // >>>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>>> properly with the native >>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>> JVM_RawMonitors in terms of >>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>> >>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>> >>>>>> >>>>>> I could keep setting the owner as _owner = >>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>>>> hurt. >>>>> >>>>> It's useful for checking usage errors, but we won't have that if >>>>> we replace with PlatformMonitor, so may as well drop it now IMO. >>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>> and before releasing it though. >>>> >>>>>>> Monitor::~Monitor() { >>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>>>> p2i(_owner)); >>>>>>> } >>>>>>> >>>>>>> Will this automatically result in the PlatformMonitor destructor >>>>>>> being called? >>>>>> Yes, should I add a comment to make it clear that >>>>>> ~PlatformMonitor() will be executed? >>>>> >>>>> No need - assume other people have a better understanding of C++ >>>>> than I do :) >>>> >>>> Below is version v04, which also contains a correction pointed out >>>> off-list by Robbin to do a local poll first in >>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>> polls. Since the thread local poll is armed after changing _state >>>> to _synchronizing, if we only do a global poll in the TLBIVM >>>> constructor we could detect there is a safepoint in progress and >>>> callback but when coming back in the destructor >>>> SafepointMechanism::should_block() could miss detecting the >>>> safepoint in progress since that method checks first for local polls. >>>> >>>> >>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>> >>>> >>>> Thanks, >>>> Patricio >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> >>>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>>> --- >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>> >>>> >>> >> > From kim.barrett at oracle.com Fri Feb 1 20:53:05 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Feb 2019 15:53:05 -0500 Subject: RFR: 8218202: gc/stress/TestStressG1Humongous.java to ProblemList-graal.txt Message-ID: Please review this addition to ProblemList-graal.txt. See comment in main bug for details: https://bugs.openjdk.java.net/browse/JDK-8218176?focusedCommentId=14242017&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14242017 CR: https://bugs.openjdk.java.net/browse/JDK-8218202 Main Bug: https://bugs.openjdk.java.net/browse/JDK-8218176 Webrev: http://cr.openjdk.java.net/~kbarrett/8218202/open.00/ Testing: Locally verified exclusion of test when using ProblemList-graal.txt From coleen.phillimore at oracle.com Fri Feb 1 21:13:44 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 1 Feb 2019 16:13:44 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <0c45ed83-e04c-c640-2cac-ae6581faeebf@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <0c45ed83-e04c-c640-2cac-ae6581faeebf@oracle.com> Message-ID: On 2/1/19 1:31 AM, Patricio Chilano wrote: > Hi David, > > On 2/1/19 12:34 AM, David Holmes wrote: >> Hi Patricio, >> >> Comments on inc v4: >> >> src/hotspot/share/runtime/safepointMechanism.inline.hpp >> >> +?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >> >> Need space after if. >> >> I trust Robbin's judgement that this is the right way to express >> this, but if ordering is so critical it should be documented. > He didn't propose that exact line but local_poll_armed() is a load > acquire so should be okay. But let's see what Robbin says. > >> --- >> >> src/hotspot/share/runtime/mutex.hpp/.cpp >> >> assert_owned_by_self doesn't need to be a member function, it can >> just be a file static in the .cpp file. No need to clutter the API. >> >> Using a version that takes the owner thread is a good idea for >> checking the NULL case too. > Done. > >> --- >> >> src/hotspot/share/runtime/interfaceSupport.inline.hpp >> >> I like the comment block - thanks! A couple of minor things: >> >> + // are trying to acquire. This will be used to access and release >> the monitor in case needed to avoid >> >> s/in case/if/ > Done. > >> + // the monitor that is in the process of being acquired (only >> setting the owner is missing). >> >> I think the part in parentheses can be dropped - it reads like you >> should be setting the owner but have chosen not to for some reason. > Done. > >> + // The logic of this class could have been integrated into a more >> general ThreadBlockInVM. By using a >> + // separate class though, we avoid executing branches that would >> otherwise be needed to identify each >> + // case. >> >> Not necessary IMHO but up to you whether to keep or drop. > Dropped. > >> In regards to the name ThreadLockBlockInVM ... I don't have a good >> suggestion. >> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is rather >> unwieldy. ;-) But the "Lock" part really doesn't mean anything. So >> your suggestion of ThreadBlockinVMWithDeadlockPrevention seems a big >> improvement to me. :) > ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut was the > right one, too bad it's so long =D. Ok, I''ll leave > ThreadBlockInVMWithDeadlockPrevention, if anybody comes up with a > better one I can change it. I want ThreadLockBlockInVM - yah it looks the same as ThreadBlockInVM but I'd rather the name say that it's used for Locks vs some specifics about what it does.? I hope all the jackets prevent deadlock!? So my vote is to leave the name as in version 1. Coleen > > I'll wait for Robbin then to send v05. > > Thanks! > Patricio > >> Thanks, >> David >> ----- >> >> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>> Hi David, >>> >>> On 1/31/19 12:54 AM, David Holmes wrote: >>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>> Hi David, >>>>> >>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>> Hi Patricio, >>>>>> >>>>>> >>>>>> >>>>>> First, thanks for all the many weeks of work you've put into >>>>>> this, pulling together a number of ideas from different people to >>>>>> make it all work! >>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>> >>>> :) Nothing innovative there. >>>> >>>>>> I've only got a few minor comments/suggestions. >>>>>> >>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>> Inc: >>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>> >>>>>> >>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>> >>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>>> masking the actual difference between the two wrappers to me. It >>>>>> seems to me that an extra arg to transition_and_fence should >>>>>> allow you to handle the new behaviour without having to duplicate >>>>>> so much of this code. In any case the semantics of >>>>>> ThreadLockBlockInVM needs to be described. >>>>> I could do it with one extra argument, but I would need to add two >>>>> extra branches in transition_and_fence(), one to decide if I'm in >>>>> the Monitor case to avoid calling >>>>> SafepointMechanism::block_if_requested() directly and another one >>>>> to actually decide if I'm transitioning in or out, since the >>>>> actions to perform are different. I think it is easier to read >>>>> without adding new conditionals, and also we will save those extra >>>>> branches, but if you think it's better this way I can change it. >>>> >>>> I would like something that tells me more clearly how this new >>>> transition helper differs from the existing TBIVM. Sharing the code >>>> between them and using different args would be one way. Documenting >>>> the difference in comments would be another. Your choice. >>> Ok, I added a description on top of TLBIVM. >>> >>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>>> refers to. I find the name quite jarring to read. >>>>> What about changing it to ThreadBlockinMonitor? >>>> >>>> That's not quite conveying the semantics. The problem is that the >>>> semantics we are changing compared to TBIVM are not evident in the >>>> TBIVM name. If TBIVM was actually >>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>> perhaps that lengthy, but clear name would be okay anyway? >>> Not convinced on that name since we are blocking at safepoints in >>> the destructor. Based on the comments I added how about >>> ThreadBlockinVMWithDeadlockPrevention ? or >>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>> conditions for deadlocks). >>> >>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>> don't really convey to me what happens - what is being >>>>>> "preempted" here? I would suggest a more direct >>>>>> Monitor::release_for_safepoint >>>>> Changed. >>>>> >>>>>> --- >>>>>> >>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>> need bother at all with the one logging statement that is present. >>>>> I added it to eventually track unbounded try locks. Not sure I >>>>> follow you with the name, isn't that how we name this monitors? I >>>>> tried to differentiate them from Java monitors. What about just >>>>> "monitor"? >>>> >>>> How about vmmonitor ? >>> Ok, changed. >>> >>>>>> --- >>>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> >>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>>> checks. >>>>>> >>>>>> The comment there should only say "not require". >>>>> Done. >>>>> >>>>>> void Monitor::preempt_by_safepoint() { >>>>>> ? _lock.unlock(); >>>>>> } >>>>>> >>>>>> Apart from renaming this as suggested above, aren't there any >>>>>> suitable assertions we should have here? safepoint-in-progress or >>>>>> handshake-in-progress? _owner == Thread::current? >>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>> safepoint-in-progress does not really work because _state could >>>>> change to _not_synchronized right after you checked for it in TLBIVM. >>>> >>>> Okay. >>>> >>>>>> Nit: >>>>>> >>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>> INTPTR_FORMAT >>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>> p2i(Thread::current())); >>>>>> >>>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>>> second line should indent to the first comma, but that will make >>>>>> the second line extend way past 80 columns. >>>>>> >>>>>> Also you could factor that assertion for >>>>>> _owner==Thread::current() into its own function or macro to avoid >>>>>> the repetition. >>>>> Corrected indentation based on Dan's reply to align with _owner. >>>> >>>> I though it should indent to the comma because it is a continuation >>>> of the same argument being passed to the assert "function". But I'm >>>> okay with Dan's suggestion. >>>> >>>> Factoring it into its own little function or macro would still be >>>> good to avoid the repetition. >>> Ok, added new function assert_owned_by_self(). I could change it to >>> assert_owner(Thread*) and use it for the NULL case too unifying the >>> printed messages to something like "invalid owner: owner=" >>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>> >>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>> Object.wait() */); >>>>>> >>>>>> This needs to be returned to its original place as per Dan's >>>>>> comments. >>>>> Done. >>>>> >>>>>> ??? } else { >>>>>> ????? Monitor::lock(self); >>>>>> ??? } >>>>>> >>>>>> You don't need Monitor:: here >>>>> Removed. >>>>> >>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>>> PlatformMonitor now. >>>>>> >>>>>> This needs to be resolved before committing. Some of the existing >>>>>> commentary on what raw monitors are needs to be retained. Not >>>>>> clear if we need to set the _owner field or can just skip it. >>>>> Is it okay if I keep the following comments? >>>>> >>>>> // Yet another degenerate version of Monitor::lock() or >>>>> lock_without_safepoint_check() >>>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>>> via JVM_RawMonitorEnter. >>>>> // >>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>> properly with the native >>>>> // Mutex-Monitor constructs.? We happen to implement >>>>> JVM_RawMonitors in terms of >>>>> // native Mutex-Monitors simply as a matter of convenience. >>>> >>>> Yep that's perfect. And as a future RFE we can replace them with >>>> direct use of PlatformMonitor (or PlatformMutex). >>>> >>>>> >>>>> I could keep setting the owner as _owner = >>>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>>> hurt. >>>> >>>> It's useful for checking usage errors, but we won't have that if we >>>> replace with PlatformMonitor, so may as well drop it now IMO. >>> Ok, I added asserts that _owner should be NULL after acquiring it >>> and before releasing it though. >>> >>>>>> Monitor::~Monitor() { >>>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>>> p2i(_owner)); >>>>>> } >>>>>> >>>>>> Will this automatically result in the PlatformMonitor destructor >>>>>> being called? >>>>> Yes, should I add a comment to make it clear that >>>>> ~PlatformMonitor() will be executed? >>>> >>>> No need - assume other people have a better understanding of C++ >>>> than I do :) >>> >>> Below is version v04, which also contains a correction pointed out >>> off-list by Robbin to do a local poll first in >>> SafepointMechanism::callback_if_safepoint() if we are using local >>> polls. Since the thread local poll is armed after changing _state to >>> _synchronizing, if we only do a global poll in the TLBIVM >>> constructor we could detect there is a safepoint in progress and >>> callback but when coming back in the destructor >>> SafepointMechanism::should_block() could miss detecting the >>> safepoint in progress since that method checks first for local polls. >>> >>> >>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>> >>> >>> Thanks, >>> Patricio >>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>> >>>>> Thanks, >>>>> Patricio >>>>>> --- >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>> >>> > From coleen.phillimore at oracle.com Fri Feb 1 21:28:46 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 1 Feb 2019 16:28:46 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: On 2/1/19 12:34 AM, David Holmes wrote: > Hi Patricio, > > Comments on inc v4: > > src/hotspot/share/runtime/safepointMechanism.inline.hpp > > +?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { > > Need space after if. > > I trust Robbin's judgement that this is the right way to express this, > but if ordering is so critical it should be documented. > > --- > > src/hotspot/share/runtime/mutex.hpp/.cpp > > assert_owned_by_self doesn't need to be a member function, it can just > be a file static in the .cpp file. No need to clutter the API. > > Using a version that takes the owner thread is a good idea for > checking the NULL case too. > > --- > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > > I like the comment block - thanks! A couple of minor things: > > + // are trying to acquire. This will be used to access and release > the monitor in case needed to avoid > > s/in case/if/ > > + //?? the monitor that is in the process of being acquired (only > setting the owner is missing). > > I think the part in parentheses can be dropped - it reads like you > should be setting the owner but have chosen not to for some reason. > > + // The logic of this class could have been integrated into a more > general ThreadBlockInVM. By using a > + // separate class though, we avoid executing branches that would > otherwise be needed to identify each > + // case. > > Not necessary IMHO but up to you whether to keep or drop. > > In regards to the name ThreadLockBlockInVM ... I don't have a good > suggestion. > ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is rather > unwieldy. ;-) But the "Lock" part really doesn't mean anything. So > your suggestion of ThreadBlockinVMWithDeadlockPrevention seems a big > improvement to me. :) How about ThreadBlockInVMForLock ??? This answers the question "why" this class, vs. "what" this class does.? Since the latter can change. thanks, Coleen > > Thanks, > David > ----- > > On 1/02/2019 3:05 pm, Patricio Chilano wrote: >> Hi David, >> >> On 1/31/19 12:54 AM, David Holmes wrote: >>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>> Hi David, >>>> >>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>> Hi Patricio, >>>>> >>>>> >>>>> >>>>> First, thanks for all the many weeks of work you've put into this, >>>>> pulling together a number of ideas from different people to make >>>>> it all work! >>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>> >>> :) Nothing innovative there. >>> >>>>> I've only got a few minor comments/suggestions. >>>>> >>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>> Inc: >>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>> >>>>> >>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>> >>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>> masking the actual difference between the two wrappers to me. It >>>>> seems to me that an extra arg to transition_and_fence should allow >>>>> you to handle the new behaviour without having to duplicate so >>>>> much of this code. In any case the semantics of >>>>> ThreadLockBlockInVM needs to be described. >>>> I could do it with one extra argument, but I would need to add two >>>> extra branches in transition_and_fence(), one to decide if I'm in >>>> the Monitor case to avoid calling >>>> SafepointMechanism::block_if_requested() directly and another one >>>> to actually decide if I'm transitioning in or out, since the >>>> actions to perform are different. I think it is easier to read >>>> without adding new conditionals, and also we will save those extra >>>> branches, but if you think it's better this way I can change it. >>> >>> I would like something that tells me more clearly how this new >>> transition helper differs from the existing TBIVM. Sharing the code >>> between them and using different args would be one way. Documenting >>> the difference in comments would be another. Your choice. >> Ok, I added a description on top of TLBIVM. >> >>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>> refers to. I find the name quite jarring to read. >>>> What about changing it to ThreadBlockinMonitor? >>> >>> That's not quite conveying the semantics. The problem is that the >>> semantics we are changing compared to TBIVM are not evident in the >>> TBIVM name. If TBIVM was actually >>> ThreadBlockInVMWithSafepointBlocking, then this new transition would >>> obviously be ThreadBlockInVMWithoutSafepointBlocking - but perhaps >>> that lengthy, but clear name would be okay anyway? >> Not convinced on that name since we are blocking at safepoints in the >> destructor. Based on the comments I added how about >> ThreadBlockinVMWithDeadlockPrevention ? or >> ThreadBlockinVMWithPreemption? (as in eliminate one of the conditions >> for deadlocks). >> >>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>> don't really convey to me what happens - what is being "preempted" >>>>> here? I would suggest a more direct Monitor::release_for_safepoint >>>> Changed. >>>> >>>>> --- >>>>> >>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>> need bother at all with the one logging statement that is present. >>>> I added it to eventually track unbounded try locks. Not sure I >>>> follow you with the name, isn't that how we name this monitors? I >>>> tried to differentiate them from Java monitors. What about just >>>> "monitor"? >>> >>> How about vmmonitor ? >> Ok, changed. >> >>>>> --- >>>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> >>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>> checks. >>>>> >>>>> The comment there should only say "not require". >>>> Done. >>>> >>>>> void Monitor::preempt_by_safepoint() { >>>>> ? _lock.unlock(); >>>>> } >>>>> >>>>> Apart from renaming this as suggested above, aren't there any >>>>> suitable assertions we should have here? safepoint-in-progress or >>>>> handshake-in-progress? _owner == Thread::current? >>>> Ok, I added an assertion that owner should be NULL. Asserting >>>> safepoint-in-progress does not really work because _state could >>>> change to _not_synchronized right after you checked for it in TLBIVM. >>> >>> Okay. >>> >>>>> Nit: >>>>> >>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>> INTPTR_FORMAT >>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>> p2i(Thread::current())); >>>>> >>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>> second line should indent to the first comma, but that will make >>>>> the second line extend way past 80 columns. >>>>> >>>>> Also you could factor that assertion for _owner==Thread::current() >>>>> into its own function or macro to avoid the repetition. >>>> Corrected indentation based on Dan's reply to align with _owner. >>> >>> I though it should indent to the comma because it is a continuation >>> of the same argument being passed to the assert "function". But I'm >>> okay with Dan's suggestion. >>> >>> Factoring it into its own little function or macro would still be >>> good to avoid the repetition. >> Ok, added new function assert_owned_by_self(). I could change it to >> assert_owner(Thread*) and use it for the NULL case too unifying the >> printed messages to something like "invalid owner: owner=" >> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >> >>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>> Object.wait() */); >>>>> >>>>> This needs to be returned to its original place as per Dan's >>>>> comments. >>>> Done. >>>> >>>>> ??? } else { >>>>> ????? Monitor::lock(self); >>>>> ??? } >>>>> >>>>> You don't need Monitor:: here >>>> Removed. >>>> >>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>> PlatformMonitor now. >>>>> >>>>> This needs to be resolved before committing. Some of the existing >>>>> commentary on what raw monitors are needs to be retained. Not >>>>> clear if we need to set the _owner field or can just skip it. >>>> Is it okay if I keep the following comments? >>>> >>>> // Yet another degenerate version of Monitor::lock() or >>>> lock_without_safepoint_check() >>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>> via JVM_RawMonitorEnter. >>>> // >>>> // There's no expectation that JVM_RawMonitors will interoperate >>>> properly with the native >>>> // Mutex-Monitor constructs.? We happen to implement >>>> JVM_RawMonitors in terms of >>>> // native Mutex-Monitors simply as a matter of convenience. >>> >>> Yep that's perfect. And as a future RFE we can replace them with >>> direct use of PlatformMonitor (or PlatformMutex). >>> >>>> >>>> I could keep setting the owner as _owner = >>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>> hurt. >>> >>> It's useful for checking usage errors, but we won't have that if we >>> replace with PlatformMonitor, so may as well drop it now IMO. >> Ok, I added asserts that _owner should be NULL after acquiring it and >> before releasing it though. >> >>>>> Monitor::~Monitor() { >>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>> p2i(_owner)); >>>>> } >>>>> >>>>> Will this automatically result in the PlatformMonitor destructor >>>>> being called? >>>> Yes, should I add a comment to make it clear that >>>> ~PlatformMonitor() will be executed? >>> >>> No need - assume other people have a better understanding of C++ >>> than I do :) >> >> Below is version v04, which also contains a correction pointed out >> off-list by Robbin to do a local poll first in >> SafepointMechanism::callback_if_safepoint() if we are using local >> polls. Since the thread local poll is armed after changing _state to >> _synchronizing, if we only do a global poll in the TLBIVM constructor >> we could detect there is a safepoint in progress and callback but >> when coming back in the destructor SafepointMechanism::should_block() >> could miss detecting the safepoint in progress since that method >> checks first for local polls. >> >> >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >> >> >> Thanks, >> Patricio >> >>> Thanks, >>> David >>> >>>> >>>> >>>> Thanks for looking into this! Waiting on your comments to send v04. >>>> >>>> Thanks, >>>> Patricio >>>>> --- >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>> >> From patricio.chilano.mateo at oracle.com Fri Feb 1 21:48:31 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 1 Feb 2019 16:48:31 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: Hi Coleen, On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: > > > On 2/1/19 12:34 AM, David Holmes wrote: >> Hi Patricio, >> >> Comments on inc v4: >> >> src/hotspot/share/runtime/safepointMechanism.inline.hpp >> >> +?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >> >> Need space after if. >> >> I trust Robbin's judgement that this is the right way to express >> this, but if ordering is so critical it should be documented. >> >> --- >> >> src/hotspot/share/runtime/mutex.hpp/.cpp >> >> assert_owned_by_self doesn't need to be a member function, it can >> just be a file static in the .cpp file. No need to clutter the API. >> >> Using a version that takes the owner thread is a good idea for >> checking the NULL case too. >> >> --- >> >> src/hotspot/share/runtime/interfaceSupport.inline.hpp >> >> I like the comment block - thanks! A couple of minor things: >> >> + // are trying to acquire. This will be used to access and release >> the monitor in case needed to avoid >> >> s/in case/if/ >> >> + //?? the monitor that is in the process of being acquired (only >> setting the owner is missing). >> >> I think the part in parentheses can be dropped - it reads like you >> should be setting the owner but have chosen not to for some reason. >> >> + // The logic of this class could have been integrated into a more >> general ThreadBlockInVM. By using a >> + // separate class though, we avoid executing branches that would >> otherwise be needed to identify each >> + // case. >> >> Not necessary IMHO but up to you whether to keep or drop. >> >> In regards to the name ThreadLockBlockInVM ... I don't have a good >> suggestion. >> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is rather >> unwieldy. ;-) But the "Lock" part really doesn't mean anything. So >> your suggestion of ThreadBlockinVMWithDeadlockPrevention seems a big >> improvement to me. :) > > How about ThreadBlockInVMForLock ??? This answers the question "why" > this class, vs. "what" this class does.? Since the latter can change. I like that name. Is that name okay with you David? Thanks, Patricio > thanks, > Coleen > >> >> Thanks, >> David >> ----- >> >> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>> Hi David, >>> >>> On 1/31/19 12:54 AM, David Holmes wrote: >>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>> Hi David, >>>>> >>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>> Hi Patricio, >>>>>> >>>>>> >>>>>> >>>>>> First, thanks for all the many weeks of work you've put into >>>>>> this, pulling together a number of ideas from different people to >>>>>> make it all work! >>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>> >>>> :) Nothing innovative there. >>>> >>>>>> I've only got a few minor comments/suggestions. >>>>>> >>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>> Inc: >>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>> >>>>>> >>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>> >>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>>> masking the actual difference between the two wrappers to me. It >>>>>> seems to me that an extra arg to transition_and_fence should >>>>>> allow you to handle the new behaviour without having to duplicate >>>>>> so much of this code. In any case the semantics of >>>>>> ThreadLockBlockInVM needs to be described. >>>>> I could do it with one extra argument, but I would need to add two >>>>> extra branches in transition_and_fence(), one to decide if I'm in >>>>> the Monitor case to avoid calling >>>>> SafepointMechanism::block_if_requested() directly and another one >>>>> to actually decide if I'm transitioning in or out, since the >>>>> actions to perform are different. I think it is easier to read >>>>> without adding new conditionals, and also we will save those extra >>>>> branches, but if you think it's better this way I can change it. >>>> >>>> I would like something that tells me more clearly how this new >>>> transition helper differs from the existing TBIVM. Sharing the code >>>> between them and using different args would be one way. Documenting >>>> the difference in comments would be another. Your choice. >>> Ok, I added a description on top of TLBIVM. >>> >>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>>> refers to. I find the name quite jarring to read. >>>>> What about changing it to ThreadBlockinMonitor? >>>> >>>> That's not quite conveying the semantics. The problem is that the >>>> semantics we are changing compared to TBIVM are not evident in the >>>> TBIVM name. If TBIVM was actually >>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>> perhaps that lengthy, but clear name would be okay anyway? >>> Not convinced on that name since we are blocking at safepoints in >>> the destructor. Based on the comments I added how about >>> ThreadBlockinVMWithDeadlockPrevention ? or >>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>> conditions for deadlocks). >>> >>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>> don't really convey to me what happens - what is being >>>>>> "preempted" here? I would suggest a more direct >>>>>> Monitor::release_for_safepoint >>>>> Changed. >>>>> >>>>>> --- >>>>>> >>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>> need bother at all with the one logging statement that is present. >>>>> I added it to eventually track unbounded try locks. Not sure I >>>>> follow you with the name, isn't that how we name this monitors? I >>>>> tried to differentiate them from Java monitors. What about just >>>>> "monitor"? >>>> >>>> How about vmmonitor ? >>> Ok, changed. >>> >>>>>> --- >>>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> >>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>>> checks. >>>>>> >>>>>> The comment there should only say "not require". >>>>> Done. >>>>> >>>>>> void Monitor::preempt_by_safepoint() { >>>>>> ? _lock.unlock(); >>>>>> } >>>>>> >>>>>> Apart from renaming this as suggested above, aren't there any >>>>>> suitable assertions we should have here? safepoint-in-progress or >>>>>> handshake-in-progress? _owner == Thread::current? >>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>> safepoint-in-progress does not really work because _state could >>>>> change to _not_synchronized right after you checked for it in TLBIVM. >>>> >>>> Okay. >>>> >>>>>> Nit: >>>>>> >>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>> INTPTR_FORMAT >>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>> p2i(Thread::current())); >>>>>> >>>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>>> second line should indent to the first comma, but that will make >>>>>> the second line extend way past 80 columns. >>>>>> >>>>>> Also you could factor that assertion for >>>>>> _owner==Thread::current() into its own function or macro to avoid >>>>>> the repetition. >>>>> Corrected indentation based on Dan's reply to align with _owner. >>>> >>>> I though it should indent to the comma because it is a continuation >>>> of the same argument being passed to the assert "function". But I'm >>>> okay with Dan's suggestion. >>>> >>>> Factoring it into its own little function or macro would still be >>>> good to avoid the repetition. >>> Ok, added new function assert_owned_by_self(). I could change it to >>> assert_owner(Thread*) and use it for the NULL case too unifying the >>> printed messages to something like "invalid owner: owner=" >>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>> >>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>> Object.wait() */); >>>>>> >>>>>> This needs to be returned to its original place as per Dan's >>>>>> comments. >>>>> Done. >>>>> >>>>>> ??? } else { >>>>>> ????? Monitor::lock(self); >>>>>> ??? } >>>>>> >>>>>> You don't need Monitor:: here >>>>> Removed. >>>>> >>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>>> PlatformMonitor now. >>>>>> >>>>>> This needs to be resolved before committing. Some of the existing >>>>>> commentary on what raw monitors are needs to be retained. Not >>>>>> clear if we need to set the _owner field or can just skip it. >>>>> Is it okay if I keep the following comments? >>>>> >>>>> // Yet another degenerate version of Monitor::lock() or >>>>> lock_without_safepoint_check() >>>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>>> via JVM_RawMonitorEnter. >>>>> // >>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>> properly with the native >>>>> // Mutex-Monitor constructs.? We happen to implement >>>>> JVM_RawMonitors in terms of >>>>> // native Mutex-Monitors simply as a matter of convenience. >>>> >>>> Yep that's perfect. And as a future RFE we can replace them with >>>> direct use of PlatformMonitor (or PlatformMutex). >>>> >>>>> >>>>> I could keep setting the owner as _owner = >>>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>>> hurt. >>>> >>>> It's useful for checking usage errors, but we won't have that if we >>>> replace with PlatformMonitor, so may as well drop it now IMO. >>> Ok, I added asserts that _owner should be NULL after acquiring it >>> and before releasing it though. >>> >>>>>> Monitor::~Monitor() { >>>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>>> p2i(_owner)); >>>>>> } >>>>>> >>>>>> Will this automatically result in the PlatformMonitor destructor >>>>>> being called? >>>>> Yes, should I add a comment to make it clear that >>>>> ~PlatformMonitor() will be executed? >>>> >>>> No need - assume other people have a better understanding of C++ >>>> than I do :) >>> >>> Below is version v04, which also contains a correction pointed out >>> off-list by Robbin to do a local poll first in >>> SafepointMechanism::callback_if_safepoint() if we are using local >>> polls. Since the thread local poll is armed after changing _state to >>> _synchronizing, if we only do a global poll in the TLBIVM >>> constructor we could detect there is a safepoint in progress and >>> callback but when coming back in the destructor >>> SafepointMechanism::should_block() could miss detecting the >>> safepoint in progress since that method checks first for local polls. >>> >>> >>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>> >>> >>> Thanks, >>> Patricio >>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> >>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>> >>>>> Thanks, >>>>> Patricio >>>>>> --- >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>> >>> > From kim.barrett at oracle.com Fri Feb 1 21:48:36 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Feb 2019 16:48:36 -0500 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> Message-ID: <65CB5B51-4BBA-4CD3-8DA8-27BAB8211648@oracle.com> > On Feb 1, 2019, at 2:55 AM, David Holmes wrote: >> In retrospect, ?MSVC? seems like a better choice than MSVCPP. > > Agreed. Especially since it seems what I actually used in the webrev was MSCPP :) Let?s go with ?MSVC? then. From igor.ignatyev at oracle.com Fri Feb 1 22:04:35 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 1 Feb 2019 14:04:35 -0800 Subject: RFR: 8218202: gc/stress/TestStressG1Humongous.java to ProblemList-graal.txt In-Reply-To: References: Message-ID: <315C2BFF-85BA-4801-9724-BECB92058FD3@oracle.com> Hi Kim, it looks like 218176 is a duplicate of 8196611[1], so to a save problem-list cleanup fix, you might want to use 8196611 in the problem list. I haven't analyzed 8218176 deep enough though, so I can be wrong. -- Igor [1] https://bugs.openjdk.java.net/browse/JDK-8196611 > On Feb 1, 2019, at 12:53 PM, Kim Barrett wrote: > > Please review this addition to ProblemList-graal.txt. See comment in main bug for details: > https://bugs.openjdk.java.net/browse/JDK-8218176?focusedCommentId=14242017&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14242017 > > CR: > https://bugs.openjdk.java.net/browse/JDK-8218202 > > Main Bug: > https://bugs.openjdk.java.net/browse/JDK-8218176 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8218202/open.00/ > > Testing: > Locally verified exclusion of test when using ProblemList-graal.txt > From kim.barrett at oracle.com Fri Feb 1 22:49:09 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Feb 2019 17:49:09 -0500 Subject: RFR: 8218202: gc/stress/TestStressG1Humongous.java to ProblemList-graal.txt In-Reply-To: <315C2BFF-85BA-4801-9724-BECB92058FD3@oracle.com> References: <315C2BFF-85BA-4801-9724-BECB92058FD3@oracle.com> Message-ID: <30988730-FA90-4D4D-AC66-93D6C0C0C346@oracle.com> > On Feb 1, 2019, at 5:04 PM, Igor Ignatyev wrote: > > Hi Kim, > > it looks like 218176 is a duplicate of 8196611[1], so to a save problem-list cleanup fix, you might want to use 8196611 in the problem list. I haven't analyzed 8218176 deep enough though, so I can be wrong. I don?t think it?s a duplicate. 8196611 is a test bug. The test isn?t prepared for significant additional allocation by code other than the test, e.g. by some background task like Graal compilation. 218176 seems to be a Graal problem. The test is fine, it intentionally triggers OOMEs and handles them appropriately. However, a background task, like Graal compilation, might also encounter OOME because of what the test is doing. Graal compilation seems to be insufficiently resilient to OOME and the process terminates as a result. From igor.ignatyev at oracle.com Fri Feb 1 22:51:01 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 1 Feb 2019 14:51:01 -0800 Subject: RFR: 8218202: gc/stress/TestStressG1Humongous.java to ProblemList-graal.txt In-Reply-To: <30988730-FA90-4D4D-AC66-93D6C0C0C346@oracle.com> References: <315C2BFF-85BA-4801-9724-BECB92058FD3@oracle.com> <30988730-FA90-4D4D-AC66-93D6C0C0C346@oracle.com> Message-ID: <47E150CB-5392-4F3A-8A4F-DE4B1693C41A@oracle.com> I see, thanks for the explanation. Reviewed. -- Igor > On Feb 1, 2019, at 2:49 PM, Kim Barrett wrote: > >> On Feb 1, 2019, at 5:04 PM, Igor Ignatyev wrote: >> >> Hi Kim, >> >> it looks like 218176 is a duplicate of 8196611[1], so to a save problem-list cleanup fix, you might want to use 8196611 in the problem list. I haven't analyzed 8218176 deep enough though, so I can be wrong. > > I don?t think it?s a duplicate. > > 8196611 is a test bug. The test isn?t prepared for significant additional allocation > by code other than the test, e.g. by some background task like Graal compilation. > > 218176 seems to be a Graal problem. The test is fine, it intentionally triggers OOMEs > and handles them appropriately. However, a background task, like Graal compilation, > might also encounter OOME because of what the test is doing. Graal compilation > seems to be insufficiently resilient to OOME and the process terminates as a result. > From daniel.daugherty at oracle.com Fri Feb 1 22:55:36 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Feb 2019 17:55:36 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <9ebe68f4-5b36-f998-d7b1-b419f7f7983f@oracle.com> <922da8bc-6ba5-79df-5045-e72568cc7e1f@oracle.com> <6affcf41-321c-9a94-028f-43d1102ded90@oracle.com> Message-ID: <868f469d-737f-54da-6e8a-1d0e273ecc5a@oracle.com> On 2/1/19 3:20 PM, Patricio Chilano wrote: > Hi Dan, > > > On 2/1/19 2:22 PM, Daniel D. Daugherty wrote: >> On 2/1/19 1:01 PM, Patricio Chilano wrote: >>> Hi Dan, >>> >>> On 2/1/19 11:10 AM, Daniel D. Daugherty wrote: >>>> > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>> >>>> src/hotspot/share/logging/logTag.hpp >>>> ??? No comments. >>>> >>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>> ??? L295: // - When transitioning in (constructor), it checks for >>>> safepoints without having to block, i.e calls >>>> ??????? Perhaps: >>>> ????????? // - When transitioning in (constructor), it checks for >>>> safepoints without blocking, i.e., calls >>>> >>>> ??? L298: //?? the monitor that is in the process of being acquired >>>> (only setting the owner is missing). >>>> ??????? Perhaps: >>>> ????????? //?? the monitor that is only partially acquired. >>> Done. >>>> src/hotspot/share/runtime/mutex.cpp >>>> ??? L59: log_trace(vmmonitor)("JavaThread " INTPTR_FORMAT " on %d >>>> attempt trying to acquire native monitor %s", p2i(self), retry_cnt, >>>> _name); >>>> ??????? nit - s/native monitor/vmmonitor/? - for consistency. >>> Done. >>> >>>> src/hotspot/share/runtime/mutex.hpp >>>> ??? No comments. >>>> >>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>> ??? L83: ? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >>>> ??? L84: ??? if (global_poll()) { >>>> ??????? I'm having trouble with this construct: >>>> >>>> ??????? - if uses_thread_local_poll() is false, then we check >>>> global_poll() >>>> ????????? and call SafepointSynchronize::block() if global_poll() >>>> == true. >>>> ????????? That makes sense since we're not using local polling. >>>> >>>> ??????? - if uses_thread_local_poll() is true, then we check >>>> ????????? if local_poll_armed(thread) == true and then we check >>>> global_poll() >>>> ????????? and call SafepointSynchronize::block() if global_poll() >>>> == true. >>>> >>>> ????????? Huh? >>>> >>>> ??????? So we only call SafepointSynchronize::block() if >>>> global_poll() == true >>>> ??????? no matter what. It seems like the checks for local polling >>>> don't really >>>> ??????? do anything here. >>>> >>>> ??????? What am I missing? >>> A couple of observations before going straight to the question. The >>> check for local poll in SafepointMechanism::should_block() (TBIVMWDP >>> destructor) is needed because we need to check for both, pending >>> safepoints or pending handshakes. In other words once we transition >>> back from the _thread_blocked state, there could be either a >>> safepoint or a handshake for that thread being processed. If >>> SafepointMechanism::should_block() returns true, then >>> SafepointMechanism::callback_if_safepoint() only checks for pending >>> safepoints. After that I do the check "if >>> (_thread->has_handshake())" for pending handshakes. I couldn't use >>> SafepointMechanism::block_if_requested() which checks for both like >>> in the normal TBIVM, because of two reasons: >>> - On one hand, I need to pass the "false" parameter to >>> SafepointSynchronize::block() to avoid blocking when transitioning >>> in, and avoid failing the test that we have a ThreadSafepointState >>> of _call_back when transitioing back. Without introducing >>> SafepointMechanism::callback_if_safepoint() I would have to modify a >>> couple of methods in SafepointMechanism to receive that extra >>> argument. I think this was cleaner. >>> -But even if I did add the extra argument to those functions and use >>> SafepointMechanism::block_if_requested(), I would need also to avoid >>> checking for handshakes in the TBIVMWDP constructor. The processing >>> of handshakes uses its own ThreadInVMForHandshake jacket which >>> internally calls SafepointMechanism::block_if_requested(). Since in >>> the constructor we do not block for safepoints, executing again >>> SafepointMechanism::block_if_requested() in a handshake would >>> execute SS::block twice. >>> So to solve that I just introduced >>> SafepointMechanism::callback_if_safepoint() which only checks for >>> safepoints and uses the extra argument in SS::block. >>> >>> Now, as to why I can't just check for global polls in >>> SafepointMechanism::callback_if_safepoint() (since I only want to >>> check/stop for safepoints), this has to do with the race found by >>> Robbin. Since the thread local poll is armed after changing _state >>> to _synchronizing, if I only do a global poll, >>> SafepointMechanism::callback_if_safepoint(in the TBIVMWDP >>> constructor) could detect there is a safepoint in progress and >>> callback but when coming back in the destructor >>> SafepointMechanism::should_block() could miss detecting the >>> safepoint in progress since that method checks for local polls first >>> (it cares about both safepoints and handshakes). So I need to match >>> the order of checks done by SafepointMechanism::should_block(). >>> >>> Any of this makes sense? >> >> Not really, but now I have a better way to ask about this. >> >> Here's should_block(): >> >> ? 50 bool SafepointMechanism::should_block(Thread* thread) { >> ? 51?? if (uses_thread_local_poll()) { >> ? 52???? return local_poll(thread); >> ? 53?? } else { >> ? 54???? return global_poll(); >> ? 55?? } >> ? 56 } >> >> If uses_thread_local_poll() == true, then we return the result >> of local_poll(thread) and skip calling global_poll(). >> >> Here's callback_if_safepoint(): >> >> ? 82 void SafepointMechanism::callback_if_safepoint(JavaThread* >> thread) { >> ? 83?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >> ? 84???? if (global_poll()) { >> ? 85?????? SafepointSynchronize::block(thread, false); >> ? 86???? } >> ? 87?? } >> ? 88 } >> >> If uses_thread_local_poll() == false and global_poll() == true, >> then we call block(). >> If uses_thread_local_poll() == true and local_poll_armed() == true >> and global_poll() == true, then we call block(). >> >> Since we always check global_poll() == true before calling block(), >> then preceding expressions are moot. They do not affect whether we >> call block() at all. > It's true that those checks for local poll are not actually needed if > you get to execute SafepointMechanism::callback_if_safepoint() in the > TBIVMWDP destructor. At that point I could just check for > global_poll(). But because I'm previously executing > SafepointMechanism::should_block() to first decide whether or not I > need to block for a safepoint or handshake, that forces me to add the > local polls checks when executing > SafepointMechanism::callback_if_safepoint() in the TBIVMWDP > constructor. Otherwise let's say I removed them: > > 1- VMThread in SafepointSynchronize::begin() executes? "_state = > _synchronizing;" and gets context switched by the OS. > 2 - JavaThread executes SafepointMechanism::callback_if_safepoint() in > TBIVMWDP constructor, checks global_poll() which returns true, and > callsback for safepoint without blocking. > 3- JavaThread goes into the _thread_blocked state and blocks, let's > say in "_lock.lock();" in Monitor::lock(). > 4- JavaThread acquires the lock and transitions back. In the TBIVMWDP > destructor calls SafepointMechanism::should_block(). If we are using > local polls, should_block() will check local_poll_armed(). That will > return false since the VMThread didn't armed the local poll yet. > 5- JavaThread continues to execute in VM. > 6- VMThread is scheduled again, and arms local polls. At this point > you can have serveral problems, either the JavaThread could try to > callback again(i.e twice) at some point later, or not and the > safepoint will start while that JavaThread is executing in the VM. Making sure I understand why you think you need L83: At step #2, if you put this check back: ? L83?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { then the change in behavior is that you don't call ? L84???? if (global_poll()) { ? L85?????? SafepointSynchronize::block(thread, false); because the VMThread hasn't armed local polls yet right? So L83 keeps the target thread from calling block() too early? And then in step 4, in should_block(), uses_thread_local_poll() will return false because the local poll still isn't armed yet and the target will call global_poll() which will return true because of _state == _synchronizing. The caller of should_block() in the TBIVMWDP destructor realizes that we need to block for a safepoint so it will release the lock that the VMThread _might_ want and block() for the safepoint. Okay, I think I have understood what you're arguing. Here's a minor correction that I see in the above: > 4- JavaThread acquires the lock and transitions back. In the TBIVMWDP > destructor calls SafepointMechanism::should_block(). If we are using > local polls, should_block() will check local_poll_armed(). That will > return false since the VMThread didn't armed the local poll yet. In Step 4, you're missing that should_block() will call global_poll() and global_poll() is: ? 37 bool SafepointMechanism::global_poll() { ? 38?? return SafepointSynchronize::do_call_back(); ? 39 } which calls: ?141?? inline static bool do_call_back() { ?142???? return (_state != _not_synchronized); ?143?? } and the _state == _synchronizing still so should_block() will return true. The TBIVMWDP destructor realizes that we need to block for a safepoint so it will release the lock that the VMThread _might_ want and block() for the safepoint. So we do get the second block() call for the same safepoint from the save thread. So for this function, consider adding this comment: ? L82: void SafepointMechanism::callback_if_safepoint(JavaThread* thread) { ? L83: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { ?????????? // If using thread local polls, then we should not check the ?????????? // global_poll() and callback via block() yet if the VMThread ?????????? // has not armed the local poll yet. Otherwise, we'll callback ?????????? // twice for the same thread. ? L84: ??? if (global_poll()) { ? L85: ????? SafepointSynchronize::block(thread, false); ? L86: ??? } ? L87: ? } ? L88: } Maybe I'm the only one who isn't grok'ing this code. Dunno. The above comment clears it up for me, but others may say "That's obvious!" Dan > > I could add another argument in > SafepointMechanism::callback_if_safepoint() to skip checking local > polls in the destructor if that's what you mean. > > > Patricio > >> Dan >> >> >>> >>> >>> Thanks, >>> Patricio >>> >>>> Dan >>>> >>>> On 2/1/19 12:05 AM, Patricio Chilano wrote: >>>>> Hi David, >>>>> >>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>> Hi Patricio, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>> this, pulling together a number of ideas from different people >>>>>>>> to make it all work! >>>>>>> Thanks! Credit to you for the PlatformMonitor implementation : ) >>>>>> >>>>>> :) Nothing innovative there. >>>>>> >>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>> >>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>> Full: >>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>> Inc: >>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>> >>>>>>>> >>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>> >>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which >>>>>>>> is masking the actual difference between the two wrappers to >>>>>>>> me. It seems to me that an extra arg to transition_and_fence >>>>>>>> should allow you to handle the new behaviour without having to >>>>>>>> duplicate so much of this code. In any case the semantics of >>>>>>>> ThreadLockBlockInVM needs to be described. >>>>>>> I could do it with one extra argument, but I would need to add >>>>>>> two extra branches in transition_and_fence(), one to decide if >>>>>>> I'm in the Monitor case to avoid calling >>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>> one to actually decide if I'm transitioning in or out, since the >>>>>>> actions to perform are different. I think it is easier to read >>>>>>> without adding new conditionals, and also we will save those >>>>>>> extra branches, but if you think it's better this way I can >>>>>>> change it. >>>>>> >>>>>> I would like something that tells me more clearly how this new >>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>> code between them and using different args would be one way. >>>>>> Documenting the difference in comments would be another. Your >>>>>> choice. >>>>> Ok, I added a description on top of TLBIVM. >>>>> >>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>> >>>>>> That's not quite conveying the semantics. The problem is that the >>>>>> semantics we are changing compared to TBIVM are not evident in >>>>>> the TBIVM name. If TBIVM was actually >>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>>> perhaps that lengthy, but clear name would be okay anyway? >>>>> Not convinced on that name since we are blocking at safepoints in >>>>> the destructor. Based on the comments I added how about >>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>> conditions for deadlocks). >>>>> >>>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>>> don't really convey to me what happens - what is being >>>>>>>> "preempted" here? I would suggest a more direct >>>>>>>> Monitor::release_for_safepoint >>>>>>> Changed. >>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>>>> need bother at all with the one logging statement that is present. >>>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>>> follow you with the name, isn't that how we name this monitors? >>>>>>> I tried to differentiate them from Java monitors. What about >>>>>>> just "monitor"? >>>>>> >>>>>> How about vmmonitor ? >>>>> Ok, changed. >>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>> >>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>> safepoint checks. >>>>>>>> >>>>>>>> The comment there should only say "not require". >>>>>>> Done. >>>>>>> >>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>> ? _lock.unlock(); >>>>>>>> } >>>>>>>> >>>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>>> suitable assertions we should have here? safepoint-in-progress >>>>>>>> or handshake-in-progress? _owner == Thread::current? >>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>> safepoint-in-progress does not really work because _state could >>>>>>> change to _not_synchronized right after you checked for it in >>>>>>> TLBIVM. >>>>>> >>>>>> Okay. >>>>>> >>>>>>>> Nit: >>>>>>>> >>>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>>> INTPTR_FORMAT >>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>> p2i(Thread::current())); >>>>>>>> >>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>> The second line should indent to the first comma, but that will >>>>>>>> make the second line extend way past 80 columns. >>>>>>>> >>>>>>>> Also you could factor that assertion for >>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>> avoid the repetition. >>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>> >>>>>> I though it should indent to the comma because it is a >>>>>> continuation of the same argument being passed to the assert >>>>>> "function". But I'm okay with Dan's suggestion. >>>>>> >>>>>> Factoring it into its own little function or macro would still be >>>>>> good to avoid the repetition. >>>>> Ok, added new function assert_owned_by_self(). I could change it >>>>> to assert_owner(Thread*) and use it for the NULL case too unifying >>>>> the printed messages to something like "invalid owner: owner=" >>>>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>>>> >>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>> Object.wait() */); >>>>>>>> >>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>> comments. >>>>>>> Done. >>>>>>> >>>>>>>> ??? } else { >>>>>>>> ????? Monitor::lock(self); >>>>>>>> ??? } >>>>>>>> >>>>>>>> You don't need Monitor:: here >>>>>>> Removed. >>>>>>> >>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be >>>>>>>> a PlatformMonitor now. >>>>>>>> >>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>> retained. Not clear if we need to set the _owner field or can >>>>>>>> just skip it. >>>>>>> Is it okay if I keep the following comments? >>>>>>> >>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>> lock_without_safepoint_check() >>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>> threads via JVM_RawMonitorEnter. >>>>>>> // >>>>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>>>> properly with the native >>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>> JVM_RawMonitors in terms of >>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>> >>>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>>> >>>>>>> >>>>>>> I could keep setting the owner as _owner = >>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>> wouldn't hurt. >>>>>> >>>>>> It's useful for checking usage errors, but we won't have that if >>>>>> we replace with PlatformMonitor, so may as well drop it now IMO. >>>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>>> and before releasing it though. >>>>> >>>>>>>> Monitor::~Monitor() { >>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>> } >>>>>>>> >>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>> destructor being called? >>>>>>> Yes, should I add a comment to make it clear that >>>>>>> ~PlatformMonitor() will be executed? >>>>>> >>>>>> No need - assume other people have a better understanding of C++ >>>>>> than I do :) >>>>> >>>>> Below is version v04, which also contains a correction pointed out >>>>> off-list by Robbin to do a local poll first in >>>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>>> polls. Since the thread local poll is armed after changing _state >>>>> to _synchronizing, if we only do a global poll in the TLBIVM >>>>> constructor we could detect there is a safepoint in progress and >>>>> callback but when coming back in the destructor >>>>> SafepointMechanism::should_block() could miss detecting the >>>>> safepoint in progress since that method checks first for local polls. >>>>> >>>>> >>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>> >>>>> >>>>> Thanks, >>>>> Patricio >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>>>> >>>>>>> Thanks, >>>>>>> Patricio >>>>>>>> --- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From kim.barrett at oracle.com Fri Feb 1 23:17:45 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 1 Feb 2019 18:17:45 -0500 Subject: RFR: 8218202: gc/stress/TestStressG1Humongous.java to ProblemList-graal.txt In-Reply-To: <47E150CB-5392-4F3A-8A4F-DE4B1693C41A@oracle.com> References: <315C2BFF-85BA-4801-9724-BECB92058FD3@oracle.com> <30988730-FA90-4D4D-AC66-93D6C0C0C346@oracle.com> <47E150CB-5392-4F3A-8A4F-DE4B1693C41A@oracle.com> Message-ID: > On Feb 1, 2019, at 5:51 PM, Igor Ignatyev wrote: > > I see, thanks for the explanation. Reviewed. Thanks. From patricio.chilano.mateo at oracle.com Fri Feb 1 23:51:35 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 1 Feb 2019 18:51:35 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <868f469d-737f-54da-6e8a-1d0e273ecc5a@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <9ebe68f4-5b36-f998-d7b1-b419f7f7983f@oracle.com> <922da8bc-6ba5-79df-5045-e72568cc7e1f@oracle.com> <6affcf41-321c-9a94-028f-43d1102ded90@oracle.com> <868f469d-737f-54da-6e8a-1d0e273ecc5a@oracle.com> Message-ID: <7b335ede-ba65-25dd-72d2-1fd82c285bc2@oracle.com> On 2/1/19 5:55 PM, Daniel D. Daugherty wrote: > > > On 2/1/19 3:20 PM, Patricio Chilano wrote: >> Hi Dan, >> >> >> On 2/1/19 2:22 PM, Daniel D. Daugherty wrote: >>> On 2/1/19 1:01 PM, Patricio Chilano wrote: >>>> Hi Dan, >>>> >>>> On 2/1/19 11:10 AM, Daniel D. Daugherty wrote: >>>>> > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>> >>>>> src/hotspot/share/logging/logTag.hpp >>>>> ??? No comments. >>>>> >>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>> ??? L295: // - When transitioning in (constructor), it checks for >>>>> safepoints without having to block, i.e calls >>>>> ??????? Perhaps: >>>>> ????????? // - When transitioning in (constructor), it checks for >>>>> safepoints without blocking, i.e., calls >>>>> >>>>> ??? L298: //?? the monitor that is in the process of being >>>>> acquired (only setting the owner is missing). >>>>> ??????? Perhaps: >>>>> ????????? //?? the monitor that is only partially acquired. >>>> Done. >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> ??? L59: log_trace(vmmonitor)("JavaThread " INTPTR_FORMAT " on %d >>>>> attempt trying to acquire native monitor %s", p2i(self), >>>>> retry_cnt, _name); >>>>> ??????? nit - s/native monitor/vmmonitor/? - for consistency. >>>> Done. >>>> >>>>> src/hotspot/share/runtime/mutex.hpp >>>>> ??? No comments. >>>>> >>>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>>> ??? L83: ? if(!uses_thread_local_poll() || >>>>> local_poll_armed(thread)) { >>>>> ??? L84: ??? if (global_poll()) { >>>>> ??????? I'm having trouble with this construct: >>>>> >>>>> ??????? - if uses_thread_local_poll() is false, then we check >>>>> global_poll() >>>>> ????????? and call SafepointSynchronize::block() if global_poll() >>>>> == true. >>>>> ????????? That makes sense since we're not using local polling. >>>>> >>>>> ??????? - if uses_thread_local_poll() is true, then we check >>>>> ????????? if local_poll_armed(thread) == true and then we check >>>>> global_poll() >>>>> ????????? and call SafepointSynchronize::block() if global_poll() >>>>> == true. >>>>> >>>>> ????????? Huh? >>>>> >>>>> ??????? So we only call SafepointSynchronize::block() if >>>>> global_poll() == true >>>>> ??????? no matter what. It seems like the checks for local polling >>>>> don't really >>>>> ??????? do anything here. >>>>> >>>>> ??????? What am I missing? >>>> A couple of observations before going straight to the question. The >>>> check for local poll in SafepointMechanism::should_block() >>>> (TBIVMWDP destructor) is needed because we need to check for both, >>>> pending safepoints or pending handshakes. In other words once we >>>> transition back from the _thread_blocked state, there could be >>>> either a safepoint or a handshake for that thread being processed. >>>> If SafepointMechanism::should_block() returns true, then >>>> SafepointMechanism::callback_if_safepoint() only checks for pending >>>> safepoints. After that I do the check "if >>>> (_thread->has_handshake())" for pending handshakes. I couldn't use >>>> SafepointMechanism::block_if_requested() which checks for both like >>>> in the normal TBIVM, because of two reasons: >>>> - On one hand, I need to pass the "false" parameter to >>>> SafepointSynchronize::block() to avoid blocking when transitioning >>>> in, and avoid failing the test that we have a ThreadSafepointState >>>> of _call_back when transitioing back. Without introducing >>>> SafepointMechanism::callback_if_safepoint() I would have to modify >>>> a couple of methods in SafepointMechanism to receive that extra >>>> argument. I think this was cleaner. >>>> -But even if I did add the extra argument to those functions and >>>> use SafepointMechanism::block_if_requested(), I would need also to >>>> avoid checking for handshakes in the TBIVMWDP constructor. The >>>> processing of handshakes uses its own ThreadInVMForHandshake jacket >>>> which internally calls SafepointMechanism::block_if_requested(). >>>> Since in the constructor we do not block for safepoints, executing >>>> again SafepointMechanism::block_if_requested() in a handshake would >>>> execute SS::block twice. >>>> So to solve that I just introduced >>>> SafepointMechanism::callback_if_safepoint() which only checks for >>>> safepoints and uses the extra argument in SS::block. >>>> >>>> Now, as to why I can't just check for global polls in >>>> SafepointMechanism::callback_if_safepoint() (since I only want to >>>> check/stop for safepoints), this has to do with the race found by >>>> Robbin. Since the thread local poll is armed after changing _state >>>> to _synchronizing, if I only do a global poll, >>>> SafepointMechanism::callback_if_safepoint(in the TBIVMWDP >>>> constructor) could detect there is a safepoint in progress and >>>> callback but when coming back in the destructor >>>> SafepointMechanism::should_block() could miss detecting the >>>> safepoint in progress since that method checks for local polls >>>> first (it cares about both safepoints and handshakes). So I need to >>>> match the order of checks done by SafepointMechanism::should_block(). >>>> >>>> Any of this makes sense? >>> >>> Not really, but now I have a better way to ask about this. >>> >>> Here's should_block(): >>> >>> ? 50 bool SafepointMechanism::should_block(Thread* thread) { >>> ? 51?? if (uses_thread_local_poll()) { >>> ? 52???? return local_poll(thread); >>> ? 53?? } else { >>> ? 54???? return global_poll(); >>> ? 55?? } >>> ? 56 } >>> >>> If uses_thread_local_poll() == true, then we return the result >>> of local_poll(thread) and skip calling global_poll(). >>> >>> Here's callback_if_safepoint(): >>> >>> ? 82 void SafepointMechanism::callback_if_safepoint(JavaThread* >>> thread) { >>> ? 83?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >>> ? 84???? if (global_poll()) { >>> ? 85?????? SafepointSynchronize::block(thread, false); >>> ? 86???? } >>> ? 87?? } >>> ? 88 } >>> >>> If uses_thread_local_poll() == false and global_poll() == true, >>> then we call block(). >>> If uses_thread_local_poll() == true and local_poll_armed() == true >>> and global_poll() == true, then we call block(). >>> >>> Since we always check global_poll() == true before calling block(), >>> then preceding expressions are moot. They do not affect whether we >>> call block() at all. >> It's true that those checks for local poll are not actually needed if >> you get to execute SafepointMechanism::callback_if_safepoint() in the >> TBIVMWDP destructor. At that point I could just check for >> global_poll(). But because I'm previously executing >> SafepointMechanism::should_block() to first decide whether or not I >> need to block for a safepoint or handshake, that forces me to add the >> local polls checks when executing >> SafepointMechanism::callback_if_safepoint() in the TBIVMWDP >> constructor. Otherwise let's say I removed them: >> >> 1- VMThread in SafepointSynchronize::begin() executes? "_state = >> _synchronizing;" and gets context switched by the OS. >> 2 - JavaThread executes SafepointMechanism::callback_if_safepoint() >> in TBIVMWDP constructor, checks global_poll() which returns true, and >> callsback for safepoint without blocking. >> 3- JavaThread goes into the _thread_blocked state and blocks, let's >> say in "_lock.lock();" in Monitor::lock(). >> 4- JavaThread acquires the lock and transitions back. In the TBIVMWDP >> destructor calls SafepointMechanism::should_block(). If we are using >> local polls, should_block() will check local_poll_armed(). That will >> return false since the VMThread didn't armed the local poll yet. >> 5- JavaThread continues to execute in VM. >> 6- VMThread is scheduled again, and arms local polls. At this point >> you can have serveral problems, either the JavaThread could try to >> callback again(i.e twice) at some point later, or not and the >> safepoint will start while that JavaThread is executing in the VM. > > Making sure I understand why you think you need L83: > > At step #2, if you put this check back: > > ? L83?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { > > then the change in behavior is that you don't call > > ? L84???? if (global_poll()) { > ? L85?????? SafepointSynchronize::block(thread, false); > > because the VMThread hasn't armed local polls yet right? So L83 > keeps the target thread from calling block() too early? Right. The idea is that if SafepointMechanism::callback_if_safepoint() detects there is a pending safepoint then SafepointMechanism::should_block() cannot miss detecting that same safepoint if it is still going on. > And then in > step 4, in should_block(), uses_thread_local_poll() will return > false I think by "uses_thread_local_poll()" you probably meant "local_poll_armed()". If we are using local polls uses_thread_local_poll() will always return true. > because the local poll still isn't armed yet and the target > will call global_poll() which will return true because of _state > == _synchronizing. The caller of should_block() in the TBIVMWDP > destructor realizes that we need to block for a safepoint so it > will release the lock that the VMThread _might_ want and block() > for the safepoint. If the local poll was still not set, the target thread will just exit the TBIVMWDP jacket and will continue executing in the VM. At some point later it will detect there is a safepoint and it will call SS::block(). If the local poll was set, then yes, it will release the monitor and block() for the safepoint. > Okay, I think I have understood what you're arguing. > > > Here's a minor correction that I see in the above: > >> 4- JavaThread acquires the lock and transitions back. In the TBIVMWDP >> destructor calls SafepointMechanism::should_block(). If we are using >> local polls, should_block() will check local_poll_armed(). That will >> return false since the VMThread didn't armed the local poll yet. > > In Step 4, you're missing that should_block() will call > global_poll() and global_poll() is: If we are using thread local polls should_block() will not call global_poll(). It will just return whatever local_poll() returns, and that is if the local poll is armed or not. > ? 37 bool SafepointMechanism::global_poll() { > ? 38?? return SafepointSynchronize::do_call_back(); > ? 39 } > > which calls: > > ?141?? inline static bool do_call_back() { > ?142???? return (_state != _not_synchronized); > ?143?? } > > and the _state == _synchronizing still so should_block() > will return true. The TBIVMWDP destructor realizes that > we need to block for a safepoint so it will release the > lock that the VMThread _might_ want and block() for the > safepoint. So we do get the second block() call for the > same safepoint from the save thread. > > So for this function, consider adding this comment: > > ? L82: void SafepointMechanism::callback_if_safepoint(JavaThread* > thread) { > ? L83: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { > ?????????? // If using thread local polls, then we should not check the > ?????????? // global_poll() and callback via block() yet if the VMThread > ?????????? // has not armed the local poll yet. Otherwise, we'll callback > ?????????? // twice for the same thread. > ? L84: ??? if (global_poll()) { > ? L85: ????? SafepointSynchronize::block(thread, false); > ? L86: ??? } > ? L87: ? } > ? L88: } I can add that comment. Although I'm not convinced about the last sentence since it is only a possibility to call back twice. It could also be that nothing happens because when that JavaThread transition back, the local poll could be already set. Or even if it is not set and you don't detect the safepoint, the VM thread might finish executing the safepoint before the JavaThread calls back the second time. Patricio > Maybe I'm the only one who isn't grok'ing this code. Dunno. The above > comment clears it up for me, but others may say "That's obvious!" > > Dan > > >> >> I could add another argument in >> SafepointMechanism::callback_if_safepoint() to skip checking local >> polls in the destructor if that's what you mean. >> >> >> Patricio >> >>> Dan >>> >>> >>>> >>>> >>>> Thanks, >>>> Patricio >>>> >>>>> Dan >>>>> >>>>> On 2/1/19 12:05 AM, Patricio Chilano wrote: >>>>>> Hi David, >>>>>> >>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>> Hi Patricio, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>> this, pulling together a number of ideas from different people >>>>>>>>> to make it all work! >>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation : ) >>>>>>> >>>>>>> :) Nothing innovative there. >>>>>>> >>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>> >>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>> Full: >>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>> Inc: >>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>> >>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which >>>>>>>>> is masking the actual difference between the two wrappers to >>>>>>>>> me. It seems to me that an extra arg to transition_and_fence >>>>>>>>> should allow you to handle the new behaviour without having to >>>>>>>>> duplicate so much of this code. In any case the semantics of >>>>>>>>> ThreadLockBlockInVM needs to be described. >>>>>>>> I could do it with one extra argument, but I would need to add >>>>>>>> two extra branches in transition_and_fence(), one to decide if >>>>>>>> I'm in the Monitor case to avoid calling >>>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>>> one to actually decide if I'm transitioning in or out, since >>>>>>>> the actions to perform are different. I think it is easier to >>>>>>>> read without adding new conditionals, and also we will save >>>>>>>> those extra branches, but if you think it's better this way I >>>>>>>> can change it. >>>>>>> >>>>>>> I would like something that tells me more clearly how this new >>>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>>> code between them and using different args would be one way. >>>>>>> Documenting the difference in comments would be another. Your >>>>>>> choice. >>>>>> Ok, I added a description on top of TLBIVM. >>>>>> >>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>> >>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>> the semantics we are changing compared to TBIVM are not evident >>>>>>> in the TBIVM name. If TBIVM was actually >>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>>>> perhaps that lengthy, but clear name would be okay anyway? >>>>>> Not convinced on that name since we are blocking at safepoints in >>>>>> the destructor. Based on the comments I added how about >>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>> conditions for deadlocks). >>>>>> >>>>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>>>> don't really convey to me what happens - what is being >>>>>>>>> "preempted" here? I would suggest a more direct >>>>>>>>> Monitor::release_for_safepoint >>>>>>>> Changed. >>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>>>> relate to a "native" monitor?? Actually I'm not even sure if >>>>>>>>> we need bother at all with the one logging statement that is >>>>>>>>> present. >>>>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>>>> follow you with the name, isn't that how we name this monitors? >>>>>>>> I tried to differentiate them from Java monitors. What about >>>>>>>> just "monitor"? >>>>>>> >>>>>>> How about vmmonitor ? >>>>>> Ok, changed. >>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>> >>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>> safepoint checks. >>>>>>>>> >>>>>>>>> The comment there should only say "not require". >>>>>>>> Done. >>>>>>>> >>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>> ? _lock.unlock(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>>>> suitable assertions we should have here? safepoint-in-progress >>>>>>>>> or handshake-in-progress? _owner == Thread::current? >>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>> safepoint-in-progress does not really work because _state could >>>>>>>> change to _not_synchronized right after you checked for it in >>>>>>>> TLBIVM. >>>>>>> >>>>>>> Okay. >>>>>>> >>>>>>>>> Nit: >>>>>>>>> >>>>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>>>> INTPTR_FORMAT >>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>> p2i(Thread::current())); >>>>>>>>> >>>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>>> The second line should indent to the first comma, but that >>>>>>>>> will make the second line extend way past 80 columns. >>>>>>>>> >>>>>>>>> Also you could factor that assertion for >>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>> avoid the repetition. >>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>> >>>>>>> I though it should indent to the comma because it is a >>>>>>> continuation of the same argument being passed to the assert >>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>> >>>>>>> Factoring it into its own little function or macro would still >>>>>>> be good to avoid the repetition. >>>>>> Ok, added new function assert_owned_by_self(). I could change it >>>>>> to assert_owner(Thread*) and use it for the NULL case too >>>>>> unifying the printed messages to something like "invalid owner: >>>>>> owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you >>>>>> think? >>>>>> >>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>> Object.wait() */); >>>>>>>>> >>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>> comments. >>>>>>>> Done. >>>>>>>> >>>>>>>>> ??? } else { >>>>>>>>> ????? Monitor::lock(self); >>>>>>>>> ??? } >>>>>>>>> >>>>>>>>> You don't need Monitor:: here >>>>>>>> Removed. >>>>>>>> >>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just >>>>>>>>> be a PlatformMonitor now. >>>>>>>>> >>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>> retained. Not clear if we need to set the _owner field or can >>>>>>>>> just skip it. >>>>>>>> Is it okay if I keep the following comments? >>>>>>>> >>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>> lock_without_safepoint_check() >>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>> // >>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>> interoperate properly with the native >>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>> JVM_RawMonitors in terms of >>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>> >>>>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>>>> >>>>>>>> >>>>>>>> I could keep setting the owner as _owner = >>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>> wouldn't hurt. >>>>>>> >>>>>>> It's useful for checking usage errors, but we won't have that if >>>>>>> we replace with PlatformMonitor, so may as well drop it now IMO. >>>>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>>>> and before releasing it though. >>>>>> >>>>>>>>> Monitor::~Monitor() { >>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>> } >>>>>>>>> >>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>> destructor being called? >>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>> ~PlatformMonitor() will be executed? >>>>>>> >>>>>>> No need - assume other people have a better understanding of C++ >>>>>>> than I do :) >>>>>> >>>>>> Below is version v04, which also contains a correction pointed >>>>>> out off-list by Robbin to do a local poll first in >>>>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>>>> polls. Since the thread local poll is armed after changing _state >>>>>> to _synchronizing, if we only do a global poll in the TLBIVM >>>>>> constructor we could detect there is a safepoint in progress and >>>>>> callback but when coming back in the destructor >>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>> safepoint in progress since that method checks first for local >>>>>> polls. >>>>>> >>>>>> >>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks for looking into this! Waiting on your comments to send >>>>>>>> v04. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Patricio >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Sat Feb 2 00:31:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 2 Feb 2019 10:31:07 +1000 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <0c45ed83-e04c-c640-2cac-ae6581faeebf@oracle.com> Message-ID: <7e744b9d-7469-a300-4247-e87ce317deaa@oracle.com> On 2/02/2019 7:13 am, coleen.phillimore at oracle.com wrote: > > > On 2/1/19 1:31 AM, Patricio Chilano wrote: >> Hi David, >> >> On 2/1/19 12:34 AM, David Holmes wrote: >>> Hi Patricio, >>> >>> Comments on inc v4: >>> >>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>> >>> +?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >>> >>> Need space after if. >>> >>> I trust Robbin's judgement that this is the right way to express >>> this, but if ordering is so critical it should be documented. >> He didn't propose that exact line but local_poll_armed() is a load >> acquire so should be okay. But let's see what Robbin says. >> >>> --- >>> >>> src/hotspot/share/runtime/mutex.hpp/.cpp >>> >>> assert_owned_by_self doesn't need to be a member function, it can >>> just be a file static in the .cpp file. No need to clutter the API. >>> >>> Using a version that takes the owner thread is a good idea for >>> checking the NULL case too. >> Done. >> >>> --- >>> >>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>> >>> I like the comment block - thanks! A couple of minor things: >>> >>> + // are trying to acquire. This will be used to access and release >>> the monitor in case needed to avoid >>> >>> s/in case/if/ >> Done. >> >>> + // the monitor that is in the process of being acquired (only >>> setting the owner is missing). >>> >>> I think the part in parentheses can be dropped - it reads like you >>> should be setting the owner but have chosen not to for some reason. >> Done. >> >>> + // The logic of this class could have been integrated into a more >>> general ThreadBlockInVM. By using a >>> + // separate class though, we avoid executing branches that would >>> otherwise be needed to identify each >>> + // case. >>> >>> Not necessary IMHO but up to you whether to keep or drop. >> Dropped. >> >>> In regards to the name ThreadLockBlockInVM ... I don't have a good >>> suggestion. >>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is rather >>> unwieldy. ;-) But the "Lock" part really doesn't mean anything. So >>> your suggestion of ThreadBlockinVMWithDeadlockPrevention seems a big >>> improvement to me. :) >> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut was the >> right one, too bad it's so long =D. Ok, I''ll leave >> ThreadBlockInVMWithDeadlockPrevention, if anybody comes up with a >> better one I can change it. > > I want ThreadLockBlockInVM - yah it looks the same as ThreadBlockInVM > but I'd rather the name say that it's used for Locks vs some specifics > about what it does.? I hope all the jackets prevent deadlock!? So my > vote is to leave the name as in version 1. but its NOT used for "Locks" it's used for Monitor/Mutex. "locks" is far too generic given all the different type of locking that exists. David > Coleen > >> >> I'll wait for Robbin then to send v05. >> >> Thanks! >> Patricio >> >>> Thanks, >>> David >>> ----- >>> >>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>> Hi David, >>>> >>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>> Hi David, >>>>>> >>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>> Hi Patricio, >>>>>>> >>>>>>> >>>>>>> >>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>> this, pulling together a number of ideas from different people to >>>>>>> make it all work! >>>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>>> >>>>> :) Nothing innovative there. >>>>> >>>>>>> I've only got a few minor comments/suggestions. >>>>>>> >>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>> Inc: >>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>> >>>>>>> >>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>> >>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>>>> masking the actual difference between the two wrappers to me. It >>>>>>> seems to me that an extra arg to transition_and_fence should >>>>>>> allow you to handle the new behaviour without having to duplicate >>>>>>> so much of this code. In any case the semantics of >>>>>>> ThreadLockBlockInVM needs to be described. >>>>>> I could do it with one extra argument, but I would need to add two >>>>>> extra branches in transition_and_fence(), one to decide if I'm in >>>>>> the Monitor case to avoid calling >>>>>> SafepointMechanism::block_if_requested() directly and another one >>>>>> to actually decide if I'm transitioning in or out, since the >>>>>> actions to perform are different. I think it is easier to read >>>>>> without adding new conditionals, and also we will save those extra >>>>>> branches, but if you think it's better this way I can change it. >>>>> >>>>> I would like something that tells me more clearly how this new >>>>> transition helper differs from the existing TBIVM. Sharing the code >>>>> between them and using different args would be one way. Documenting >>>>> the difference in comments would be another. Your choice. >>>> Ok, I added a description on top of TLBIVM. >>>> >>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>>>> refers to. I find the name quite jarring to read. >>>>>> What about changing it to ThreadBlockinMonitor? >>>>> >>>>> That's not quite conveying the semantics. The problem is that the >>>>> semantics we are changing compared to TBIVM are not evident in the >>>>> TBIVM name. If TBIVM was actually >>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>> perhaps that lengthy, but clear name would be okay anyway? >>>> Not convinced on that name since we are blocking at safepoints in >>>> the destructor. Based on the comments I added how about >>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>> conditions for deadlocks). >>>> >>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>> don't really convey to me what happens - what is being >>>>>>> "preempted" here? I would suggest a more direct >>>>>>> Monitor::release_for_safepoint >>>>>> Changed. >>>>>> >>>>>>> --- >>>>>>> >>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>>> need bother at all with the one logging statement that is present. >>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>> follow you with the name, isn't that how we name this monitors? I >>>>>> tried to differentiate them from Java monitors. What about just >>>>>> "monitor"? >>>>> >>>>> How about vmmonitor ? >>>> Ok, changed. >>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> >>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>>>> checks. >>>>>>> >>>>>>> The comment there should only say "not require". >>>>>> Done. >>>>>> >>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>> ? _lock.unlock(); >>>>>>> } >>>>>>> >>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>> suitable assertions we should have here? safepoint-in-progress or >>>>>>> handshake-in-progress? _owner == Thread::current? >>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>> safepoint-in-progress does not really work because _state could >>>>>> change to _not_synchronized right after you checked for it in TLBIVM. >>>>> >>>>> Okay. >>>>> >>>>>>> Nit: >>>>>>> >>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>> INTPTR_FORMAT >>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>> p2i(Thread::current())); >>>>>>> >>>>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>>>> second line should indent to the first comma, but that will make >>>>>>> the second line extend way past 80 columns. >>>>>>> >>>>>>> Also you could factor that assertion for >>>>>>> _owner==Thread::current() into its own function or macro to avoid >>>>>>> the repetition. >>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>> >>>>> I though it should indent to the comma because it is a continuation >>>>> of the same argument being passed to the assert "function". But I'm >>>>> okay with Dan's suggestion. >>>>> >>>>> Factoring it into its own little function or macro would still be >>>>> good to avoid the repetition. >>>> Ok, added new function assert_owned_by_self(). I could change it to >>>> assert_owner(Thread*) and use it for the NULL case too unifying the >>>> printed messages to something like "invalid owner: owner=" >>>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>>> >>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>> Object.wait() */); >>>>>>> >>>>>>> This needs to be returned to its original place as per Dan's >>>>>>> comments. >>>>>> Done. >>>>>> >>>>>>> ??? } else { >>>>>>> ????? Monitor::lock(self); >>>>>>> ??? } >>>>>>> >>>>>>> You don't need Monitor:: here >>>>>> Removed. >>>>>> >>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>>>> PlatformMonitor now. >>>>>>> >>>>>>> This needs to be resolved before committing. Some of the existing >>>>>>> commentary on what raw monitors are needs to be retained. Not >>>>>>> clear if we need to set the _owner field or can just skip it. >>>>>> Is it okay if I keep the following comments? >>>>>> >>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>> lock_without_safepoint_check() >>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>>>> via JVM_RawMonitorEnter. >>>>>> // >>>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>>> properly with the native >>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>> JVM_RawMonitors in terms of >>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>> >>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>> >>>>>> >>>>>> I could keep setting the owner as _owner = >>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>>>> hurt. >>>>> >>>>> It's useful for checking usage errors, but we won't have that if we >>>>> replace with PlatformMonitor, so may as well drop it now IMO. >>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>> and before releasing it though. >>>> >>>>>>> Monitor::~Monitor() { >>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>>>> p2i(_owner)); >>>>>>> } >>>>>>> >>>>>>> Will this automatically result in the PlatformMonitor destructor >>>>>>> being called? >>>>>> Yes, should I add a comment to make it clear that >>>>>> ~PlatformMonitor() will be executed? >>>>> >>>>> No need - assume other people have a better understanding of C++ >>>>> than I do :) >>>> >>>> Below is version v04, which also contains a correction pointed out >>>> off-list by Robbin to do a local poll first in >>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>> polls. Since the thread local poll is armed after changing _state to >>>> _synchronizing, if we only do a global poll in the TLBIVM >>>> constructor we could detect there is a safepoint in progress and >>>> callback but when coming back in the destructor >>>> SafepointMechanism::should_block() could miss detecting the >>>> safepoint in progress since that method checks first for local polls. >>>> >>>> >>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>> >>>> >>>> Thanks, >>>> Patricio >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> >>>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>>> --- >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>> >>>> >> > From david.holmes at oracle.com Sat Feb 2 00:35:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 2 Feb 2019 10:35:00 +1000 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <6affcf41-321c-9a94-028f-43d1102ded90@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <9ebe68f4-5b36-f998-d7b1-b419f7f7983f@oracle.com> <922da8bc-6ba5-79df-5045-e72568cc7e1f@oracle.com> <6affcf41-321c-9a94-028f-43d1102ded90@oracle.com> Message-ID: <0629ad73-fc00-daa6-853a-349a1c114706@oracle.com> On 2/02/2019 5:22 am, Daniel D. Daugherty wrote: > On 2/1/19 1:01 PM, Patricio Chilano wrote: >> Hi Dan, >> >> On 2/1/19 11:10 AM, Daniel D. Daugherty wrote: >>> > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>> >>> src/hotspot/share/logging/logTag.hpp >>> ??? No comments. >>> >>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>> ??? L295: // - When transitioning in (constructor), it checks for >>> safepoints without having to block, i.e calls >>> ??????? Perhaps: >>> ????????? // - When transitioning in (constructor), it checks for >>> safepoints without blocking, i.e., calls >>> >>> ??? L298: //?? the monitor that is in the process of being acquired >>> (only setting the owner is missing). >>> ??????? Perhaps: >>> ????????? //?? the monitor that is only partially acquired. >> Done. >>> src/hotspot/share/runtime/mutex.cpp >>> ??? L59: log_trace(vmmonitor)("JavaThread " INTPTR_FORMAT " on %d >>> attempt trying to acquire native monitor %s", p2i(self), retry_cnt, >>> _name); >>> ??????? nit - s/native monitor/vmmonitor/? - for consistency. >> Done. >> >>> src/hotspot/share/runtime/mutex.hpp >>> ??? No comments. >>> >>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>> ??? L83: ? if(!uses_thread_local_poll() || local_poll_armed(thread)) { >>> ??? L84: ??? if (global_poll()) { >>> ??????? I'm having trouble with this construct: >>> >>> ??????? - if uses_thread_local_poll() is false, then we check >>> global_poll() >>> ????????? and call SafepointSynchronize::block() if global_poll() == >>> true. >>> ????????? That makes sense since we're not using local polling. >>> >>> ??????? - if uses_thread_local_poll() is true, then we check >>> ????????? if local_poll_armed(thread) == true and then we check >>> global_poll() >>> ????????? and call SafepointSynchronize::block() if global_poll() == >>> true. >>> >>> ????????? Huh? >>> >>> ??????? So we only call SafepointSynchronize::block() if >>> global_poll() == true >>> ??????? no matter what. It seems like the checks for local polling >>> don't really >>> ??????? do anything here. >>> >>> ??????? What am I missing? >> A couple of observations before going straight to the question. The >> check for local poll in SafepointMechanism::should_block() (TBIVMWDP >> destructor) is needed because we need to check for both, pending >> safepoints or pending handshakes. In other words once we transition >> back from the _thread_blocked state, there could be either a safepoint >> or a handshake for that thread being processed. If >> SafepointMechanism::should_block() returns true, then >> SafepointMechanism::callback_if_safepoint() only checks for pending >> safepoints. After that I do the check "if (_thread->has_handshake())" >> for pending handshakes. I couldn't use >> SafepointMechanism::block_if_requested() which checks for both like in >> the normal TBIVM, because of two reasons: >> - On one hand, I need to pass the "false" parameter to >> SafepointSynchronize::block() to avoid blocking when transitioning in, >> and avoid failing the test that we have a ThreadSafepointState of >> _call_back when transitioing back. Without introducing >> SafepointMechanism::callback_if_safepoint() I would have to modify a >> couple of methods in SafepointMechanism to receive that extra >> argument. I think this was cleaner. >> -But even if I did add the extra argument to those functions and use >> SafepointMechanism::block_if_requested(), I would need also to avoid >> checking for handshakes in the TBIVMWDP constructor. The processing of >> handshakes uses its own ThreadInVMForHandshake jacket which internally >> calls SafepointMechanism::block_if_requested(). Since in the >> constructor we do not block for safepoints, executing again >> SafepointMechanism::block_if_requested() in a handshake would execute >> SS::block twice. >> So to solve that I just introduced >> SafepointMechanism::callback_if_safepoint() which only checks for >> safepoints and uses the extra argument in SS::block. >> >> Now, as to why I can't just check for global polls in >> SafepointMechanism::callback_if_safepoint() (since I only want to >> check/stop for safepoints), this has to do with the race found by >> Robbin. Since the thread local poll is armed after changing _state to >> _synchronizing, if I only do a global poll, >> SafepointMechanism::callback_if_safepoint(in the TBIVMWDP constructor) >> could detect there is a safepoint in progress and callback but when >> coming back in the destructor SafepointMechanism::should_block() could >> miss detecting the safepoint in progress since that method checks for >> local polls first (it cares about both safepoints and handshakes). So >> I need to match the order of checks done by >> SafepointMechanism::should_block(). >> >> Any of this makes sense? > > Not really, but now I have a better way to ask about this. > > Here's should_block(): > > ? 50 bool SafepointMechanism::should_block(Thread* thread) { > ? 51?? if (uses_thread_local_poll()) { > ? 52???? return local_poll(thread); > ? 53?? } else { > ? 54???? return global_poll(); > ? 55?? } > ? 56 } > > If uses_thread_local_poll() == true, then we return the result > of local_poll(thread) and skip calling global_poll(). > > Here's callback_if_safepoint(): > > ? 82 void SafepointMechanism::callback_if_safepoint(JavaThread* thread) { > ? 83?? if(!uses_thread_local_poll() || local_poll_armed(thread)) { > ? 84???? if (global_poll()) { > ? 85?????? SafepointSynchronize::block(thread, false); > ? 86???? } > ? 87?? } > ? 88 } > > If uses_thread_local_poll() == false and global_poll() == true, > then we call block(). > If uses_thread_local_poll() == true and local_poll_armed() == true > and global_poll() == true, then we call block(). > > Since we always check global_poll() == true before calling block(), > then preceding expressions are moot. They do not affect whether we > call block() at all. Not quite true. If you expand the truth table for this there is one case where global_poll() could be true and we won't call block(), and that is when uses_thread_local_poll() is true and local_poll_armed is false. David ----- > > Dan > > >> >> >> Thanks, >> Patricio >> >>> Dan >>> >>> On 2/1/19 12:05 AM, Patricio Chilano wrote: >>>> Hi David, >>>> >>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>> Hi David, >>>>>> >>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>> Hi Patricio, >>>>>>> >>>>>>> >>>>>>> >>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>> this, pulling together a number of ideas from different people to >>>>>>> make it all work! >>>>>> Thanks! Credit to you for the PlatformMonitor implementation : ) >>>>> >>>>> :) Nothing innovative there. >>>>> >>>>>>> I've only got a few minor comments/suggestions. >>>>>>> >>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>> Inc: >>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>> >>>>>>> >>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>> >>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>>>> masking the actual difference between the two wrappers to me. It >>>>>>> seems to me that an extra arg to transition_and_fence should >>>>>>> allow you to handle the new behaviour without having to duplicate >>>>>>> so much of this code. In any case the semantics of >>>>>>> ThreadLockBlockInVM needs to be described. >>>>>> I could do it with one extra argument, but I would need to add two >>>>>> extra branches in transition_and_fence(), one to decide if I'm in >>>>>> the Monitor case to avoid calling >>>>>> SafepointMechanism::block_if_requested() directly and another one >>>>>> to actually decide if I'm transitioning in or out, since the >>>>>> actions to perform are different. I think it is easier to read >>>>>> without adding new conditionals, and also we will save those extra >>>>>> branches, but if you think it's better this way I can change it. >>>>> >>>>> I would like something that tells me more clearly how this new >>>>> transition helper differs from the existing TBIVM. Sharing the code >>>>> between them and using different args would be one way. Documenting >>>>> the difference in comments would be another. Your choice. >>>> Ok, I added a description on top of TLBIVM. >>>> >>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>>>> refers to. I find the name quite jarring to read. >>>>>> What about changing it to ThreadBlockinMonitor? >>>>> >>>>> That's not quite conveying the semantics. The problem is that the >>>>> semantics we are changing compared to TBIVM are not evident in the >>>>> TBIVM name. If TBIVM was actually >>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>> perhaps that lengthy, but clear name would be okay anyway? >>>> Not convinced on that name since we are blocking at safepoints in >>>> the destructor. Based on the comments I added how about >>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>> conditions for deadlocks). >>>> >>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>> don't really convey to me what happens - what is being >>>>>>> "preempted" here? I would suggest a more direct >>>>>>> Monitor::release_for_safepoint >>>>>> Changed. >>>>>> >>>>>>> --- >>>>>>> >>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>>> need bother at all with the one logging statement that is present. >>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>> follow you with the name, isn't that how we name this monitors? I >>>>>> tried to differentiate them from Java monitors. What about just >>>>>> "monitor"? >>>>> >>>>> How about vmmonitor ? >>>> Ok, changed. >>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> >>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>>>> checks. >>>>>>> >>>>>>> The comment there should only say "not require". >>>>>> Done. >>>>>> >>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>> ? _lock.unlock(); >>>>>>> } >>>>>>> >>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>> suitable assertions we should have here? safepoint-in-progress or >>>>>>> handshake-in-progress? _owner == Thread::current? >>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>> safepoint-in-progress does not really work because _state could >>>>>> change to _not_synchronized right after you checked for it in TLBIVM. >>>>> >>>>> Okay. >>>>> >>>>>>> Nit: >>>>>>> >>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>> INTPTR_FORMAT >>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>> p2i(Thread::current())); >>>>>>> >>>>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>>>> second line should indent to the first comma, but that will make >>>>>>> the second line extend way past 80 columns. >>>>>>> >>>>>>> Also you could factor that assertion for >>>>>>> _owner==Thread::current() into its own function or macro to avoid >>>>>>> the repetition. >>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>> >>>>> I though it should indent to the comma because it is a continuation >>>>> of the same argument being passed to the assert "function". But I'm >>>>> okay with Dan's suggestion. >>>>> >>>>> Factoring it into its own little function or macro would still be >>>>> good to avoid the repetition. >>>> Ok, added new function assert_owned_by_self(). I could change it to >>>> assert_owner(Thread*) and use it for the NULL case too unifying the >>>> printed messages to something like "invalid owner: owner=" >>>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>>> >>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>> Object.wait() */); >>>>>>> >>>>>>> This needs to be returned to its original place as per Dan's >>>>>>> comments. >>>>>> Done. >>>>>> >>>>>>> ??? } else { >>>>>>> ????? Monitor::lock(self); >>>>>>> ??? } >>>>>>> >>>>>>> You don't need Monitor:: here >>>>>> Removed. >>>>>> >>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>>>> PlatformMonitor now. >>>>>>> >>>>>>> This needs to be resolved before committing. Some of the existing >>>>>>> commentary on what raw monitors are needs to be retained. Not >>>>>>> clear if we need to set the _owner field or can just skip it. >>>>>> Is it okay if I keep the following comments? >>>>>> >>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>> lock_without_safepoint_check() >>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>>>> via JVM_RawMonitorEnter. >>>>>> // >>>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>>> properly with the native >>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>> JVM_RawMonitors in terms of >>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>> >>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>> >>>>>> >>>>>> I could keep setting the owner as _owner = >>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>>>> hurt. >>>>> >>>>> It's useful for checking usage errors, but we won't have that if we >>>>> replace with PlatformMonitor, so may as well drop it now IMO. >>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>> and before releasing it though. >>>> >>>>>>> Monitor::~Monitor() { >>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>>>> p2i(_owner)); >>>>>>> } >>>>>>> >>>>>>> Will this automatically result in the PlatformMonitor destructor >>>>>>> being called? >>>>>> Yes, should I add a comment to make it clear that >>>>>> ~PlatformMonitor() will be executed? >>>>> >>>>> No need - assume other people have a better understanding of C++ >>>>> than I do :) >>>> >>>> Below is version v04, which also contains a correction pointed out >>>> off-list by Robbin to do a local poll first in >>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>> polls. Since the thread local poll is armed after changing _state to >>>> _synchronizing, if we only do a global poll in the TLBIVM >>>> constructor we could detect there is a safepoint in progress and >>>> callback but when coming back in the destructor >>>> SafepointMechanism::should_block() could miss detecting the >>>> safepoint in progress since that method checks first for local polls. >>>> >>>> >>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>> >>>> >>>> Thanks, >>>> Patricio >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> >>>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>>> --- >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>> >>>> >>> >> > From david.holmes at oracle.com Sat Feb 2 00:49:38 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 2 Feb 2019 10:49:38 +1000 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: On 2/02/2019 7:48 am, Patricio Chilano wrote: > On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>> In regards to the name ThreadLockBlockInVM ... I don't have a good >>> suggestion. >>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is rather >>> unwieldy. ;-) But the "Lock" part really doesn't mean anything. So >>> your suggestion of ThreadBlockinVMWithDeadlockPrevention seems a big >>> improvement to me. :) >> >> How about ThreadBlockInVMForLock ??? This answers the question "why" >> this class, vs. "what" this class does.? Since the latter can change. > I like that name. Is that name okay with you David? Sorry no. "Lock" still adds zero information about when/why you would use this. It's used within Monitor::lock and Monitor::wait so is not specific to "locking" even in that class. This is about blocking in the VM and we need to know what this version does differently to the existing TBIVM. There are lots of different types of "locking" in the VM and we don't use this with them. Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) David ----- > Thanks, > Patricio >> thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> ----- >>> >>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>> Hi David, >>>> >>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>> Hi David, >>>>>> >>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>> Hi Patricio, >>>>>>> >>>>>>> >>>>>>> >>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>> this, pulling together a number of ideas from different people to >>>>>>> make it all work! >>>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>>> >>>>> :) Nothing innovative there. >>>>> >>>>>>> I've only got a few minor comments/suggestions. >>>>>>> >>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>> Inc: >>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>> >>>>>>> >>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>> >>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>>>> masking the actual difference between the two wrappers to me. It >>>>>>> seems to me that an extra arg to transition_and_fence should >>>>>>> allow you to handle the new behaviour without having to duplicate >>>>>>> so much of this code. In any case the semantics of >>>>>>> ThreadLockBlockInVM needs to be described. >>>>>> I could do it with one extra argument, but I would need to add two >>>>>> extra branches in transition_and_fence(), one to decide if I'm in >>>>>> the Monitor case to avoid calling >>>>>> SafepointMechanism::block_if_requested() directly and another one >>>>>> to actually decide if I'm transitioning in or out, since the >>>>>> actions to perform are different. I think it is easier to read >>>>>> without adding new conditionals, and also we will save those extra >>>>>> branches, but if you think it's better this way I can change it. >>>>> >>>>> I would like something that tells me more clearly how this new >>>>> transition helper differs from the existing TBIVM. Sharing the code >>>>> between them and using different args would be one way. Documenting >>>>> the difference in comments would be another. Your choice. >>>> Ok, I added a description on top of TLBIVM. >>>> >>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>>>> refers to. I find the name quite jarring to read. >>>>>> What about changing it to ThreadBlockinMonitor? >>>>> >>>>> That's not quite conveying the semantics. The problem is that the >>>>> semantics we are changing compared to TBIVM are not evident in the >>>>> TBIVM name. If TBIVM was actually >>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>> perhaps that lengthy, but clear name would be okay anyway? >>>> Not convinced on that name since we are blocking at safepoints in >>>> the destructor. Based on the comments I added how about >>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>> conditions for deadlocks). >>>> >>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>> don't really convey to me what happens - what is being >>>>>>> "preempted" here? I would suggest a more direct >>>>>>> Monitor::release_for_safepoint >>>>>> Changed. >>>>>> >>>>>>> --- >>>>>>> >>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>>> need bother at all with the one logging statement that is present. >>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>> follow you with the name, isn't that how we name this monitors? I >>>>>> tried to differentiate them from Java monitors. What about just >>>>>> "monitor"? >>>>> >>>>> How about vmmonitor ? >>>> Ok, changed. >>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> >>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>>>> checks. >>>>>>> >>>>>>> The comment there should only say "not require". >>>>>> Done. >>>>>> >>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>> ? _lock.unlock(); >>>>>>> } >>>>>>> >>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>> suitable assertions we should have here? safepoint-in-progress or >>>>>>> handshake-in-progress? _owner == Thread::current? >>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>> safepoint-in-progress does not really work because _state could >>>>>> change to _not_synchronized right after you checked for it in TLBIVM. >>>>> >>>>> Okay. >>>>> >>>>>>> Nit: >>>>>>> >>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>> INTPTR_FORMAT >>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>> p2i(Thread::current())); >>>>>>> >>>>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>>>> second line should indent to the first comma, but that will make >>>>>>> the second line extend way past 80 columns. >>>>>>> >>>>>>> Also you could factor that assertion for >>>>>>> _owner==Thread::current() into its own function or macro to avoid >>>>>>> the repetition. >>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>> >>>>> I though it should indent to the comma because it is a continuation >>>>> of the same argument being passed to the assert "function". But I'm >>>>> okay with Dan's suggestion. >>>>> >>>>> Factoring it into its own little function or macro would still be >>>>> good to avoid the repetition. >>>> Ok, added new function assert_owned_by_self(). I could change it to >>>> assert_owner(Thread*) and use it for the NULL case too unifying the >>>> printed messages to something like "invalid owner: owner=" >>>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>>> >>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>> Object.wait() */); >>>>>>> >>>>>>> This needs to be returned to its original place as per Dan's >>>>>>> comments. >>>>>> Done. >>>>>> >>>>>>> ??? } else { >>>>>>> ????? Monitor::lock(self); >>>>>>> ??? } >>>>>>> >>>>>>> You don't need Monitor:: here >>>>>> Removed. >>>>>> >>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>>>> PlatformMonitor now. >>>>>>> >>>>>>> This needs to be resolved before committing. Some of the existing >>>>>>> commentary on what raw monitors are needs to be retained. Not >>>>>>> clear if we need to set the _owner field or can just skip it. >>>>>> Is it okay if I keep the following comments? >>>>>> >>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>> lock_without_safepoint_check() >>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>>>> via JVM_RawMonitorEnter. >>>>>> // >>>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>>> properly with the native >>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>> JVM_RawMonitors in terms of >>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>> >>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>> >>>>>> >>>>>> I could keep setting the owner as _owner = >>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>>>> hurt. >>>>> >>>>> It's useful for checking usage errors, but we won't have that if we >>>>> replace with PlatformMonitor, so may as well drop it now IMO. >>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>> and before releasing it though. >>>> >>>>>>> Monitor::~Monitor() { >>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>>>> p2i(_owner)); >>>>>>> } >>>>>>> >>>>>>> Will this automatically result in the PlatformMonitor destructor >>>>>>> being called? >>>>>> Yes, should I add a comment to make it clear that >>>>>> ~PlatformMonitor() will be executed? >>>>> >>>>> No need - assume other people have a better understanding of C++ >>>>> than I do :) >>>> >>>> Below is version v04, which also contains a correction pointed out >>>> off-list by Robbin to do a local poll first in >>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>> polls. Since the thread local poll is armed after changing _state to >>>> _synchronizing, if we only do a global poll in the TLBIVM >>>> constructor we could detect there is a safepoint in progress and >>>> callback but when coming back in the destructor >>>> SafepointMechanism::should_block() could miss detecting the >>>> safepoint in progress since that method checks first for local polls. >>>> >>>> >>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>> >>>> >>>> Thanks, >>>> Patricio >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> >>>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>>> --- >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>> >>>> >> > From daniel.daugherty at oracle.com Sat Feb 2 00:58:16 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Feb 2019 19:58:16 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: On 2/1/19 7:49 PM, David Holmes wrote: > > > On 2/02/2019 7:48 am, Patricio Chilano wrote: >> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>> In regards to the name ThreadLockBlockInVM ... I don't have a good >>>> suggestion. >>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>> anything. So your suggestion of >>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement to >>>> me. :) >>> >>> How about ThreadBlockInVMForLock ??? This answers the question "why" >>> this class, vs. "what" this class does.? Since the latter can change. >> I like that name. Is that name okay with you David? > > Sorry no. "Lock" still adds zero information about when/why you would > use this. It's used within Monitor::lock and Monitor::wait so is not > specific to "locking" even in that class. This is about blocking in > the VM and we need to know what this version does differently to the > existing TBIVM. There are lots of different types of "locking" in the > VM and we don't use this with them. > > Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) ThreadBlockInVMBecauseSneakyLockingIsEvil? ThreadBlockinVMWithDeadlockPrevention is okay. ThreadBlockinVMWithDeadlockCheck ThreadBlockinVMWithDeadlockChk ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) Just pick a name and run with it... :-) Dan > > David > ----- > > >> Thanks, >> Patricio >>> thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>> Hi David, >>>>> >>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>> Hi Patricio, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>> this, pulling together a number of ideas from different people >>>>>>>> to make it all work! >>>>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>>>> >>>>>> :) Nothing innovative there. >>>>>> >>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>> >>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>> Full: >>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>> Inc: >>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>> >>>>>>>> >>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>> >>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which >>>>>>>> is masking the actual difference between the two wrappers to >>>>>>>> me. It seems to me that an extra arg to transition_and_fence >>>>>>>> should allow you to handle the new behaviour without having to >>>>>>>> duplicate so much of this code. In any case the semantics of >>>>>>>> ThreadLockBlockInVM needs to be described. >>>>>>> I could do it with one extra argument, but I would need to add >>>>>>> two extra branches in transition_and_fence(), one to decide if >>>>>>> I'm in the Monitor case to avoid calling >>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>> one to actually decide if I'm transitioning in or out, since the >>>>>>> actions to perform are different. I think it is easier to read >>>>>>> without adding new conditionals, and also we will save those >>>>>>> extra branches, but if you think it's better this way I can >>>>>>> change it. >>>>>> >>>>>> I would like something that tells me more clearly how this new >>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>> code between them and using different args would be one way. >>>>>> Documenting the difference in comments would be another. Your >>>>>> choice. >>>>> Ok, I added a description on top of TLBIVM. >>>>> >>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>> >>>>>> That's not quite conveying the semantics. The problem is that the >>>>>> semantics we are changing compared to TBIVM are not evident in >>>>>> the TBIVM name. If TBIVM was actually >>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>>> perhaps that lengthy, but clear name would be okay anyway? >>>>> Not convinced on that name since we are blocking at safepoints in >>>>> the destructor. Based on the comments I added how about >>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>> conditions for deadlocks). >>>>> >>>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>>> don't really convey to me what happens - what is being >>>>>>>> "preempted" here? I would suggest a more direct >>>>>>>> Monitor::release_for_safepoint >>>>>>> Changed. >>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>>>> need bother at all with the one logging statement that is present. >>>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>>> follow you with the name, isn't that how we name this monitors? >>>>>>> I tried to differentiate them from Java monitors. What about >>>>>>> just "monitor"? >>>>>> >>>>>> How about vmmonitor ? >>>>> Ok, changed. >>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>> >>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>> safepoint checks. >>>>>>>> >>>>>>>> The comment there should only say "not require". >>>>>>> Done. >>>>>>> >>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>> ? _lock.unlock(); >>>>>>>> } >>>>>>>> >>>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>>> suitable assertions we should have here? safepoint-in-progress >>>>>>>> or handshake-in-progress? _owner == Thread::current? >>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>> safepoint-in-progress does not really work because _state could >>>>>>> change to _not_synchronized right after you checked for it in >>>>>>> TLBIVM. >>>>>> >>>>>> Okay. >>>>>> >>>>>>>> Nit: >>>>>>>> >>>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>>> INTPTR_FORMAT >>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>> p2i(Thread::current())); >>>>>>>> >>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>> The second line should indent to the first comma, but that will >>>>>>>> make the second line extend way past 80 columns. >>>>>>>> >>>>>>>> Also you could factor that assertion for >>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>> avoid the repetition. >>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>> >>>>>> I though it should indent to the comma because it is a >>>>>> continuation of the same argument being passed to the assert >>>>>> "function". But I'm okay with Dan's suggestion. >>>>>> >>>>>> Factoring it into its own little function or macro would still be >>>>>> good to avoid the repetition. >>>>> Ok, added new function assert_owned_by_self(). I could change it >>>>> to assert_owner(Thread*) and use it for the NULL case too unifying >>>>> the printed messages to something like "invalid owner: owner=" >>>>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>>>> >>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>> Object.wait() */); >>>>>>>> >>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>> comments. >>>>>>> Done. >>>>>>> >>>>>>>> ??? } else { >>>>>>>> ????? Monitor::lock(self); >>>>>>>> ??? } >>>>>>>> >>>>>>>> You don't need Monitor:: here >>>>>>> Removed. >>>>>>> >>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be >>>>>>>> a PlatformMonitor now. >>>>>>>> >>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>> retained. Not clear if we need to set the _owner field or can >>>>>>>> just skip it. >>>>>>> Is it okay if I keep the following comments? >>>>>>> >>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>> lock_without_safepoint_check() >>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>> threads via JVM_RawMonitorEnter. >>>>>>> // >>>>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>>>> properly with the native >>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>> JVM_RawMonitors in terms of >>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>> >>>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>>> >>>>>>> >>>>>>> I could keep setting the owner as _owner = >>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>> wouldn't hurt. >>>>>> >>>>>> It's useful for checking usage errors, but we won't have that if >>>>>> we replace with PlatformMonitor, so may as well drop it now IMO. >>>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>>> and before releasing it though. >>>>> >>>>>>>> Monitor::~Monitor() { >>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>> } >>>>>>>> >>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>> destructor being called? >>>>>>> Yes, should I add a comment to make it clear that >>>>>>> ~PlatformMonitor() will be executed? >>>>>> >>>>>> No need - assume other people have a better understanding of C++ >>>>>> than I do :) >>>>> >>>>> Below is version v04, which also contains a correction pointed out >>>>> off-list by Robbin to do a local poll first in >>>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>>> polls. Since the thread local poll is armed after changing _state >>>>> to _synchronizing, if we only do a global poll in the TLBIVM >>>>> constructor we could detect there is a safepoint in progress and >>>>> callback but when coming back in the destructor >>>>> SafepointMechanism::should_block() could miss detecting the >>>>> safepoint in progress since that method checks first for local polls. >>>>> >>>>> >>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>> >>>>> >>>>> Thanks, >>>>> Patricio >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>>>> >>>>>>> Thanks, >>>>>>> Patricio >>>>>>>> --- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>> >>>>> >>> >> From igor.ignatyev at oracle.com Sat Feb 2 04:58:11 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 1 Feb 2019 20:58:11 -0800 Subject: RFR(S) [12] : 8218197 : [failurehandler] parent processes shouldn't be killed till their children are handle Message-ID: http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html > 25 lines changed: 8 ins; 2 del; 15 mod; Hi all, could you please review this small fix for timeout handler? after 8205687[1], we start to kill a process to get a core dump. since we gather info from the parent process before its children and killing a parent can kill children, we started to observer suspiciously disappeared children processes (8176214[2], 8217170[3]). the patch changes the order we gather information, so we never kill a process till we gather from all its children. the other part of the patch fixes html-output. [1] https://bugs.openjdk.java.net/browse/JDK-8205687 [2] https://bugs.openjdk.java.net/browse/JDK-8176214 [3] https://bugs.openjdk.java.net/browse/JDK-8217170 webrev: http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8218197 testing: manually verified reports generated for all time-outing multi-processed test on linux, windows, solaris and mac. Thanks, -- Igor From patricio.chilano.mateo at oracle.com Mon Feb 4 01:46:30 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Sun, 3 Feb 2019 20:46:30 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: Hi all, Here is v05: Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ Tested tiers 1-6. Thanks, Patricio On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: > On 2/1/19 7:49 PM, David Holmes wrote: >> >> >> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>> In regards to the name ThreadLockBlockInVM ... I don't have a good >>>>> suggestion. >>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>> anything. So your suggestion of >>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement to >>>>> me. :) >>>> >>>> How about ThreadBlockInVMForLock ??? This answers the question >>>> "why" this class, vs. "what" this class does. Since the latter can >>>> change. >>> I like that name. Is that name okay with you David? >> >> Sorry no. "Lock" still adds zero information about when/why you would >> use this. It's used within Monitor::lock and Monitor::wait so is not >> specific to "locking" even in that class. This is about blocking in >> the VM and we need to know what this version does differently to the >> existing TBIVM. There are lots of different types of "locking" in the >> VM and we don't use this with them. >> >> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) > > ThreadBlockInVMBecauseSneakyLockingIsEvil? > > ThreadBlockinVMWithDeadlockPrevention is okay. > > ThreadBlockinVMWithDeadlockCheck > ThreadBlockinVMWithDeadlockChk > ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) > > Just pick a name and run with it... :-) > > Dan > > >> >> David >> ----- >> >> >>> Thanks, >>> Patricio >>>> thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>> Hi David, >>>>>> >>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>> Hi Patricio, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>> this, pulling together a number of ideas from different people >>>>>>>>> to make it all work! >>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>>>>> >>>>>>> :) Nothing innovative there. >>>>>>> >>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>> >>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>> Full: >>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>> Inc: >>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>> >>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which >>>>>>>>> is masking the actual difference between the two wrappers to >>>>>>>>> me. It seems to me that an extra arg to transition_and_fence >>>>>>>>> should allow you to handle the new behaviour without having to >>>>>>>>> duplicate so much of this code. In any case the semantics of >>>>>>>>> ThreadLockBlockInVM needs to be described. >>>>>>>> I could do it with one extra argument, but I would need to add >>>>>>>> two extra branches in transition_and_fence(), one to decide if >>>>>>>> I'm in the Monitor case to avoid calling >>>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>>> one to actually decide if I'm transitioning in or out, since >>>>>>>> the actions to perform are different. I think it is easier to >>>>>>>> read without adding new conditionals, and also we will save >>>>>>>> those extra branches, but if you think it's better this way I >>>>>>>> can change it. >>>>>>> >>>>>>> I would like something that tells me more clearly how this new >>>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>>> code between them and using different args would be one way. >>>>>>> Documenting the difference in comments would be another. Your >>>>>>> choice. >>>>>> Ok, I added a description on top of TLBIVM. >>>>>> >>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>> >>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>> the semantics we are changing compared to TBIVM are not evident >>>>>>> in the TBIVM name. If TBIVM was actually >>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>>>> perhaps that lengthy, but clear name would be okay anyway? >>>>>> Not convinced on that name since we are blocking at safepoints in >>>>>> the destructor. Based on the comments I added how about >>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>> conditions for deadlocks). >>>>>> >>>>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>>>> don't really convey to me what happens - what is being >>>>>>>>> "preempted" here? I would suggest a more direct >>>>>>>>> Monitor::release_for_safepoint >>>>>>>> Changed. >>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>>>> relate to a "native" monitor?? Actually I'm not even sure if >>>>>>>>> we need bother at all with the one logging statement that is >>>>>>>>> present. >>>>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>>>> follow you with the name, isn't that how we name this monitors? >>>>>>>> I tried to differentiate them from Java monitors. What about >>>>>>>> just "monitor"? >>>>>>> >>>>>>> How about vmmonitor ? >>>>>> Ok, changed. >>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>> >>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>> safepoint checks. >>>>>>>>> >>>>>>>>> The comment there should only say "not require". >>>>>>>> Done. >>>>>>>> >>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>> ? _lock.unlock(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>>>> suitable assertions we should have here? safepoint-in-progress >>>>>>>>> or handshake-in-progress? _owner == Thread::current? >>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>> safepoint-in-progress does not really work because _state could >>>>>>>> change to _not_synchronized right after you checked for it in >>>>>>>> TLBIVM. >>>>>>> >>>>>>> Okay. >>>>>>> >>>>>>>>> Nit: >>>>>>>>> >>>>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>>>> INTPTR_FORMAT >>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>> p2i(Thread::current())); >>>>>>>>> >>>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>>> The second line should indent to the first comma, but that >>>>>>>>> will make the second line extend way past 80 columns. >>>>>>>>> >>>>>>>>> Also you could factor that assertion for >>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>> avoid the repetition. >>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>> >>>>>>> I though it should indent to the comma because it is a >>>>>>> continuation of the same argument being passed to the assert >>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>> >>>>>>> Factoring it into its own little function or macro would still >>>>>>> be good to avoid the repetition. >>>>>> Ok, added new function assert_owned_by_self(). I could change it >>>>>> to assert_owner(Thread*) and use it for the NULL case too >>>>>> unifying the printed messages to something like "invalid owner: >>>>>> owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you >>>>>> think? >>>>>> >>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>> Object.wait() */); >>>>>>>>> >>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>> comments. >>>>>>>> Done. >>>>>>>> >>>>>>>>> ??? } else { >>>>>>>>> ????? Monitor::lock(self); >>>>>>>>> ??? } >>>>>>>>> >>>>>>>>> You don't need Monitor:: here >>>>>>>> Removed. >>>>>>>> >>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just >>>>>>>>> be a PlatformMonitor now. >>>>>>>>> >>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>> retained. Not clear if we need to set the _owner field or can >>>>>>>>> just skip it. >>>>>>>> Is it okay if I keep the following comments? >>>>>>>> >>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>> lock_without_safepoint_check() >>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>> // >>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>> interoperate properly with the native >>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>> JVM_RawMonitors in terms of >>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>> >>>>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>>>> >>>>>>>> >>>>>>>> I could keep setting the owner as _owner = >>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>> wouldn't hurt. >>>>>>> >>>>>>> It's useful for checking usage errors, but we won't have that if >>>>>>> we replace with PlatformMonitor, so may as well drop it now IMO. >>>>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>>>> and before releasing it though. >>>>>> >>>>>>>>> Monitor::~Monitor() { >>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>> } >>>>>>>>> >>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>> destructor being called? >>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>> ~PlatformMonitor() will be executed? >>>>>>> >>>>>>> No need - assume other people have a better understanding of C++ >>>>>>> than I do :) >>>>>> >>>>>> Below is version v04, which also contains a correction pointed >>>>>> out off-list by Robbin to do a local poll first in >>>>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>>>> polls. Since the thread local poll is armed after changing _state >>>>>> to _synchronizing, if we only do a global poll in the TLBIVM >>>>>> constructor we could detect there is a safepoint in progress and >>>>>> callback but when coming back in the destructor >>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>> safepoint in progress since that method checks first for local >>>>>> polls. >>>>>> >>>>>> >>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks for looking into this! Waiting on your comments to send >>>>>>>> v04. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Patricio >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From david.holmes at oracle.com Mon Feb 4 04:42:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Feb 2019 14:42:34 +1000 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: Hi Patricio, I don't want to drag this out but we're losing some detail in the assertion messages here: + static inline void assert_owner(Thread *owner, Thread *thread) { + assert(owner == thread, + "invalid owner: owner=" INTPTR_FORMAT ", should be=" INTPTR_FORMAT, + p2i(owner), p2i(thread)); + } First does inline mean anything on a file static function? Second if this were actually a member function (yes I know I should have realized this on previous feedback - my bad, sorry) then you don't need to pass in the owner. Finally, I'd like to see clearer messages for the common cases of unowned or owned-by-current-thread e.g. something like #ifdef DEBUG const char* msg = "invalid owner"; if (thread == NULL) { msg = "should be un-owned"; } else if (thread == Thread::current()) { msg = "should be owned by current thread"; } assert(owner == thread, "%s: owner=" INTPTR_FORMAT ", should be=" INTPTR_FORMAT, msg, p2i(owner), p2i(thread)); #endif Otherwise no further comments. Thanks, David ----- On 4/02/2019 11:46 am, Patricio Chilano wrote: > Hi all, > > Here is v05: > > Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ > > Tested tiers 1-6. > > Thanks, > Patricio > > On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >> On 2/1/19 7:49 PM, David Holmes wrote: >>> >>> >>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a good >>>>>> suggestion. >>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>> anything. So your suggestion of >>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement to >>>>>> me. :) >>>>> >>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>> "why" this class, vs. "what" this class does. Since the latter can >>>>> change. >>>> I like that name. Is that name okay with you David? >>> >>> Sorry no. "Lock" still adds zero information about when/why you would >>> use this. It's used within Monitor::lock and Monitor::wait so is not >>> specific to "locking" even in that class. This is about blocking in >>> the VM and we need to know what this version does differently to the >>> existing TBIVM. There are lots of different types of "locking" in the >>> VM and we don't use this with them. >>> >>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >> >> ThreadBlockInVMBecauseSneakyLockingIsEvil? >> >> ThreadBlockinVMWithDeadlockPrevention is okay. >> >> ThreadBlockinVMWithDeadlockCheck >> ThreadBlockinVMWithDeadlockChk >> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >> >> Just pick a name and run with it... :-) >> >> Dan >> >> >>> >>> David >>> ----- >>> >>> >>>> Thanks, >>>> Patricio >>>>> thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>> Hi Patricio, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>>> this, pulling together a number of ideas from different people >>>>>>>>>> to make it all work! >>>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>>>>>> >>>>>>>> :) Nothing innovative there. >>>>>>>> >>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>> >>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>> Full: >>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>> Inc: >>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>> >>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which >>>>>>>>>> is masking the actual difference between the two wrappers to >>>>>>>>>> me. It seems to me that an extra arg to transition_and_fence >>>>>>>>>> should allow you to handle the new behaviour without having to >>>>>>>>>> duplicate so much of this code. In any case the semantics of >>>>>>>>>> ThreadLockBlockInVM needs to be described. >>>>>>>>> I could do it with one extra argument, but I would need to add >>>>>>>>> two extra branches in transition_and_fence(), one to decide if >>>>>>>>> I'm in the Monitor case to avoid calling >>>>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>>>> one to actually decide if I'm transitioning in or out, since >>>>>>>>> the actions to perform are different. I think it is easier to >>>>>>>>> read without adding new conditionals, and also we will save >>>>>>>>> those extra branches, but if you think it's better this way I >>>>>>>>> can change it. >>>>>>>> >>>>>>>> I would like something that tells me more clearly how this new >>>>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>>>> code between them and using different args would be one way. >>>>>>>> Documenting the difference in comments would be another. Your >>>>>>>> choice. >>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>> >>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>> >>>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>>> the semantics we are changing compared to TBIVM are not evident >>>>>>>> in the TBIVM name. If TBIVM was actually >>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>>>>> perhaps that lengthy, but clear name would be okay anyway? >>>>>>> Not convinced on that name since we are blocking at safepoints in >>>>>>> the destructor. Based on the comments I added how about >>>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>> conditions for deadlocks). >>>>>>> >>>>>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>>>>> don't really convey to me what happens - what is being >>>>>>>>>> "preempted" here? I would suggest a more direct >>>>>>>>>> Monitor::release_for_safepoint >>>>>>>>> Changed. >>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>>>>> relate to a "native" monitor?? Actually I'm not even sure if >>>>>>>>>> we need bother at all with the one logging statement that is >>>>>>>>>> present. >>>>>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>>>>> follow you with the name, isn't that how we name this monitors? >>>>>>>>> I tried to differentiate them from Java monitors. What about >>>>>>>>> just "monitor"? >>>>>>>> >>>>>>>> How about vmmonitor ? >>>>>>> Ok, changed. >>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>> >>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>> safepoint checks. >>>>>>>>>> >>>>>>>>>> The comment there should only say "not require". >>>>>>>>> Done. >>>>>>>>> >>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>> ? _lock.unlock(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>>>>> suitable assertions we should have here? safepoint-in-progress >>>>>>>>>> or handshake-in-progress? _owner == Thread::current? >>>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>>> safepoint-in-progress does not really work because _state could >>>>>>>>> change to _not_synchronized right after you checked for it in >>>>>>>>> TLBIVM. >>>>>>>> >>>>>>>> Okay. >>>>>>>> >>>>>>>>>> Nit: >>>>>>>>>> >>>>>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>>>>> INTPTR_FORMAT >>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>> p2i(Thread::current())); >>>>>>>>>> >>>>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>>>> The second line should indent to the first comma, but that >>>>>>>>>> will make the second line extend way past 80 columns. >>>>>>>>>> >>>>>>>>>> Also you could factor that assertion for >>>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>>> avoid the repetition. >>>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>>> >>>>>>>> I though it should indent to the comma because it is a >>>>>>>> continuation of the same argument being passed to the assert >>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>> >>>>>>>> Factoring it into its own little function or macro would still >>>>>>>> be good to avoid the repetition. >>>>>>> Ok, added new function assert_owned_by_self(). I could change it >>>>>>> to assert_owner(Thread*) and use it for the NULL case too >>>>>>> unifying the printed messages to something like "invalid owner: >>>>>>> owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you >>>>>>> think? >>>>>>> >>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>> Object.wait() */); >>>>>>>>>> >>>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>>> comments. >>>>>>>>> Done. >>>>>>>>> >>>>>>>>>> ??? } else { >>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>> ??? } >>>>>>>>>> >>>>>>>>>> You don't need Monitor:: here >>>>>>>>> Removed. >>>>>>>>> >>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just >>>>>>>>>> be a PlatformMonitor now. >>>>>>>>>> >>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>> retained. Not clear if we need to set the _owner field or can >>>>>>>>>> just skip it. >>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>> >>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>> lock_without_safepoint_check() >>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>> // >>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>> interoperate properly with the native >>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>> >>>>>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>>>>> >>>>>>>>> >>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>> wouldn't hurt. >>>>>>>> >>>>>>>> It's useful for checking usage errors, but we won't have that if >>>>>>>> we replace with PlatformMonitor, so may as well drop it now IMO. >>>>>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>>>>> and before releasing it though. >>>>>>> >>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>> destructor being called? >>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>> >>>>>>>> No need - assume other people have a better understanding of C++ >>>>>>>> than I do :) >>>>>>> >>>>>>> Below is version v04, which also contains a correction pointed >>>>>>> out off-list by Robbin to do a local poll first in >>>>>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>>>>> polls. Since the thread local poll is armed after changing _state >>>>>>> to _synchronizing, if we only do a global poll in the TLBIVM >>>>>>> constructor we could detect there is a safepoint in progress and >>>>>>> callback but when coming back in the destructor >>>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>>> safepoint in progress since that method checks first for local >>>>>>> polls. >>>>>>> >>>>>>> >>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Patricio >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for looking into this! Waiting on your comments to send >>>>>>>>> v04. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Patricio >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> > From patricio.chilano.mateo at oracle.com Mon Feb 4 06:46:46 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Mon, 4 Feb 2019 01:46:46 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: <6526b9c4-d394-ea7a-8c76-a292e0ac0e65@oracle.com> Hi David, On 2/3/19 11:42 PM, David Holmes wrote: > Hi Patricio, > > I don't want to drag this out but we're losing some detail in the > assertion messages here: > > + static inline void assert_owner(Thread *owner, Thread *thread) { > +?? assert(owner == thread, > +????????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" > INTPTR_FORMAT, > +????????? p2i(owner), p2i(thread)); > + } > > First does inline mean anything on a file static function? > > Second if this were actually a member function (yes I know I should > have realized this on previous feedback - my bad, sorry) then you > don't need to pass in the owner. No problem, I also liked it more being a member function actually. Is it okay then if I switch it back as it was in v04 and change the msg for those two cases? Although I don't agree we are losing information. The information is the same, it's only presented different. Thanks, Patricio > Finally, I'd like to see clearer messages for the common cases of > unowned or owned-by-current-thread e.g. something like > > #ifdef DEBUG > ? const char* msg = "invalid owner"; > ? if (thread == NULL) { > ??? msg = "should be un-owned"; > ? } > ? else if (thread == Thread::current()) { > ??? msg = "should be owned by current thread"; > ? } > ? assert(owner == thread, "%s: owner=" INTPTR_FORMAT ", should be=" > INTPTR_FORMAT, > ???????? msg, p2i(owner), p2i(thread)); > #endif > > Otherwise no further comments. > > Thanks, > David > ----- > > On 4/02/2019 11:46 am, Patricio Chilano wrote: >> Hi all, >> >> Here is v05: >> >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >> >> Tested tiers 1-6. >> >> Thanks, >> Patricio >> >> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>> On 2/1/19 7:49 PM, David Holmes wrote: >>>> >>>> >>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>>> good suggestion. >>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>>> anything. So your suggestion of >>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement to >>>>>>> me. :) >>>>>> >>>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>>> "why" this class, vs. "what" this class does. Since the latter >>>>>> can change. >>>>> I like that name. Is that name okay with you David? >>>> >>>> Sorry no. "Lock" still adds zero information about when/why you >>>> would use this. It's used within Monitor::lock and Monitor::wait so >>>> is not specific to "locking" even in that class. This is about >>>> blocking in the VM and we need to know what this version does >>>> differently to the existing TBIVM. There are lots of different >>>> types of "locking" in the VM and we don't use this with them. >>>> >>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>> >>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>> >>> ThreadBlockinVMWithDeadlockPrevention is okay. >>> >>> ThreadBlockinVMWithDeadlockCheck >>> ThreadBlockinVMWithDeadlockChk >>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>> >>> Just pick a name and run with it... :-) >>> >>> Dan >>> >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, >>>>> Patricio >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>> Hi Patricio, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>>>> this, pulling together a number of ideas from different >>>>>>>>>>> people to make it all work! >>>>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation? >>>>>>>>>> : ) >>>>>>>>> >>>>>>>>> :) Nothing innovative there. >>>>>>>>> >>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>> >>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>> Full: >>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>> Inc: >>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>> >>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>> behaviour without having to duplicate so much of this code. >>>>>>>>>>> In any case the semantics of ThreadLockBlockInVM needs to be >>>>>>>>>>> described. >>>>>>>>>> I could do it with one extra argument, but I would need to >>>>>>>>>> add two extra branches in transition_and_fence(), one to >>>>>>>>>> decide if I'm in the Monitor case to avoid calling >>>>>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>>>>> one to actually decide if I'm transitioning in or out, since >>>>>>>>>> the actions to perform are different. I think it is easier to >>>>>>>>>> read without adding new conditionals, and also we will save >>>>>>>>>> those extra branches, but if you think it's better this way I >>>>>>>>>> can change it. >>>>>>>>> >>>>>>>>> I would like something that tells me more clearly how this new >>>>>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>>>>> code between them and using different args would be one way. >>>>>>>>> Documenting the difference in comments would be another. Your >>>>>>>>> choice. >>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>> >>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>> >>>>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>>>> the semantics we are changing compared to TBIVM are not >>>>>>>>> evident in the TBIVM name. If TBIVM was actually >>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - >>>>>>>>> but perhaps that lengthy, but clear name would be okay anyway? >>>>>>>> Not convinced on that name since we are blocking at safepoints >>>>>>>> in the destructor. Based on the comments I added how about >>>>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>> conditions for deadlocks). >>>>>>>> >>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>> preempt_by_safepoint don't really convey to me what happens >>>>>>>>>>> - what is being "preempted" here? I would suggest a more >>>>>>>>>>> direct Monitor::release_for_safepoint >>>>>>>>>> Changed. >>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not even >>>>>>>>>>> sure if we need bother at all with the one logging statement >>>>>>>>>>> that is present. >>>>>>>>>> I added it to eventually track unbounded try locks. Not sure >>>>>>>>>> I follow you with the name, isn't that how we name this >>>>>>>>>> monitors? I tried to differentiate them from Java monitors. >>>>>>>>>> What about just "monitor"? >>>>>>>>> >>>>>>>>> How about vmmonitor ? >>>>>>>> Ok, changed. >>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>> >>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>> safepoint checks. >>>>>>>>>>> >>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>> Done. >>>>>>>>>> >>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Apart from renaming this as suggested above, aren't there >>>>>>>>>>> any suitable assertions we should have here? >>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>>> Thread::current? >>>>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>>>> safepoint-in-progress does not really work because _state >>>>>>>>>> could change to _not_synchronized right after you checked for >>>>>>>>>> it in TLBIVM. >>>>>>>>> >>>>>>>>> Okay. >>>>>>>>> >>>>>>>>>>> Nit: >>>>>>>>>>> >>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>> >>>>>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>>>>> The second line should indent to the first comma, but that >>>>>>>>>>> will make the second line extend way past 80 columns. >>>>>>>>>>> >>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>>>> avoid the repetition. >>>>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>>>> >>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>> continuation of the same argument being passed to the assert >>>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>>> >>>>>>>>> Factoring it into its own little function or macro would still >>>>>>>>> be good to avoid the repetition. >>>>>>>> Ok, added new function assert_owned_by_self(). I could change >>>>>>>> it to assert_owner(Thread*) and use it for the NULL case too >>>>>>>> unifying the printed messages to something like "invalid owner: >>>>>>>> owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you >>>>>>>> think? >>>>>>>> >>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>> Object.wait() */); >>>>>>>>>>> >>>>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>>>> comments. >>>>>>>>>> Done. >>>>>>>>>> >>>>>>>>>>> ??? } else { >>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>> ??? } >>>>>>>>>>> >>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>> Removed. >>>>>>>>>> >>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just >>>>>>>>>>> be a PlatformMonitor now. >>>>>>>>>>> >>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>> retained. Not clear if we need to set the _owner field or >>>>>>>>>>> can just skip it. >>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>> >>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>> // >>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>> interoperate properly with the native >>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>> >>>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>> wouldn't hurt. >>>>>>>>> >>>>>>>>> It's useful for checking usage errors, but we won't have that >>>>>>>>> if we replace with PlatformMonitor, so may as well drop it now >>>>>>>>> IMO. >>>>>>>> Ok, I added asserts that _owner should be NULL after acquiring >>>>>>>> it and before releasing it though. >>>>>>>> >>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>> destructor being called? >>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>> >>>>>>>>> No need - assume other people have a better understanding of >>>>>>>>> C++ than I do :) >>>>>>>> >>>>>>>> Below is version v04, which also contains a correction pointed >>>>>>>> out off-list by Robbin to do a local poll first in >>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>> changing _state to _synchronizing, if we only do a global poll >>>>>>>> in the TLBIVM constructor we could detect there is a safepoint >>>>>>>> in progress and callback but when coming back in the destructor >>>>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>>>> safepoint in progress since that method checks first for local >>>>>>>> polls. >>>>>>>> >>>>>>>> >>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Patricio >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>> send v04. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Patricio >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From david.holmes at oracle.com Mon Feb 4 07:36:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Feb 2019 17:36:04 +1000 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <6526b9c4-d394-ea7a-8c76-a292e0ac0e65@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <6526b9c4-d394-ea7a-8c76-a292e0ac0e65@oracle.com> Message-ID: <600488f0-be6d-92de-b351-8d163b06fead@oracle.com> On 4/02/2019 4:46 pm, Patricio Chilano wrote: > Hi David, > > On 2/3/19 11:42 PM, David Holmes wrote: >> Hi Patricio, >> >> I don't want to drag this out but we're losing some detail in the >> assertion messages here: >> >> + static inline void assert_owner(Thread *owner, Thread *thread) { >> +?? assert(owner == thread, >> +????????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" >> INTPTR_FORMAT, >> +????????? p2i(owner), p2i(thread)); >> + } >> >> First does inline mean anything on a file static function? >> >> Second if this were actually a member function (yes I know I should >> have realized this on previous feedback - my bad, sorry) then you >> don't need to pass in the owner. > No problem, I also liked it more being a member function actually. Is it > okay then if I switch it back as it was in v04 and change the msg for v04 has asserts plus assert_owned_by_self, I'd rather see one function assert_owned_by(Thread* expected) but with that function giving clearer information about the actual error. > those two cases? Although I don't agree we are losing information. The > information is the same, it's only presented different. The information needs decoding if you only have two hex values to compare, which is not as clear as the original assert messages, and that's what I'd like to restore - but within the context of a single helper function. Thanks, David > > Thanks, > Patricio >> Finally, I'd like to see clearer messages for the common cases of >> unowned or owned-by-current-thread e.g. something like >> >> #ifdef DEBUG >> ? const char* msg = "invalid owner"; >> ? if (thread == NULL) { >> ??? msg = "should be un-owned"; >> ? } >> ? else if (thread == Thread::current()) { >> ??? msg = "should be owned by current thread"; >> ? } >> ? assert(owner == thread, "%s: owner=" INTPTR_FORMAT ", should be=" >> INTPTR_FORMAT, >> ???????? msg, p2i(owner), p2i(thread)); >> #endif >> >> Otherwise no further comments. >> >> Thanks, >> David >> ----- >> >> On 4/02/2019 11:46 am, Patricio Chilano wrote: >>> Hi all, >>> >>> Here is v05: >>> >>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>> >>> Tested tiers 1-6. >>> >>> Thanks, >>> Patricio >>> >>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>> >>>>> >>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>>>> good suggestion. >>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>>>> anything. So your suggestion of >>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement to >>>>>>>> me. :) >>>>>>> >>>>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>>>> "why" this class, vs. "what" this class does. Since the latter >>>>>>> can change. >>>>>> I like that name. Is that name okay with you David? >>>>> >>>>> Sorry no. "Lock" still adds zero information about when/why you >>>>> would use this. It's used within Monitor::lock and Monitor::wait so >>>>> is not specific to "locking" even in that class. This is about >>>>> blocking in the VM and we need to know what this version does >>>>> differently to the existing TBIVM. There are lots of different >>>>> types of "locking" in the VM and we don't use this with them. >>>>> >>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>>> >>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>> >>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>> >>>> ThreadBlockinVMWithDeadlockCheck >>>> ThreadBlockinVMWithDeadlockChk >>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>> >>>> Just pick a name and run with it... :-) >>>> >>>> Dan >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>>>>> this, pulling together a number of ideas from different >>>>>>>>>>>> people to make it all work! >>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation : ) >>>>>>>>>> >>>>>>>>>> :) Nothing innovative there. >>>>>>>>>> >>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>> >>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>> Full: >>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>> Inc: >>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>> >>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>> behaviour without having to duplicate so much of this code. >>>>>>>>>>>> In any case the semantics of ThreadLockBlockInVM needs to be >>>>>>>>>>>> described. >>>>>>>>>>> I could do it with one extra argument, but I would need to >>>>>>>>>>> add two extra branches in transition_and_fence(), one to >>>>>>>>>>> decide if I'm in the Monitor case to avoid calling >>>>>>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>>>>>> one to actually decide if I'm transitioning in or out, since >>>>>>>>>>> the actions to perform are different. I think it is easier to >>>>>>>>>>> read without adding new conditionals, and also we will save >>>>>>>>>>> those extra branches, but if you think it's better this way I >>>>>>>>>>> can change it. >>>>>>>>>> >>>>>>>>>> I would like something that tells me more clearly how this new >>>>>>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>>>>>> code between them and using different args would be one way. >>>>>>>>>> Documenting the difference in comments would be another. Your >>>>>>>>>> choice. >>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>> >>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>> >>>>>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>>>>> the semantics we are changing compared to TBIVM are not >>>>>>>>>> evident in the TBIVM name. If TBIVM was actually >>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - >>>>>>>>>> but perhaps that lengthy, but clear name would be okay anyway? >>>>>>>>> Not convinced on that name since we are blocking at safepoints >>>>>>>>> in the destructor. Based on the comments I added how about >>>>>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>> conditions for deadlocks). >>>>>>>>> >>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>> preempt_by_safepoint don't really convey to me what happens >>>>>>>>>>>> - what is being "preempted" here? I would suggest a more >>>>>>>>>>>> direct Monitor::release_for_safepoint >>>>>>>>>>> Changed. >>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not even >>>>>>>>>>>> sure if we need bother at all with the one logging statement >>>>>>>>>>>> that is present. >>>>>>>>>>> I added it to eventually track unbounded try locks. Not sure >>>>>>>>>>> I follow you with the name, isn't that how we name this >>>>>>>>>>> monitors? I tried to differentiate them from Java monitors. >>>>>>>>>>> What about just "monitor"? >>>>>>>>>> >>>>>>>>>> How about vmmonitor ? >>>>>>>>> Ok, changed. >>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>> >>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>> safepoint checks. >>>>>>>>>>>> >>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>> Done. >>>>>>>>>>> >>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Apart from renaming this as suggested above, aren't there >>>>>>>>>>>> any suitable assertions we should have here? >>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>>>> Thread::current? >>>>>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>>>>> safepoint-in-progress does not really work because _state >>>>>>>>>>> could change to _not_synchronized right after you checked for >>>>>>>>>>> it in TLBIVM. >>>>>>>>>> >>>>>>>>>> Okay. >>>>>>>>>> >>>>>>>>>>>> Nit: >>>>>>>>>>>> >>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>>> >>>>>>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>>>>>> The second line should indent to the first comma, but that >>>>>>>>>>>> will make the second line extend way past 80 columns. >>>>>>>>>>>> >>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>>>>> avoid the repetition. >>>>>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>>>>> >>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>> continuation of the same argument being passed to the assert >>>>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>>>> >>>>>>>>>> Factoring it into its own little function or macro would still >>>>>>>>>> be good to avoid the repetition. >>>>>>>>> Ok, added new function assert_owned_by_self(). I could change >>>>>>>>> it to assert_owner(Thread*) and use it for the NULL case too >>>>>>>>> unifying the printed messages to something like "invalid owner: >>>>>>>>> owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you >>>>>>>>> think? >>>>>>>>> >>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>> >>>>>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>>>>> comments. >>>>>>>>>>> Done. >>>>>>>>>>> >>>>>>>>>>>> ??? } else { >>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>> ??? } >>>>>>>>>>>> >>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>> Removed. >>>>>>>>>>> >>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just >>>>>>>>>>>> be a PlatformMonitor now. >>>>>>>>>>>> >>>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>>> retained. Not clear if we need to set the _owner field or >>>>>>>>>>>> can just skip it. >>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>> >>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>>> // >>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>> interoperate properly with the native >>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>> >>>>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>> wouldn't hurt. >>>>>>>>>> >>>>>>>>>> It's useful for checking usage errors, but we won't have that >>>>>>>>>> if we replace with PlatformMonitor, so may as well drop it now >>>>>>>>>> IMO. >>>>>>>>> Ok, I added asserts that _owner should be NULL after acquiring >>>>>>>>> it and before releasing it though. >>>>>>>>> >>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>> destructor being called? >>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>> >>>>>>>>>> No need - assume other people have a better understanding of >>>>>>>>>> C++ than I do :) >>>>>>>>> >>>>>>>>> Below is version v04, which also contains a correction pointed >>>>>>>>> out off-list by Robbin to do a local poll first in >>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>>> changing _state to _synchronizing, if we only do a global poll >>>>>>>>> in the TLBIVM constructor we could detect there is a safepoint >>>>>>>>> in progress and callback but when coming back in the destructor >>>>>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>>>>> safepoint in progress since that method checks first for local >>>>>>>>> polls. >>>>>>>>> >>>>>>>>> >>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Patricio >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>>> send v04. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Patricio >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From matthias.baesken at sap.com Mon Feb 4 11:27:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 4 Feb 2019 11:27:52 +0000 Subject: RFR : 8218276: AIX build fails in tieredThresholdPolicy.cpp Message-ID: Hello, please review this small build fix for AIX . Currently the AIX builds for jdk/jdk fail with : "/rs6000_64/nightly/jdk/src/hotspot/share/runtime/tieredThresholdPolicy.cpp", line 481.23: 1540-0129 (S) The qualifier "SafepointSynchronize" is not defined in the current scope. "/rs6000_64/nightly/jdk/src/hotspot/share/runtime/tieredThresholdPolicy.cpp", line 506.23: 1540-0129 (S) The qualifier "SafepointSynchronize" is not defined in the current scope. Seems we miss an inclusions. Webrev and bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8218276.0/ https://bugs.openjdk.java.net/browse/JDK-8218276 Best regards, Matthias From matthias.baesken at sap.com Mon Feb 4 11:36:13 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 4 Feb 2019 11:36:13 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi David, I want to follow your suggestion ?? . I adjusted the comment , see globalDefinitions_xlc.hpp . Additionally I removed a strange ifdef handling pre-xlc10 versions that are not useful today any more for OpenJDK ( we most likely cannot build jdk/jdk with xlc versions < 10). New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Freitag, 1. Februar 2019 13:49 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; > 'magnus.ihse.bursie at oracle.com' > Cc: 'build-dev at openjdk.java.net' > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi Matthias, > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > - adjusted globalDefinitions_xlc.hpp > > I don't think it makes sense to keep the comment which was obviously > copied from the gcc file: > > // On Linux NULL is defined as a special type '__null'. Assigning > __null to > // integer variable will cause gcc warning. Use NULL_WORD in places > where a > // pointer is stored as integer value. On some platforms, > sizeof(intptr_t) > > // sizeof(void*), so here we want something which is integer type, > but has the > // same size as a pointer. > > Rather something like: > > // Some platform/tool-chain combinations can't assign NULL to an integer > // type so we define NULL_WORD to use in those contexts. For xlc they > // are the same. > > Thanks, > David > > From martin.doerr at sap.com Mon Feb 4 11:57:32 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 4 Feb 2019 11:57:32 +0000 Subject: RFR : 8218276: AIX build fails in tieredThresholdPolicy.cpp In-Reply-To: References: Message-ID: Hi Matthias, looks good and trivial. Thanks for fixing. Martin -----Original Message----- From: hotspot-dev On Behalf Of Baesken, Matthias Sent: Montag, 4. Februar 2019 12:28 To: 'hotspot-dev at openjdk.java.net' Subject: RFR : 8218276: AIX build fails in tieredThresholdPolicy.cpp Hello, please review this small build fix for AIX . Currently the AIX builds for jdk/jdk fail with : "/rs6000_64/nightly/jdk/src/hotspot/share/runtime/tieredThresholdPolicy.cpp", line 481.23: 1540-0129 (S) The qualifier "SafepointSynchronize" is not defined in the current scope. "/rs6000_64/nightly/jdk/src/hotspot/share/runtime/tieredThresholdPolicy.cpp", line 506.23: 1540-0129 (S) The qualifier "SafepointSynchronize" is not defined in the current scope. Seems we miss an inclusions. Webrev and bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8218276.0/ https://bugs.openjdk.java.net/browse/JDK-8218276 Best regards, Matthias From david.holmes at oracle.com Mon Feb 4 12:28:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Feb 2019 22:28:37 +1000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: <68040b37-1a3b-35e3-98cd-277f1a6421bf@oracle.com> Hi Matthias, On 4/02/2019 9:36 pm, Baesken, Matthias wrote: > Hi David, I want to follow your suggestion ?? . > I adjusted the comment , see globalDefinitions_xlc.hpp . Looks good. Thanks. > Additionally I removed a strange ifdef handling pre-xlc10 versions that are not useful today any more for OpenJDK > ( we most likely cannot build jdk/jdk with xlc versions < 10). Can't comment on that bit. :) Cheers, David > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Freitag, 1. Februar 2019 13:49 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' ; >> 'magnus.ihse.bursie at oracle.com' >> Cc: 'build-dev at openjdk.java.net' >> Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from >> xlc16 on AIX >> >> Hi Matthias, >> >> On 1/02/2019 10:36 pm, Baesken, Matthias wrote: >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ >>> >>> - adjusted globalDefinitions_xlc.hpp >> >> I don't think it makes sense to keep the comment which was obviously >> copied from the gcc file: >> >> // On Linux NULL is defined as a special type '__null'. Assigning >> __null to >> // integer variable will cause gcc warning. Use NULL_WORD in places >> where a >> // pointer is stored as integer value. On some platforms, >> sizeof(intptr_t) > >> // sizeof(void*), so here we want something which is integer type, >> but has the >> // same size as a pointer. >> >> Rather something like: >> >> // Some platform/tool-chain combinations can't assign NULL to an integer >> // type so we define NULL_WORD to use in those contexts. For xlc they >> // are the same. >> >> Thanks, >> David >> >> > From david.holmes at oracle.com Mon Feb 4 12:29:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Feb 2019 22:29:32 +1000 Subject: RFR : 8218276: AIX build fails in tieredThresholdPolicy.cpp In-Reply-To: References: Message-ID: <0b88bd1f-c9a4-6599-0498-3bba00fa180c@oracle.com> +1 but I'm puzzled why we don't see a problem elsewhere, even with PCH disabled ... Thanks, David On 4/02/2019 9:57 pm, Doerr, Martin wrote: > Hi Matthias, > > looks good and trivial. > > Thanks for fixing. > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of Baesken, Matthias > Sent: Montag, 4. Februar 2019 12:28 > To: 'hotspot-dev at openjdk.java.net' > Subject: RFR : 8218276: AIX build fails in tieredThresholdPolicy.cpp > > Hello, please review this small build fix for AIX . > > Currently the AIX builds for jdk/jdk fail with : > > "/rs6000_64/nightly/jdk/src/hotspot/share/runtime/tieredThresholdPolicy.cpp", > line 481.23: 1540-0129 (S) The qualifier "SafepointSynchronize" is not defined in the current scope. > "/rs6000_64/nightly/jdk/src/hotspot/share/runtime/tieredThresholdPolicy.cpp", > line 506.23: 1540-0129 (S) The qualifier "SafepointSynchronize" is not defined in the current scope. > > Seems we miss an inclusions. > > > Webrev and bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218276.0/ > > https://bugs.openjdk.java.net/browse/JDK-8218276 > > > Best regards, Matthias > From lois.foltan at oracle.com Mon Feb 4 12:32:50 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 4 Feb 2019 07:32:50 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call Message-ID: Please review this change that removes the unused method_type field associated with the appendix field of an indy or method handle call.? This is the first of a series of changes working towards JDK-8210685: Bootstrap method consolidation. open webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 co-contributors: Lois Foltan & John Rose Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux only), JCK vm & lang (linux only) Thanks, Lois From coleen.phillimore at oracle.com Mon Feb 4 13:44:42 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 08:44:42 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: On 2/3/19 11:42 PM, David Holmes wrote: > Hi Patricio, > > I don't want to drag this out but we're losing some detail in the > assertion messages here: > > + static inline void assert_owner(Thread *owner, Thread *thread) { > +?? assert(owner == thread, > +????????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" > INTPTR_FORMAT, > +????????? p2i(owner), p2i(thread)); > + } > > First does inline mean anything on a file static function? > > Second if this were actually a member function (yes I know I should > have realized this on previous feedback - my bad, sorry) then you > don't need to pass in the owner. > > Finally, I'd like to see clearer messages for the common cases of > unowned or owned-by-current-thread e.g. something like > > #ifdef DEBUG > ? const char* msg = "invalid owner"; > ? if (thread == NULL) { > ??? msg = "should be un-owned"; > ? } > ? else if (thread == Thread::current()) { > ??? msg = "should be owned by current thread"; > ? } > ? assert(owner == thread, "%s: owner=" INTPTR_FORMAT ", should be=" > INTPTR_FORMAT, > ???????? msg, p2i(owner), p2i(thread)); > #endif > > Otherwise no further comments. > > Thanks, > David > ----- > > On 4/02/2019 11:46 am, Patricio Chilano wrote: >> Hi all, >> >> Here is v05: >> >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >> >> Tested tiers 1-6. >> >> Thanks, >> Patricio >> >> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>> On 2/1/19 7:49 PM, David Holmes wrote: >>>> >>>> >>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>>> good suggestion. >>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>>> anything. So your suggestion of >>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement to >>>>>>> me. :) >>>>>> >>>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>>> "why" this class, vs. "what" this class does. Since the latter >>>>>> can change. >>>>> I like that name. Is that name okay with you David? >>>> >>>> Sorry no. "Lock" still adds zero information about when/why you >>>> would use this. It's used within Monitor::lock and Monitor::wait so >>>> is not specific to "locking" even in that class. This is about >>>> blocking in the VM and we need to know what this version does >>>> differently to the existing TBIVM. There are lots of different >>>> types of "locking" in the VM and we don't use this with them. >>>> >>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>> >>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>> >>> ThreadBlockinVMWithDeadlockPrevention is okay. If David likes this one, go with this one.?? Go with whatever name David likes. Coleen >>> >>> ThreadBlockinVMWithDeadlockCheck >>> ThreadBlockinVMWithDeadlockChk >>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>> >>> Just pick a name and run with it... :-) >>> >>> Dan >>> >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, >>>>> Patricio >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>> Hi Patricio, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>>>> this, pulling together a number of ideas from different >>>>>>>>>>> people to make it all work! >>>>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation? >>>>>>>>>> : ) >>>>>>>>> >>>>>>>>> :) Nothing innovative there. >>>>>>>>> >>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>> >>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>> Full: >>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>> Inc: >>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>> >>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>> behaviour without having to duplicate so much of this code. >>>>>>>>>>> In any case the semantics of ThreadLockBlockInVM needs to be >>>>>>>>>>> described. >>>>>>>>>> I could do it with one extra argument, but I would need to >>>>>>>>>> add two extra branches in transition_and_fence(), one to >>>>>>>>>> decide if I'm in the Monitor case to avoid calling >>>>>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>>>>> one to actually decide if I'm transitioning in or out, since >>>>>>>>>> the actions to perform are different. I think it is easier to >>>>>>>>>> read without adding new conditionals, and also we will save >>>>>>>>>> those extra branches, but if you think it's better this way I >>>>>>>>>> can change it. >>>>>>>>> >>>>>>>>> I would like something that tells me more clearly how this new >>>>>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>>>>> code between them and using different args would be one way. >>>>>>>>> Documenting the difference in comments would be another. Your >>>>>>>>> choice. >>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>> >>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>> >>>>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>>>> the semantics we are changing compared to TBIVM are not >>>>>>>>> evident in the TBIVM name. If TBIVM was actually >>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - >>>>>>>>> but perhaps that lengthy, but clear name would be okay anyway? >>>>>>>> Not convinced on that name since we are blocking at safepoints >>>>>>>> in the destructor. Based on the comments I added how about >>>>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>> conditions for deadlocks). >>>>>>>> >>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>> preempt_by_safepoint don't really convey to me what happens >>>>>>>>>>> - what is being "preempted" here? I would suggest a more >>>>>>>>>>> direct Monitor::release_for_safepoint >>>>>>>>>> Changed. >>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not even >>>>>>>>>>> sure if we need bother at all with the one logging statement >>>>>>>>>>> that is present. >>>>>>>>>> I added it to eventually track unbounded try locks. Not sure >>>>>>>>>> I follow you with the name, isn't that how we name this >>>>>>>>>> monitors? I tried to differentiate them from Java monitors. >>>>>>>>>> What about just "monitor"? >>>>>>>>> >>>>>>>>> How about vmmonitor ? >>>>>>>> Ok, changed. >>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>> >>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>> safepoint checks. >>>>>>>>>>> >>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>> Done. >>>>>>>>>> >>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Apart from renaming this as suggested above, aren't there >>>>>>>>>>> any suitable assertions we should have here? >>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>>> Thread::current? >>>>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>>>> safepoint-in-progress does not really work because _state >>>>>>>>>> could change to _not_synchronized right after you checked for >>>>>>>>>> it in TLBIVM. >>>>>>>>> >>>>>>>>> Okay. >>>>>>>>> >>>>>>>>>>> Nit: >>>>>>>>>>> >>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>> >>>>>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>>>>> The second line should indent to the first comma, but that >>>>>>>>>>> will make the second line extend way past 80 columns. >>>>>>>>>>> >>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>>>> avoid the repetition. >>>>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>>>> >>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>> continuation of the same argument being passed to the assert >>>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>>> >>>>>>>>> Factoring it into its own little function or macro would still >>>>>>>>> be good to avoid the repetition. >>>>>>>> Ok, added new function assert_owned_by_self(). I could change >>>>>>>> it to assert_owner(Thread*) and use it for the NULL case too >>>>>>>> unifying the printed messages to something like "invalid owner: >>>>>>>> owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you >>>>>>>> think? >>>>>>>> >>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>> Object.wait() */); >>>>>>>>>>> >>>>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>>>> comments. >>>>>>>>>> Done. >>>>>>>>>> >>>>>>>>>>> ??? } else { >>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>> ??? } >>>>>>>>>>> >>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>> Removed. >>>>>>>>>> >>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just >>>>>>>>>>> be a PlatformMonitor now. >>>>>>>>>>> >>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>> retained. Not clear if we need to set the _owner field or >>>>>>>>>>> can just skip it. >>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>> >>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>> // >>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>> interoperate properly with the native >>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>> >>>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>> wouldn't hurt. >>>>>>>>> >>>>>>>>> It's useful for checking usage errors, but we won't have that >>>>>>>>> if we replace with PlatformMonitor, so may as well drop it now >>>>>>>>> IMO. >>>>>>>> Ok, I added asserts that _owner should be NULL after acquiring >>>>>>>> it and before releasing it though. >>>>>>>> >>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>> destructor being called? >>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>> >>>>>>>>> No need - assume other people have a better understanding of >>>>>>>>> C++ than I do :) >>>>>>>> >>>>>>>> Below is version v04, which also contains a correction pointed >>>>>>>> out off-list by Robbin to do a local poll first in >>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>> changing _state to _synchronizing, if we only do a global poll >>>>>>>> in the TLBIVM constructor we could detect there is a safepoint >>>>>>>> in progress and callback but when coming back in the destructor >>>>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>>>> safepoint in progress since that method checks first for local >>>>>>>> polls. >>>>>>>> >>>>>>>> >>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Patricio >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>> send v04. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Patricio >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From coleen.phillimore at oracle.com Mon Feb 4 15:08:35 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 10:08:35 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks Message-ID: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> Summary: Walk code cache and deoptimize once per redefinition.* *This change touches the AOT and code cache code.? I tried to describe it in the comments in the RFE.? Basically, for redefinition, we walk the code cache per class redefined in order to find evol_method dependencies, then deoptimize if we find them, and then walk the code cache again to mark the deoptimized nmethods as not_entrant. I replaced this with only marking any nmethods for the class's methods to deoptimize (following InstanceKlass::_methods), also marking aot methods dependent on the class, and then doing the code cache walk to follow the evol_method dependencies at the end of redefinition for all the classes.?? The new code uses the Method::is_old() flag rather than comparing each method in the InstanceKlass.? Then deoptimization and marking not_entrant is done once at the end of the redefinition as well. Tested with tier1-6, all the redefinition tests locally: make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >&redefine.out make test TEST=open/test/jdk/java/lang/instrument >&instrument.out new test, and JMH test (see CR for results). Thanks, Coleen From matthias.baesken at sap.com Mon Feb 4 15:15:29 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 4 Feb 2019 15:15:29 +0000 Subject: RFR : 8218276: AIX build fails in tieredThresholdPolicy.cpp In-Reply-To: <0b88bd1f-c9a4-6599-0498-3bba00fa180c@oracle.com> References: <0b88bd1f-c9a4-6599-0498-3bba00fa180c@oracle.com> Message-ID: Hi David / Martin , thanks for the reviews . > > but I'm puzzled why we don't see a problem elsewhere, even with PCH > disabled ... > I was surprised too that we got an error in this compilation unit. Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Montag, 4. Februar 2019 13:30 > To: Doerr, Martin ; Baesken, Matthias > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: RFR : 8218276: AIX build fails in tieredThresholdPolicy.cpp > > +1 > > but I'm puzzled why we don't see a problem elsewhere, even with PCH > disabled ... > > Thanks, > David > > On 4/02/2019 9:57 pm, Doerr, Martin wrote: > > Hi Matthias, > > > > looks good and trivial. > > > > Thanks for fixing. > > Martin > > > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of Baesken, Matthias > > Sent: Montag, 4. Februar 2019 12:28 > > To: 'hotspot-dev at openjdk.java.net' > > Subject: RFR : 8218276: AIX build fails in tieredThresholdPolicy.cpp > > > > Hello, please review this small build fix for AIX . > > > > Currently the AIX builds for jdk/jdk fail with : > > > > > "/rs6000_64/nightly/jdk/src/hotspot/share/runtime/tieredThresholdPolicy.c > pp", > > line 481.23: 1540-0129 (S) The qualifier "SafepointSynchronize" is not > defined in the current scope. > > > "/rs6000_64/nightly/jdk/src/hotspot/share/runtime/tieredThresholdPolicy.c > pp", > > line 506.23: 1540-0129 (S) The qualifier "SafepointSynchronize" is not > defined in the current scope. > > > > Seems we miss an inclusions. > > > > > > Webrev and bug : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218276.0/ > > > > https://bugs.openjdk.java.net/browse/JDK-8218276 > > > > > > Best regards, Matthias > > From coleen.phillimore at oracle.com Mon Feb 4 15:18:55 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 10:18:55 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> Message-ID: <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8139551 The links. Thanks, Coleen On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: > Summary: Walk code cache and deoptimize once per redefinition.* > > *This change touches the AOT and code cache code.? I tried to describe > it in the comments in the RFE.? Basically, for redefinition, we walk > the code cache per class redefined in order to find evol_method > dependencies, then deoptimize if we find them, and then walk the code > cache again to mark the deoptimized nmethods as not_entrant. > > I replaced this with only marking any nmethods for the class's methods > to deoptimize (following InstanceKlass::_methods), also marking aot > methods dependent on the class, and then doing the code cache walk to > follow the evol_method dependencies at the end of redefinition for all > the classes.?? The new code uses the Method::is_old() flag rather than > comparing each method in the InstanceKlass.? Then deoptimization and > marking not_entrant is done once at the end of the redefinition as well. > > Tested with tier1-6, all the redefinition tests locally: > > make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out > make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out > make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests > >&redefine.out > make test TEST=open/test/jdk/java/lang/instrument >&instrument.out > > new test, and JMH test (see CR for results). > > Thanks, > Coleen > > From karen.kinnear at oracle.com Mon Feb 4 16:53:17 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 4 Feb 2019 11:53:17 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: References: Message-ID: <91C357F2-1E1F-4813-9AF2-7B7B7E45E1F3@oracle.com> Lois, Code looks good. Couple of minor questions.comments 1. rewriter.hpp: comment line 162 needs updating - we just use 1 entry now 2. jvmciCompilerToVM.cpp You removed an assertion about method_type_if_resolved. Would it make sense to add an assertion that !has_local_sig - which if I am reading this correctly, you are setting to indicate sig-poly methods? Does jvmci use the method_type field? Or was removing this assertion the only change needed? 3. ciStreams.cpp comment line 367: ?There is are? -> ?There are? 4. ciStreams.cpp line 336 sets local_signature Would it make sense to only do that inside the check for if (has_local_signature()) - e.g. after line 393? 5. Testing - the comments in ciStreams.cpp get_method are very helpful Are there existing tests for these cases or do we need any new ones? thanks, Karen > On Feb 4, 2019, at 7:32 AM, Lois Foltan wrote: > > Please review this change that removes the unused method_type field associated with the appendix field of an indy or method handle call. This is the first of a series of changes working towards JDK-8210685: Bootstrap method consolidation. > > open webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ > bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 > co-contributors: Lois Foltan & John Rose > > Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux only), JCK vm & lang (linux only) > > Thanks, > Lois From igor.ignatyev at oracle.com Mon Feb 4 17:37:04 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 4 Feb 2019 09:37:04 -0800 Subject: RFR(S) [12] : 8218197 : [failurehandler] parent processes shouldn't be killed till their children are handle In-Reply-To: References: Message-ID: A friendly reminder. -- Igor > On Feb 1, 2019, at 8:58 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html >> 25 lines changed: 8 ins; 2 del; 15 mod; > > Hi all, > > could you please review this small fix for timeout handler? > after 8205687[1], we start to kill a process to get a core dump. since we gather info from the parent process before its children and killing a parent can kill children, we started to observer suspiciously disappeared children processes (8176214[2], 8217170[3]). the patch changes the order we gather information, so we never kill a process till we gather from all its children. the other part of the patch fixes html-output. > > [1] https://bugs.openjdk.java.net/browse/JDK-8205687 > [2] https://bugs.openjdk.java.net/browse/JDK-8176214 > [3] https://bugs.openjdk.java.net/browse/JDK-8217170 > > webrev: http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8218197 > testing: manually verified reports generated for all time-outing multi-processed test on linux, windows, solaris and mac. > > Thanks, > -- Igor > > From lois.foltan at oracle.com Mon Feb 4 18:45:29 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 4 Feb 2019 13:45:29 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: <91C357F2-1E1F-4813-9AF2-7B7B7E45E1F3@oracle.com> References: <91C357F2-1E1F-4813-9AF2-7B7B7E45E1F3@oracle.com> Message-ID: On 2/4/2019 11:53 AM, Karen Kinnear wrote: > Lois, > > Code looks good. Couple of minor questions.comments Thank you Karen for the review!? Addressed all your comments below please see additional responses.? Updated webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/ Rerunning hs-tier1-3 & jdk-tier1-3 testing. > > 1. rewriter.hpp: comment line 162 needs updating - we just use 1 entry now Fixed the comment and also renamed the method from "add_invokedynamic_resolved_references_entries" to "add_invokedynamic_resolved_references_entry".? We were always only adding 1 entry even though previously that entry spanned multiple slots in the _invokedynamic_references_map. > > 2. jvmciCompilerToVM.cpp > You removed an assertion about method_type_if_resolved. > Would it make sense to add an assertion that !has_local_sig - which if I am reading this correctly, > you are setting to indicate sig-poly methods? Added. > > Does jvmci use the method_type field? Or was removing this assertion the only change needed? This was the only instance of the use.? However, I have sent email to Dean Long and cc'd Vladimir Kozlov asking for review. > > 3. ciStreams.cpp > comment line 367: ?There is are? -> ?There are? Fixed. > > 4. ciStreams.cpp > line 336 sets local_signature > Would it make sense to only do that inside the check for if (has_local_signature()) - e.g. after line 393? Fixed. > > 5. Testing - the comments in ciStreams.cpp get_method are very helpful > Are there existing tests for these cases or do we need any new ones? I did check the tests within jdk/java/lang/invoke, numerous scenarios for VH.get(), Lambda form for a method call dealing with linkStatic as the comments indicate, and tests dealing with variable arity, etc.? So I believe the cases are covered. Thanks, Lois > > thanks, > Karen > >> On Feb 4, 2019, at 7:32 AM, Lois Foltan wrote: >> >> Please review this change that removes the unused method_type field associated with the appendix field of an indy or method handle call. This is the first of a series of changes working towards JDK-8210685: Bootstrap method consolidation. >> >> open webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ >> bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 >> co-contributors: Lois Foltan & John Rose >> >> Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux only), JCK vm & lang (linux only) >> >> Thanks, >> Lois From daniel.daugherty at oracle.com Mon Feb 4 19:05:31 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 4 Feb 2019 14:05:31 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: On 2/3/19 8:46 PM, Patricio Chilano wrote: > Hi all, > > Here is v05: > > Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ src/hotspot/share/runtime/interfaceSupport.inline.hpp ??? L295: // - When transitioning in (constructor), it checks for safepoints without blocking, i.e calls ??????? nit - s/i.e /i.e., / ??????? (You missed the change from my v04 review) ??? L299: class ThreadBlockinVMWithDeadlockCheck : public ThreadStateTransition { ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, Monitor** in_flight_monitor_adr) ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ ??????? Lower case 'i' -> 'I' to match the CamelCastStyleInOtherHelpers. src/hotspot/share/runtime/mutex.cpp ??? L36: static inline void assert_owner(Thread *owner, Thread *thread) { ??????? nit - the predominant style in this file is ' * ' (space on each side of '*') ??? L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" INTPTR_FORMAT, ??????? Another possible style of mesg: ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", expect=" INTPTR_FORMAT, ??? ThreadBlockinVMWithDeadlockCheck renames to ThreadBlockInVMWithDeadlockCheck in ??? this file also. src/hotspot/share/runtime/mutex.hpp ??? No comments. src/hotspot/share/runtime/safepointMechanism.inline.hpp ??? L83: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { ??????? Did you decide this line does not need a comment at all? Dan > > Tested tiers 1-6. > > Thanks, > Patricio > > On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >> On 2/1/19 7:49 PM, David Holmes wrote: >>> >>> >>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>> good suggestion. >>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>> anything. So your suggestion of >>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement to >>>>>> me. :) >>>>> >>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>> "why" this class, vs. "what" this class does. Since the latter can >>>>> change. >>>> I like that name. Is that name okay with you David? >>> >>> Sorry no. "Lock" still adds zero information about when/why you >>> would use this. It's used within Monitor::lock and Monitor::wait so >>> is not specific to "locking" even in that class. This is about >>> blocking in the VM and we need to know what this version does >>> differently to the existing TBIVM. There are lots of different types >>> of "locking" in the VM and we don't use this with them. >>> >>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >> >> ThreadBlockInVMBecauseSneakyLockingIsEvil? >> >> ThreadBlockinVMWithDeadlockPrevention is okay. >> >> ThreadBlockinVMWithDeadlockCheck >> ThreadBlockinVMWithDeadlockChk >> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >> >> Just pick a name and run with it... :-) >> >> Dan >> >> >>> >>> David >>> ----- >>> >>> >>>> Thanks, >>>> Patricio >>>>> thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>> Hi Patricio, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>>> this, pulling together a number of ideas from different >>>>>>>>>> people to make it all work! >>>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>>>>>> >>>>>>>> :) Nothing innovative there. >>>>>>>> >>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>> >>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>> Full: >>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>> Inc: >>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>> >>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>> behaviour without having to duplicate so much of this code. >>>>>>>>>> In any case the semantics of ThreadLockBlockInVM needs to be >>>>>>>>>> described. >>>>>>>>> I could do it with one extra argument, but I would need to add >>>>>>>>> two extra branches in transition_and_fence(), one to decide if >>>>>>>>> I'm in the Monitor case to avoid calling >>>>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>>>> one to actually decide if I'm transitioning in or out, since >>>>>>>>> the actions to perform are different. I think it is easier to >>>>>>>>> read without adding new conditionals, and also we will save >>>>>>>>> those extra branches, but if you think it's better this way I >>>>>>>>> can change it. >>>>>>>> >>>>>>>> I would like something that tells me more clearly how this new >>>>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>>>> code between them and using different args would be one way. >>>>>>>> Documenting the difference in comments would be another. Your >>>>>>>> choice. >>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>> >>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>> >>>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>>> the semantics we are changing compared to TBIVM are not evident >>>>>>>> in the TBIVM name. If TBIVM was actually >>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - >>>>>>>> but perhaps that lengthy, but clear name would be okay anyway? >>>>>>> Not convinced on that name since we are blocking at safepoints >>>>>>> in the destructor. Based on the comments I added how about >>>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>> conditions for deadlocks). >>>>>>> >>>>>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>>>>> don't really convey to me what happens - what is being >>>>>>>>>> "preempted" here? I would suggest a more direct >>>>>>>>>> Monitor::release_for_safepoint >>>>>>>>> Changed. >>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not even >>>>>>>>>> sure if we need bother at all with the one logging statement >>>>>>>>>> that is present. >>>>>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>>>>> follow you with the name, isn't that how we name this >>>>>>>>> monitors? I tried to differentiate them from Java monitors. >>>>>>>>> What about just "monitor"? >>>>>>>> >>>>>>>> How about vmmonitor ? >>>>>>> Ok, changed. >>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>> >>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>> safepoint checks. >>>>>>>>>> >>>>>>>>>> The comment there should only say "not require". >>>>>>>>> Done. >>>>>>>>> >>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>> ? _lock.unlock(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>>>>> suitable assertions we should have here? >>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>> Thread::current? >>>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>>> safepoint-in-progress does not really work because _state >>>>>>>>> could change to _not_synchronized right after you checked for >>>>>>>>> it in TLBIVM. >>>>>>>> >>>>>>>> Okay. >>>>>>>> >>>>>>>>>> Nit: >>>>>>>>>> >>>>>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>>>>> INTPTR_FORMAT >>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>> p2i(Thread::current())); >>>>>>>>>> >>>>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>>>> The second line should indent to the first comma, but that >>>>>>>>>> will make the second line extend way past 80 columns. >>>>>>>>>> >>>>>>>>>> Also you could factor that assertion for >>>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>>> avoid the repetition. >>>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>>> >>>>>>>> I though it should indent to the comma because it is a >>>>>>>> continuation of the same argument being passed to the assert >>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>> >>>>>>>> Factoring it into its own little function or macro would still >>>>>>>> be good to avoid the repetition. >>>>>>> Ok, added new function assert_owned_by_self(). I could change it >>>>>>> to assert_owner(Thread*) and use it for the NULL case too >>>>>>> unifying the printed messages to something like "invalid owner: >>>>>>> owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you >>>>>>> think? >>>>>>> >>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>> Object.wait() */); >>>>>>>>>> >>>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>>> comments. >>>>>>>>> Done. >>>>>>>>> >>>>>>>>>> ??? } else { >>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>> ??? } >>>>>>>>>> >>>>>>>>>> You don't need Monitor:: here >>>>>>>>> Removed. >>>>>>>>> >>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just >>>>>>>>>> be a PlatformMonitor now. >>>>>>>>>> >>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>> retained. Not clear if we need to set the _owner field or can >>>>>>>>>> just skip it. >>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>> >>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>> lock_without_safepoint_check() >>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>> // >>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>> interoperate properly with the native >>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>> >>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>> >>>>>>>>> >>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>> wouldn't hurt. >>>>>>>> >>>>>>>> It's useful for checking usage errors, but we won't have that >>>>>>>> if we replace with PlatformMonitor, so may as well drop it now >>>>>>>> IMO. >>>>>>> Ok, I added asserts that _owner should be NULL after acquiring >>>>>>> it and before releasing it though. >>>>>>> >>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>> destructor being called? >>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>> >>>>>>>> No need - assume other people have a better understanding of >>>>>>>> C++ than I do :) >>>>>>> >>>>>>> Below is version v04, which also contains a correction pointed >>>>>>> out off-list by Robbin to do a local poll first in >>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>> local polls. Since the thread local poll is armed after changing >>>>>>> _state to _synchronizing, if we only do a global poll in the >>>>>>> TLBIVM constructor we could detect there is a safepoint in >>>>>>> progress and callback but when coming back in the destructor >>>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>>> safepoint in progress since that method checks first for local >>>>>>> polls. >>>>>>> >>>>>>> >>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Patricio >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for looking into this! Waiting on your comments to send >>>>>>>>> v04. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Patricio >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> > From lois.foltan at oracle.com Mon Feb 4 19:18:06 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 4 Feb 2019 14:18:06 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: References: <91C357F2-1E1F-4813-9AF2-7B7B7E45E1F3@oracle.com> Message-ID: <9866b03b-5560-69c3-5503-985840953ae1@oracle.com> On 2/4/2019 1:45 PM, Lois Foltan wrote: > On 2/4/2019 11:53 AM, Karen Kinnear wrote: >> Lois, >> >> Code looks good. Couple of minor questions.comments > Thank you Karen for the review!? Addressed all your comments below > please see additional responses.? Updated webrev at: > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/ > > Rerunning hs-tier1-3 & jdk-tier1-3 testing. > >> >> 1. rewriter.hpp: comment line 162 needs updating - we just use 1 >> entry now > Fixed the comment and also renamed the method from > "add_invokedynamic_resolved_references_entries" to > "add_invokedynamic_resolved_references_entry".? We were always only > adding 1 entry even though previously that entry spanned multiple > slots in the _invokedynamic_references_map. > >> >> 2. jvmciCompilerToVM.cpp >> You removed an assertion about method_type_if_resolved. >> Would it make sense to add an assertion that !has_local_sig - which >> if I am reading this correctly, >> you are setting to indicate sig-poly methods? > Added. Clarification on webrev .2 above, it does not contain the addition of the assertion as I indicated in my response.? The original assertion was not simply about whether a method_type was present or not.? It was about either the method_type is not present or the method_type is present and has not yet been resolved.? So a replacement of that vmassert with a call to has_local_signature does not equate and numerous compiler/aot tests were failing when I retested. Thanks, Lois > >> >> Does jvmci use the method_type field?? Or was removing this assertion >> the only change needed? > This was the only instance of the use.? However, I have sent email to > Dean Long and cc'd Vladimir Kozlov asking for review. > >> >> 3. ciStreams.cpp >> comment line 367: ?There is are? -> ?There are? > Fixed. > >> >> 4. ciStreams.cpp >> line 336 sets local_signature >> Would it make sense to only do that inside the check for if >> (has_local_signature()) - e.g. after line 393? > Fixed. > >> >> 5. Testing - the comments in ciStreams.cpp get_method are very helpful >> Are there existing tests for these cases or do we need any new ones? > I did check the tests within jdk/java/lang/invoke, numerous scenarios > for VH.get(), Lambda form for a method call dealing with linkStatic as > the comments indicate, and tests dealing with variable arity, etc.? So > I believe the cases are covered. > > Thanks, > Lois > >> >> thanks, >> Karen >> >>> On Feb 4, 2019, at 7:32 AM, Lois Foltan wrote: >>> >>> Please review this change that removes the unused method_type field >>> associated with the appendix field of an indy or method handle >>> call.? This is the first of a series of changes working towards >>> JDK-8210685: Bootstrap method consolidation. >>> >>> open webrev at: >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ >>> bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 >>> co-contributors: Lois Foltan & John Rose >>> >>> Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux >>> only), JCK vm & lang (linux only) >>> >>> Thanks, >>> Lois > From patricio.chilano.mateo at oracle.com Mon Feb 4 19:40:50 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Mon, 4 Feb 2019 14:40:50 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> Message-ID: <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> Hi Dan, On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: > On 2/3/19 8:46 PM, Patricio Chilano wrote: >> Hi all, >> >> Here is v05: >> >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > ??? L295: // - When transitioning in (constructor), it checks for > safepoints without blocking, i.e calls > ??????? nit - s/i.e /i.e., / > ??????? (You missed the change from my v04 review) Done! I did made the change s/having to block/blocking from your review but didn't see the extra comma you added after i.e. > L299: class ThreadBlockinVMWithDeadlockCheck : public > ThreadStateTransition { > ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, > Monitor** in_flight_monitor_adr) > ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { > s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ > ??????? Lower case 'i' -> 'I' to match the CamelCastStyleInOtherHelpers. Done. > src/hotspot/share/runtime/mutex.cpp > ??? L36: static inline void assert_owner(Thread *owner, Thread *thread) { > ??????? nit - the predominant style in this file is ' * ' (space on > each side of '*') Ok, is that the style that we are supposed to follow in general ? Otherwise I can change all the ones that do not match the preferred style. > L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" > INTPTR_FORMAT, > ??????? Another possible style of mesg: > ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", expect=" > INTPTR_FORMAT, I like more the first style, but if you really prefer the second one I can change it. > ThreadBlockinVMWithDeadlockCheck renames to > ThreadBlockInVMWithDeadlockCheck in > ??? this file also. Done. > src/hotspot/share/runtime/mutex.hpp > ??? No comments. > > src/hotspot/share/runtime/safepointMechanism.inline.hpp > ??? L83: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { > ??????? Did you decide this line does not need a comment at all? How about adding the following comment based on your previous email: // If using thread local polls, we should not check the // global_poll() and callback via block() if the VMThread // has not yet armed the local poll. Otherwise, when used in // combination with should_block(), the latter could miss // detecting the same safepoint that this method would detect // if only checking global polls. Patricio > Dan > > >> >> Tested tiers 1-6. >> >> Thanks, >> Patricio >> >> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>> On 2/1/19 7:49 PM, David Holmes wrote: >>>> >>>> >>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>>> good suggestion. >>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>>> anything. So your suggestion of >>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement to >>>>>>> me. :) >>>>>> >>>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>>> "why" this class, vs. "what" this class does. Since the latter >>>>>> can change. >>>>> I like that name. Is that name okay with you David? >>>> >>>> Sorry no. "Lock" still adds zero information about when/why you >>>> would use this. It's used within Monitor::lock and Monitor::wait so >>>> is not specific to "locking" even in that class. This is about >>>> blocking in the VM and we need to know what this version does >>>> differently to the existing TBIVM. There are lots of different >>>> types of "locking" in the VM and we don't use this with them. >>>> >>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>> >>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>> >>> ThreadBlockinVMWithDeadlockPrevention is okay. >>> >>> ThreadBlockinVMWithDeadlockCheck >>> ThreadBlockinVMWithDeadlockChk >>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>> >>> Just pick a name and run with it... :-) >>> >>> Dan >>> >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, >>>>> Patricio >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>> Hi Patricio, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>>>> this, pulling together a number of ideas from different >>>>>>>>>>> people to make it all work! >>>>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation? >>>>>>>>>> : ) >>>>>>>>> >>>>>>>>> :) Nothing innovative there. >>>>>>>>> >>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>> >>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>> Full: >>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>> Inc: >>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>> >>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>> behaviour without having to duplicate so much of this code. >>>>>>>>>>> In any case the semantics of ThreadLockBlockInVM needs to be >>>>>>>>>>> described. >>>>>>>>>> I could do it with one extra argument, but I would need to >>>>>>>>>> add two extra branches in transition_and_fence(), one to >>>>>>>>>> decide if I'm in the Monitor case to avoid calling >>>>>>>>>> SafepointMechanism::block_if_requested() directly and another >>>>>>>>>> one to actually decide if I'm transitioning in or out, since >>>>>>>>>> the actions to perform are different. I think it is easier to >>>>>>>>>> read without adding new conditionals, and also we will save >>>>>>>>>> those extra branches, but if you think it's better this way I >>>>>>>>>> can change it. >>>>>>>>> >>>>>>>>> I would like something that tells me more clearly how this new >>>>>>>>> transition helper differs from the existing TBIVM. Sharing the >>>>>>>>> code between them and using different args would be one way. >>>>>>>>> Documenting the difference in comments would be another. Your >>>>>>>>> choice. >>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>> >>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>> >>>>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>>>> the semantics we are changing compared to TBIVM are not >>>>>>>>> evident in the TBIVM name. If TBIVM was actually >>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - >>>>>>>>> but perhaps that lengthy, but clear name would be okay anyway? >>>>>>>> Not convinced on that name since we are blocking at safepoints >>>>>>>> in the destructor. Based on the comments I added how about >>>>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>> conditions for deadlocks). >>>>>>>> >>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>> preempt_by_safepoint don't really convey to me what happens >>>>>>>>>>> - what is being "preempted" here? I would suggest a more >>>>>>>>>>> direct Monitor::release_for_safepoint >>>>>>>>>> Changed. >>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not even >>>>>>>>>>> sure if we need bother at all with the one logging statement >>>>>>>>>>> that is present. >>>>>>>>>> I added it to eventually track unbounded try locks. Not sure >>>>>>>>>> I follow you with the name, isn't that how we name this >>>>>>>>>> monitors? I tried to differentiate them from Java monitors. >>>>>>>>>> What about just "monitor"? >>>>>>>>> >>>>>>>>> How about vmmonitor ? >>>>>>>> Ok, changed. >>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>> >>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>> safepoint checks. >>>>>>>>>>> >>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>> Done. >>>>>>>>>> >>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Apart from renaming this as suggested above, aren't there >>>>>>>>>>> any suitable assertions we should have here? >>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>>> Thread::current? >>>>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>>>> safepoint-in-progress does not really work because _state >>>>>>>>>> could change to _not_synchronized right after you checked for >>>>>>>>>> it in TLBIVM. >>>>>>>>> >>>>>>>>> Okay. >>>>>>>>> >>>>>>>>>>> Nit: >>>>>>>>>>> >>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>> >>>>>>>>>>> with Dan's enhanced assertions there's an indentation issue. >>>>>>>>>>> The second line should indent to the first comma, but that >>>>>>>>>>> will make the second line extend way past 80 columns. >>>>>>>>>>> >>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>>>> avoid the repetition. >>>>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>>>> >>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>> continuation of the same argument being passed to the assert >>>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>>> >>>>>>>>> Factoring it into its own little function or macro would still >>>>>>>>> be good to avoid the repetition. >>>>>>>> Ok, added new function assert_owned_by_self(). I could change >>>>>>>> it to assert_owner(Thread*) and use it for the NULL case too >>>>>>>> unifying the printed messages to something like "invalid owner: >>>>>>>> owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you >>>>>>>> think? >>>>>>>> >>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>> Object.wait() */); >>>>>>>>>>> >>>>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>>>> comments. >>>>>>>>>> Done. >>>>>>>>>> >>>>>>>>>>> ??? } else { >>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>> ??? } >>>>>>>>>>> >>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>> Removed. >>>>>>>>>> >>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just >>>>>>>>>>> be a PlatformMonitor now. >>>>>>>>>>> >>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>> retained. Not clear if we need to set the _owner field or >>>>>>>>>>> can just skip it. >>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>> >>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>> // >>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>> interoperate properly with the native >>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>> >>>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>> wouldn't hurt. >>>>>>>>> >>>>>>>>> It's useful for checking usage errors, but we won't have that >>>>>>>>> if we replace with PlatformMonitor, so may as well drop it now >>>>>>>>> IMO. >>>>>>>> Ok, I added asserts that _owner should be NULL after acquiring >>>>>>>> it and before releasing it though. >>>>>>>> >>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>> destructor being called? >>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>> >>>>>>>>> No need - assume other people have a better understanding of >>>>>>>>> C++ than I do :) >>>>>>>> >>>>>>>> Below is version v04, which also contains a correction pointed >>>>>>>> out off-list by Robbin to do a local poll first in >>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>> changing _state to _synchronizing, if we only do a global poll >>>>>>>> in the TLBIVM constructor we could detect there is a safepoint >>>>>>>> in progress and callback but when coming back in the destructor >>>>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>>>> safepoint in progress since that method checks first for local >>>>>>>> polls. >>>>>>>> >>>>>>>> >>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Patricio >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>> send v04. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Patricio >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> > From daniel.daugherty at oracle.com Mon Feb 4 19:47:21 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 4 Feb 2019 14:47:21 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> Message-ID: <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> On 2/4/19 2:40 PM, Patricio Chilano wrote: > Hi Dan, > > On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>> Hi all, >>> >>> Here is v05: >>> >>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >> >> src/hotspot/share/runtime/interfaceSupport.inline.hpp >> ??? L295: // - When transitioning in (constructor), it checks for >> safepoints without blocking, i.e calls >> ??????? nit - s/i.e /i.e., / >> ??????? (You missed the change from my v04 review) > Done! I did made the change s/having to block/blocking from your > review but didn't see the extra comma you added after i.e. Extra period and extra comma... I'm a font/typography nut... :-) > >> L299: class ThreadBlockinVMWithDeadlockCheck : public >> ThreadStateTransition { >> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >> Monitor** in_flight_monitor_adr) >> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >> ??????? Lower case 'i' -> 'I' to match the CamelCastStyleInOtherHelpers. > Done. > >> src/hotspot/share/runtime/mutex.cpp >> ??? L36: static inline void assert_owner(Thread *owner, Thread >> *thread) { >> ??????? nit - the predominant style in this file is ' * ' (space on >> each side of '*') > Ok, is that the style that we are supposed to follow in general ? > Otherwise I can change all the ones that do not match the preferred > style. That's a good question. The general rule is to follow the predominant style in the file. However, I'm not sure what the HotSpot recommended style is (I used to know this...). > >> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" >> INTPTR_FORMAT, >> ??????? Another possible style of mesg: >> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", expect=" >> INTPTR_FORMAT, > I like more the first style, but if you really prefer the second one I > can change it. I'm okay with what you have. > >> ThreadBlockinVMWithDeadlockCheck renames to >> ThreadBlockInVMWithDeadlockCheck in >> ??? this file also. > Done. > >> src/hotspot/share/runtime/mutex.hpp >> ??? No comments. >> >> src/hotspot/share/runtime/safepointMechanism.inline.hpp >> ??? L83: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { >> ??????? Did you decide this line does not need a comment at all? > How about adding the following comment based on your previous email: > > // If using thread local polls, we should not check the > // global_poll() and callback via block() if the VMThread > // has not yet armed the local poll. Otherwise, when used in > // combination with should_block(), the latter could miss > // detecting the same safepoint that this method would detect > // if only checking global polls. I'm good with that comment. Dan > > > Patricio >> Dan >> >> >>> >>> Tested tiers 1-6. >>> >>> Thanks, >>> Patricio >>> >>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>> >>>>> >>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>>>> good suggestion. >>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>>>> anything. So your suggestion of >>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement >>>>>>>> to me. :) >>>>>>> >>>>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>>>> "why" this class, vs. "what" this class does. Since the latter >>>>>>> can change. >>>>>> I like that name. Is that name okay with you David? >>>>> >>>>> Sorry no. "Lock" still adds zero information about when/why you >>>>> would use this. It's used within Monitor::lock and Monitor::wait >>>>> so is not specific to "locking" even in that class. This is about >>>>> blocking in the VM and we need to know what this version does >>>>> differently to the existing TBIVM. There are lots of different >>>>> types of "locking" in the VM and we don't use this with them. >>>>> >>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>>> >>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>> >>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>> >>>> ThreadBlockinVMWithDeadlockCheck >>>> ThreadBlockinVMWithDeadlockChk >>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>> >>>> Just pick a name and run with it... :-) >>>> >>>> Dan >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>>> thanks, >>>>>>> Coleen >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> First, thanks for all the many weeks of work you've put >>>>>>>>>>>> into this, pulling together a number of ideas from >>>>>>>>>>>> different people to make it all work! >>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>> implementation? : ) >>>>>>>>>> >>>>>>>>>> :) Nothing innovative there. >>>>>>>>>> >>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>> >>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>> Full: >>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>> Inc: >>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>> >>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>> behaviour without having to duplicate so much of this code. >>>>>>>>>>>> In any case the semantics of ThreadLockBlockInVM needs to >>>>>>>>>>>> be described. >>>>>>>>>>> I could do it with one extra argument, but I would need to >>>>>>>>>>> add two extra branches in transition_and_fence(), one to >>>>>>>>>>> decide if I'm in the Monitor case to avoid calling >>>>>>>>>>> SafepointMechanism::block_if_requested() directly and >>>>>>>>>>> another one to actually decide if I'm transitioning in or >>>>>>>>>>> out, since the actions to perform are different. I think it >>>>>>>>>>> is easier to read without adding new conditionals, and also >>>>>>>>>>> we will save those extra branches, but if you think it's >>>>>>>>>>> better this way I can change it. >>>>>>>>>> >>>>>>>>>> I would like something that tells me more clearly how this >>>>>>>>>> new transition helper differs from the existing TBIVM. >>>>>>>>>> Sharing the code between them and using different args would >>>>>>>>>> be one way. Documenting the difference in comments would be >>>>>>>>>> another. Your choice. >>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>> >>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>> >>>>>>>>>> That's not quite conveying the semantics. The problem is that >>>>>>>>>> the semantics we are changing compared to TBIVM are not >>>>>>>>>> evident in the TBIVM name. If TBIVM was actually >>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>> transition would obviously be >>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps that >>>>>>>>>> lengthy, but clear name would be okay anyway? >>>>>>>>> Not convinced on that name since we are blocking at safepoints >>>>>>>>> in the destructor. Based on the comments I added how about >>>>>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>> conditions for deadlocks). >>>>>>>>> >>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>> preempt_by_safepoint don't really convey to me what happens >>>>>>>>>>>> - what is being "preempted" here? I would suggest a more >>>>>>>>>>>> direct Monitor::release_for_safepoint >>>>>>>>>>> Changed. >>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not >>>>>>>>>>>> even sure if we need bother at all with the one logging >>>>>>>>>>>> statement that is present. >>>>>>>>>>> I added it to eventually track unbounded try locks. Not sure >>>>>>>>>>> I follow you with the name, isn't that how we name this >>>>>>>>>>> monitors? I tried to differentiate them from Java monitors. >>>>>>>>>>> What about just "monitor"? >>>>>>>>>> >>>>>>>>>> How about vmmonitor ? >>>>>>>>> Ok, changed. >>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>> >>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>> safepoint checks. >>>>>>>>>>>> >>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>> Done. >>>>>>>>>>> >>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Apart from renaming this as suggested above, aren't there >>>>>>>>>>>> any suitable assertions we should have here? >>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>>>> Thread::current? >>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>> Asserting safepoint-in-progress does not really work because >>>>>>>>>>> _state could change to _not_synchronized right after you >>>>>>>>>>> checked for it in TLBIVM. >>>>>>>>>> >>>>>>>>>> Okay. >>>>>>>>>> >>>>>>>>>>>> Nit: >>>>>>>>>>>> >>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>>> >>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>> issue. The second line should indent to the first comma, >>>>>>>>>>>> but that will make the second line extend way past 80 columns. >>>>>>>>>>>> >>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>> _owner==Thread::current() into its own function or macro to >>>>>>>>>>>> avoid the repetition. >>>>>>>>>>> Corrected indentation based on Dan's reply to align with >>>>>>>>>>> _owner. >>>>>>>>>> >>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>> continuation of the same argument being passed to the assert >>>>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>>>> >>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>> still be good to avoid the repetition. >>>>>>>>> Ok, added new function assert_owned_by_self(). I could change >>>>>>>>> it to assert_owner(Thread*) and use it for the NULL case too >>>>>>>>> unifying the printed messages to something like "invalid >>>>>>>>> owner: owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>> >>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>> Dan's comments. >>>>>>>>>>> Done. >>>>>>>>>>> >>>>>>>>>>>> ??? } else { >>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>> ??? } >>>>>>>>>>>> >>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>> Removed. >>>>>>>>>>> >>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can >>>>>>>>>>>> just be a PlatformMonitor now. >>>>>>>>>>>> >>>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>>> retained. Not clear if we need to set the _owner field or >>>>>>>>>>>> can just skip it. >>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>> >>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>>> // >>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>> interoperate properly with the native >>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>> >>>>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>> wouldn't hurt. >>>>>>>>>> >>>>>>>>>> It's useful for checking usage errors, but we won't have that >>>>>>>>>> if we replace with PlatformMonitor, so may as well drop it >>>>>>>>>> now IMO. >>>>>>>>> Ok, I added asserts that _owner should be NULL after acquiring >>>>>>>>> it and before releasing it though. >>>>>>>>> >>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>> destructor being called? >>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>> >>>>>>>>>> No need - assume other people have a better understanding of >>>>>>>>>> C++ than I do :) >>>>>>>>> >>>>>>>>> Below is version v04, which also contains a correction pointed >>>>>>>>> out off-list by Robbin to do a local poll first in >>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>>> changing _state to _synchronizing, if we only do a global poll >>>>>>>>> in the TLBIVM constructor we could detect there is a safepoint >>>>>>>>> in progress and callback but when coming back in the >>>>>>>>> destructor SafepointMechanism::should_block() could miss >>>>>>>>> detecting the safepoint in progress since that method checks >>>>>>>>> first for local polls. >>>>>>>>> >>>>>>>>> >>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Patricio >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>>> send v04. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Patricio >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Mon Feb 4 20:34:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 12:34:21 -0800 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> Message-ID: <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> Added the serviceability-dev back. Thanks, Serguei On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8139551 > > The links. > Thanks, > Coleen > > On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >> Summary: Walk code cache and deoptimize once per redefinition.* >> >> *This change touches the AOT and code cache code.? I tried to >> describe it in the comments in the RFE.? Basically, for redefinition, >> we walk the code cache per class redefined in order to find >> evol_method dependencies, then deoptimize if we find them, and then >> walk the code cache again to mark the deoptimized nmethods as >> not_entrant. >> >> I replaced this with only marking any nmethods for the class's >> methods to deoptimize (following InstanceKlass::_methods), also >> marking aot methods dependent on the class, and then doing the code >> cache walk to follow the evol_method dependencies at the end of >> redefinition for all the classes.?? The new code uses the >> Method::is_old() flag rather than comparing each method in the >> InstanceKlass.? Then deoptimization and marking not_entrant is done >> once at the end of the redefinition as well. >> >> Tested with tier1-6, all the redefinition tests locally: >> >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >> >&redefine.out >> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >> >> new test, and JMH test (see CR for results). >> >> Thanks, >> Coleen >> >> > From karen.kinnear at oracle.com Mon Feb 4 20:57:59 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 4 Feb 2019 15:57:59 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: <9866b03b-5560-69c3-5503-985840953ae1@oracle.com> References: <91C357F2-1E1F-4813-9AF2-7B7B7E45E1F3@oracle.com> <9866b03b-5560-69c3-5503-985840953ae1@oracle.com> Message-ID: <7B6992D4-ECD3-4807-A002-C80F004CE1B9@oracle.com> Lois, Apologies for my suggestion which caused you extra work - I did not read it carefully enough. Thank you for the careful testing. I don?t need to see a new webrev. thanks, Karen > On Feb 4, 2019, at 2:18 PM, Lois Foltan wrote: > > On 2/4/2019 1:45 PM, Lois Foltan wrote: >> On 2/4/2019 11:53 AM, Karen Kinnear wrote: >>> Lois, >>> >>> Code looks good. Couple of minor questions.comments >> Thank you Karen for the review! Addressed all your comments below please see additional responses. Updated webrev at: >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/ >> >> Rerunning hs-tier1-3 & jdk-tier1-3 testing. >> >>> >>> 1. rewriter.hpp: comment line 162 needs updating - we just use 1 entry now >> Fixed the comment and also renamed the method from "add_invokedynamic_resolved_references_entries" to "add_invokedynamic_resolved_references_entry". We were always only adding 1 entry even though previously that entry spanned multiple slots in the _invokedynamic_references_map. >> >>> >>> 2. jvmciCompilerToVM.cpp >>> You removed an assertion about method_type_if_resolved. >>> Would it make sense to add an assertion that !has_local_sig - which if I am reading this correctly, >>> you are setting to indicate sig-poly methods? >> Added. > Clarification on webrev .2 above, it does not contain the addition of the assertion as I indicated in my response. The original assertion was not simply about whether a method_type was present or not. It was about either the method_type is not present or the method_type is present and has not yet been resolved. So a replacement of that vmassert with a call to has_local_signature does not equate and numerous compiler/aot tests were failing when I retested. > > Thanks, > Lois > >> >>> >>> Does jvmci use the method_type field? Or was removing this assertion the only change needed? >> This was the only instance of the use. However, I have sent email to Dean Long and cc'd Vladimir Kozlov asking for review. >> >>> >>> 3. ciStreams.cpp >>> comment line 367: ?There is are? -> ?There are? >> Fixed. >> >>> >>> 4. ciStreams.cpp >>> line 336 sets local_signature >>> Would it make sense to only do that inside the check for if (has_local_signature()) - e.g. after line 393? >> Fixed. >> >>> >>> 5. Testing - the comments in ciStreams.cpp get_method are very helpful >>> Are there existing tests for these cases or do we need any new ones? >> I did check the tests within jdk/java/lang/invoke, numerous scenarios for VH.get(), Lambda form for a method call dealing with linkStatic as the comments indicate, and tests dealing with variable arity, etc. So I believe the cases are covered. >> >> Thanks, >> Lois >> >>> >>> thanks, >>> Karen >>> >>>> On Feb 4, 2019, at 7:32 AM, Lois Foltan wrote: >>>> >>>> Please review this change that removes the unused method_type field associated with the appendix field of an indy or method handle call. This is the first of a series of changes working towards JDK-8210685: Bootstrap method consolidation. >>>> >>>> open webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ >>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 >>>> co-contributors: Lois Foltan & John Rose >>>> >>>> Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux only), JCK vm & lang (linux only) >>>> >>>> Thanks, >>>> Lois >> > From patricio.chilano.mateo at oracle.com Mon Feb 4 20:57:48 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Mon, 4 Feb 2019 15:57:48 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> Message-ID: <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> Hi Dan, Here is v06. It also contains David's suggested changes for assert_owner(), and based on your correction about declaring pointers I fixed one in ThreadBlockInVMWithDeadlockCheck declaration. Files mutex.cpp and mutex.hpp have different styles of "pointer to" declarations so except the one you mentioned I didn't try to fix them all since I don't know if changing all of them to " * " is the right approach. Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ Thanks, Patricio On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: > On 2/4/19 2:40 PM, Patricio Chilano wrote: >> Hi Dan, >> >> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>> Hi all, >>>> >>>> Here is v05: >>>> >>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>> >>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>> ??? L295: // - When transitioning in (constructor), it checks for >>> safepoints without blocking, i.e calls >>> ??????? nit - s/i.e /i.e., / >>> ??????? (You missed the change from my v04 review) >> Done! I did made the change s/having to block/blocking from your >> review but didn't see the extra comma you added after i.e. > > Extra period and extra comma... I'm a font/typography nut... :-) > > >> >>> L299: class ThreadBlockinVMWithDeadlockCheck : public >>> ThreadStateTransition { >>> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >>> Monitor** in_flight_monitor_adr) >>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>> ??????? Lower case 'i' -> 'I' to match the >>> CamelCastStyleInOtherHelpers. >> Done. >> >>> src/hotspot/share/runtime/mutex.cpp >>> ??? L36: static inline void assert_owner(Thread *owner, Thread >>> *thread) { >>> ??????? nit - the predominant style in this file is ' * ' (space on >>> each side of '*') >> Ok, is that the style that we are supposed to follow in general ? >> Otherwise I can change all the ones that do not match the preferred >> style. > > That's a good question. The general rule is to follow the > predominant style in the file. However, I'm not sure what > the HotSpot recommended style is (I used to know this...). > > >> >>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" >>> INTPTR_FORMAT, >>> ??????? Another possible style of mesg: >>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", expect=" >>> INTPTR_FORMAT, >> I like more the first style, but if you really prefer the second one >> I can change it. > > I'm okay with what you have. > > >> >>> ThreadBlockinVMWithDeadlockCheck renames to >>> ThreadBlockInVMWithDeadlockCheck in >>> ??? this file also. >> Done. >> >>> src/hotspot/share/runtime/mutex.hpp >>> ??? No comments. >>> >>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>> ??? L83: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { >>> ??????? Did you decide this line does not need a comment at all? >> How about adding the following comment based on your previous email: >> >> // If using thread local polls, we should not check the >> // global_poll() and callback via block() if the VMThread >> // has not yet armed the local poll. Otherwise, when used in >> // combination with should_block(), the latter could miss >> // detecting the same safepoint that this method would detect >> // if only checking global polls. > > I'm good with that comment. > > Dan > > >> >> >> Patricio >>> Dan >>> >>> >>>> >>>> Tested tiers 1-6. >>>> >>>> Thanks, >>>> Patricio >>>> >>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>> >>>>>> >>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>>>>> good suggestion. >>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>>>>> anything. So your suggestion of >>>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement >>>>>>>>> to me. :) >>>>>>>> >>>>>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>>>>> "why" this class, vs. "what" this class does. Since the latter >>>>>>>> can change. >>>>>>> I like that name. Is that name okay with you David? >>>>>> >>>>>> Sorry no. "Lock" still adds zero information about when/why you >>>>>> would use this. It's used within Monitor::lock and Monitor::wait >>>>>> so is not specific to "locking" even in that class. This is about >>>>>> blocking in the VM and we need to know what this version does >>>>>> differently to the existing TBIVM. There are lots of different >>>>>> types of "locking" in the VM and we don't use this with them. >>>>>> >>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>>>> >>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>> >>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>> >>>>> ThreadBlockinVMWithDeadlockCheck >>>>> ThreadBlockinVMWithDeadlockChk >>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>> >>>>> Just pick a name and run with it... :-) >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> Patricio >>>>>>>> thanks, >>>>>>>> Coleen >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> First, thanks for all the many weeks of work you've put >>>>>>>>>>>>> into this, pulling together a number of ideas from >>>>>>>>>>>>> different people to make it all work! >>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>>> implementation? : ) >>>>>>>>>>> >>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>> >>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>> >>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>> Full: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>> >>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>>> behaviour without having to duplicate so much of this >>>>>>>>>>>>> code. In any case the semantics of ThreadLockBlockInVM >>>>>>>>>>>>> needs to be described. >>>>>>>>>>>> I could do it with one extra argument, but I would need to >>>>>>>>>>>> add two extra branches in transition_and_fence(), one to >>>>>>>>>>>> decide if I'm in the Monitor case to avoid calling >>>>>>>>>>>> SafepointMechanism::block_if_requested() directly and >>>>>>>>>>>> another one to actually decide if I'm transitioning in or >>>>>>>>>>>> out, since the actions to perform are different. I think it >>>>>>>>>>>> is easier to read without adding new conditionals, and also >>>>>>>>>>>> we will save those extra branches, but if you think it's >>>>>>>>>>>> better this way I can change it. >>>>>>>>>>> >>>>>>>>>>> I would like something that tells me more clearly how this >>>>>>>>>>> new transition helper differs from the existing TBIVM. >>>>>>>>>>> Sharing the code between them and using different args would >>>>>>>>>>> be one way. Documenting the difference in comments would be >>>>>>>>>>> another. Your choice. >>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>> >>>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>> >>>>>>>>>>> That's not quite conveying the semantics. The problem is >>>>>>>>>>> that the semantics we are changing compared to TBIVM are not >>>>>>>>>>> evident in the TBIVM name. If TBIVM was actually >>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>>> transition would obviously be >>>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps that >>>>>>>>>>> lengthy, but clear name would be okay anyway? >>>>>>>>>> Not convinced on that name since we are blocking at >>>>>>>>>> safepoints in the destructor. Based on the comments I added >>>>>>>>>> how about ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>>> conditions for deadlocks). >>>>>>>>>> >>>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>>> preempt_by_safepoint don't really convey to me what >>>>>>>>>>>>> happens - what is being "preempted" here? I would suggest >>>>>>>>>>>>> a more direct Monitor::release_for_safepoint >>>>>>>>>>>> Changed. >>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not >>>>>>>>>>>>> even sure if we need bother at all with the one logging >>>>>>>>>>>>> statement that is present. >>>>>>>>>>>> I added it to eventually track unbounded try locks. Not >>>>>>>>>>>> sure I follow you with the name, isn't that how we name >>>>>>>>>>>> this monitors? I tried to differentiate them from Java >>>>>>>>>>>> monitors. What about just "monitor"? >>>>>>>>>>> >>>>>>>>>>> How about vmmonitor ? >>>>>>>>>> Ok, changed. >>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>>> safepoint checks. >>>>>>>>>>>>> >>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>> Done. >>>>>>>>>>>> >>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Apart from renaming this as suggested above, aren't there >>>>>>>>>>>>> any suitable assertions we should have here? >>>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>>>>> Thread::current? >>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>>> Asserting safepoint-in-progress does not really work >>>>>>>>>>>> because _state could change to _not_synchronized right >>>>>>>>>>>> after you checked for it in TLBIVM. >>>>>>>>>>> >>>>>>>>>>> Okay. >>>>>>>>>>> >>>>>>>>>>>>> Nit: >>>>>>>>>>>>> >>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>>>> >>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>>> issue. The second line should indent to the first comma, >>>>>>>>>>>>> but that will make the second line extend way past 80 >>>>>>>>>>>>> columns. >>>>>>>>>>>>> >>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>> _owner==Thread::current() into its own function or macro >>>>>>>>>>>>> to avoid the repetition. >>>>>>>>>>>> Corrected indentation based on Dan's reply to align with >>>>>>>>>>>> _owner. >>>>>>>>>>> >>>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>>> continuation of the same argument being passed to the assert >>>>>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>>>>> >>>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>>> still be good to avoid the repetition. >>>>>>>>>> Ok, added new function assert_owned_by_self(). I could change >>>>>>>>>> it to assert_owner(Thread*) and use it for the NULL case too >>>>>>>>>> unifying the printed messages to something like "invalid >>>>>>>>>> owner: owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>> >>>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>>> Dan's comments. >>>>>>>>>>>> Done. >>>>>>>>>>>> >>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>> ??? } >>>>>>>>>>>>> >>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>> Removed. >>>>>>>>>>>> >>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can >>>>>>>>>>>>> just be a PlatformMonitor now. >>>>>>>>>>>>> >>>>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>>>> retained. Not clear if we need to set the _owner field or >>>>>>>>>>>>> can just skip it. >>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>> >>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>>>> // >>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>>> interoperate properly with the native >>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>>> >>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>>> wouldn't hurt. >>>>>>>>>>> >>>>>>>>>>> It's useful for checking usage errors, but we won't have >>>>>>>>>>> that if we replace with PlatformMonitor, so may as well drop >>>>>>>>>>> it now IMO. >>>>>>>>>> Ok, I added asserts that _owner should be NULL after >>>>>>>>>> acquiring it and before releasing it though. >>>>>>>>>> >>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>>> } >>>>>>>>>>>>> >>>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>>> destructor being called? >>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>> >>>>>>>>>>> No need - assume other people have a better understanding of >>>>>>>>>>> C++ than I do :) >>>>>>>>>> >>>>>>>>>> Below is version v04, which also contains a correction >>>>>>>>>> pointed out off-list by Robbin to do a local poll first in >>>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>>>> changing _state to _synchronizing, if we only do a global >>>>>>>>>> poll in the TLBIVM constructor we could detect there is a >>>>>>>>>> safepoint in progress and callback but when coming back in >>>>>>>>>> the destructor SafepointMechanism::should_block() could miss >>>>>>>>>> detecting the safepoint in progress since that method checks >>>>>>>>>> first for local polls. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Patricio >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>>>> send v04. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Patricio >>>>>>>>>>>>> --- >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From lois.foltan at oracle.com Mon Feb 4 21:17:17 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 4 Feb 2019 16:17:17 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: <7B6992D4-ECD3-4807-A002-C80F004CE1B9@oracle.com> References: <91C357F2-1E1F-4813-9AF2-7B7B7E45E1F3@oracle.com> <9866b03b-5560-69c3-5503-985840953ae1@oracle.com> <7B6992D4-ECD3-4807-A002-C80F004CE1B9@oracle.com> Message-ID: <36764625-607d-9a6f-9824-4057c9b519a7@oracle.com> Thank you again Karen for the review! Lois On 2/4/2019 3:57 PM, Karen Kinnear wrote: > Lois, > > Apologies for my suggestion which caused you extra work - I did not read it carefully enough. > Thank you for the careful testing. > > I don?t need to see a new webrev. > > thanks, > Karen > >> On Feb 4, 2019, at 2:18 PM, Lois Foltan wrote: >> >> On 2/4/2019 1:45 PM, Lois Foltan wrote: >>> On 2/4/2019 11:53 AM, Karen Kinnear wrote: >>>> Lois, >>>> >>>> Code looks good. Couple of minor questions.comments >>> Thank you Karen for the review! Addressed all your comments below please see additional responses. Updated webrev at: >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/ >>> >>> Rerunning hs-tier1-3 & jdk-tier1-3 testing. >>> >>>> 1. rewriter.hpp: comment line 162 needs updating - we just use 1 entry now >>> Fixed the comment and also renamed the method from "add_invokedynamic_resolved_references_entries" to "add_invokedynamic_resolved_references_entry". We were always only adding 1 entry even though previously that entry spanned multiple slots in the _invokedynamic_references_map. >>> >>>> 2. jvmciCompilerToVM.cpp >>>> You removed an assertion about method_type_if_resolved. >>>> Would it make sense to add an assertion that !has_local_sig - which if I am reading this correctly, >>>> you are setting to indicate sig-poly methods? >>> Added. >> Clarification on webrev .2 above, it does not contain the addition of the assertion as I indicated in my response. The original assertion was not simply about whether a method_type was present or not. It was about either the method_type is not present or the method_type is present and has not yet been resolved. So a replacement of that vmassert with a call to has_local_signature does not equate and numerous compiler/aot tests were failing when I retested. >> >> Thanks, >> Lois >> >>>> Does jvmci use the method_type field? Or was removing this assertion the only change needed? >>> This was the only instance of the use. However, I have sent email to Dean Long and cc'd Vladimir Kozlov asking for review. >>> >>>> 3. ciStreams.cpp >>>> comment line 367: ?There is are? -> ?There are? >>> Fixed. >>> >>>> 4. ciStreams.cpp >>>> line 336 sets local_signature >>>> Would it make sense to only do that inside the check for if (has_local_signature()) - e.g. after line 393? >>> Fixed. >>> >>>> 5. Testing - the comments in ciStreams.cpp get_method are very helpful >>>> Are there existing tests for these cases or do we need any new ones? >>> I did check the tests within jdk/java/lang/invoke, numerous scenarios for VH.get(), Lambda form for a method call dealing with linkStatic as the comments indicate, and tests dealing with variable arity, etc. So I believe the cases are covered. >>> >>> Thanks, >>> Lois >>> >>>> thanks, >>>> Karen >>>> >>>>> On Feb 4, 2019, at 7:32 AM, Lois Foltan wrote: >>>>> >>>>> Please review this change that removes the unused method_type field associated with the appendix field of an indy or method handle call. This is the first of a series of changes working towards JDK-8210685: Bootstrap method consolidation. >>>>> >>>>> open webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ >>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 >>>>> co-contributors: Lois Foltan & John Rose >>>>> >>>>> Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux only), JCK vm & lang (linux only) >>>>> >>>>> Thanks, >>>>> Lois From daniel.daugherty at oracle.com Mon Feb 4 21:25:47 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 4 Feb 2019 16:25:47 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> Message-ID: On 2/4/19 3:57 PM, Patricio Chilano wrote: > Hi Dan, > > Here is v06. It also contains David's suggested changes for > assert_owner(), and based on your correction about declaring pointers > I fixed one in ThreadBlockInVMWithDeadlockCheck declaration. Files > mutex.cpp and mutex.hpp have different styles of "pointer to" > declarations so except the one you mentioned I didn't try to fix them > all since I don't know if changing all of them to " * " is the right > approach. > > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev src/hotspot/share/runtime/interfaceSupport.inline.hpp ??? No comments. src/hotspot/share/runtime/mutex.cpp ??? No comments. src/hotspot/share/runtime/mutex.hpp ??? No comments. src/hotspot/share/runtime/safepointMechanism.inline.hpp ??? No comments. Thumbs up! Dan > Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ > > Thanks, > Patricio > > On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: >> On 2/4/19 2:40 PM, Patricio Chilano wrote: >>> Hi Dan, >>> >>> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>>> Hi all, >>>>> >>>>> Here is v05: >>>>> >>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>>> >>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>> ??? L295: // - When transitioning in (constructor), it checks for >>>> safepoints without blocking, i.e calls >>>> ??????? nit - s/i.e /i.e., / >>>> ??????? (You missed the change from my v04 review) >>> Done! I did made the change s/having to block/blocking from your >>> review but didn't see the extra comma you added after i.e. >> >> Extra period and extra comma... I'm a font/typography nut... :-) >> >> >>> >>>> L299: class ThreadBlockinVMWithDeadlockCheck : public >>>> ThreadStateTransition { >>>> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >>>> Monitor** in_flight_monitor_adr) >>>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>>> ??????? Lower case 'i' -> 'I' to match the >>>> CamelCastStyleInOtherHelpers. >>> Done. >>> >>>> src/hotspot/share/runtime/mutex.cpp >>>> ??? L36: static inline void assert_owner(Thread *owner, Thread >>>> *thread) { >>>> ??????? nit - the predominant style in this file is ' * ' (space on >>>> each side of '*') >>> Ok, is that the style that we are supposed to follow in general ? >>> Otherwise I can change all the ones that do not match the preferred >>> style. >> >> That's a good question. The general rule is to follow the >> predominant style in the file. However, I'm not sure what >> the HotSpot recommended style is (I used to know this...). >> >> >>> >>>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" >>>> INTPTR_FORMAT, >>>> ??????? Another possible style of mesg: >>>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", >>>> expect=" INTPTR_FORMAT, >>> I like more the first style, but if you really prefer the second one >>> I can change it. >> >> I'm okay with what you have. >> >> >>> >>>> ThreadBlockinVMWithDeadlockCheck renames to >>>> ThreadBlockInVMWithDeadlockCheck in >>>> ??? this file also. >>> Done. >>> >>>> src/hotspot/share/runtime/mutex.hpp >>>> ??? No comments. >>>> >>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>> ??? L83: ? if (!uses_thread_local_poll() || >>>> local_poll_armed(thread)) { >>>> ??????? Did you decide this line does not need a comment at all? >>> How about adding the following comment based on your previous email: >>> >>> // If using thread local polls, we should not check the >>> // global_poll() and callback via block() if the VMThread >>> // has not yet armed the local poll. Otherwise, when used in >>> // combination with should_block(), the latter could miss >>> // detecting the same safepoint that this method would detect >>> // if only checking global polls. >> >> I'm good with that comment. >> >> Dan >> >> >>> >>> >>> Patricio >>>> Dan >>>> >>>> >>>>> >>>>> Tested tiers 1-6. >>>>> >>>>> Thanks, >>>>> Patricio >>>>> >>>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>>> >>>>>>> >>>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>>>>>> good suggestion. >>>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut >>>>>>>>>> is rather unwieldy. ;-) But the "Lock" part really doesn't >>>>>>>>>> mean anything. So your suggestion of >>>>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement >>>>>>>>>> to me. :) >>>>>>>>> >>>>>>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>>>>>> "why" this class, vs. "what" this class does. Since the latter >>>>>>>>> can change. >>>>>>>> I like that name. Is that name okay with you David? >>>>>>> >>>>>>> Sorry no. "Lock" still adds zero information about when/why you >>>>>>> would use this. It's used within Monitor::lock and Monitor::wait >>>>>>> so is not specific to "locking" even in that class. This is >>>>>>> about blocking in the VM and we need to know what this version >>>>>>> does differently to the existing TBIVM. There are lots of >>>>>>> different types of "locking" in the VM and we don't use this >>>>>>> with them. >>>>>>> >>>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>>>>> >>>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>>> >>>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>>> >>>>>> ThreadBlockinVMWithDeadlockCheck >>>>>> ThreadBlockinVMWithDeadlockChk >>>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>>> >>>>>> Just pick a name and run with it... :-) >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Patricio >>>>>>>>> thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> First, thanks for all the many weeks of work you've put >>>>>>>>>>>>>> into this, pulling together a number of ideas from >>>>>>>>>>>>>> different people to make it all work! >>>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>>>> implementation? : ) >>>>>>>>>>>> >>>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>>> >>>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>>> Full: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>>>> behaviour without having to duplicate so much of this >>>>>>>>>>>>>> code. In any case the semantics of ThreadLockBlockInVM >>>>>>>>>>>>>> needs to be described. >>>>>>>>>>>>> I could do it with one extra argument, but I would need to >>>>>>>>>>>>> add two extra branches in transition_and_fence(), one to >>>>>>>>>>>>> decide if I'm in the Monitor case to avoid calling >>>>>>>>>>>>> SafepointMechanism::block_if_requested() directly and >>>>>>>>>>>>> another one to actually decide if I'm transitioning in or >>>>>>>>>>>>> out, since the actions to perform are different. I think >>>>>>>>>>>>> it is easier to read without adding new conditionals, and >>>>>>>>>>>>> also we will save those extra branches, but if you think >>>>>>>>>>>>> it's better this way I can change it. >>>>>>>>>>>> >>>>>>>>>>>> I would like something that tells me more clearly how this >>>>>>>>>>>> new transition helper differs from the existing TBIVM. >>>>>>>>>>>> Sharing the code between them and using different args >>>>>>>>>>>> would be one way. Documenting the difference in comments >>>>>>>>>>>> would be another. Your choice. >>>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>>> >>>>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>>> >>>>>>>>>>>> That's not quite conveying the semantics. The problem is >>>>>>>>>>>> that the semantics we are changing compared to TBIVM are >>>>>>>>>>>> not evident in the TBIVM name. If TBIVM was actually >>>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>>>> transition would obviously be >>>>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps that >>>>>>>>>>>> lengthy, but clear name would be okay anyway? >>>>>>>>>>> Not convinced on that name since we are blocking at >>>>>>>>>>> safepoints in the destructor. Based on the comments I added >>>>>>>>>>> how about ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>>>> conditions for deadlocks). >>>>>>>>>>> >>>>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>>>> preempt_by_safepoint don't really convey to me what >>>>>>>>>>>>>> happens - what is being "preempted" here? I would suggest >>>>>>>>>>>>>> a more direct Monitor::release_for_safepoint >>>>>>>>>>>>> Changed. >>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not >>>>>>>>>>>>>> even sure if we need bother at all with the one logging >>>>>>>>>>>>>> statement that is present. >>>>>>>>>>>>> I added it to eventually track unbounded try locks. Not >>>>>>>>>>>>> sure I follow you with the name, isn't that how we name >>>>>>>>>>>>> this monitors? I tried to differentiate them from Java >>>>>>>>>>>>> monitors. What about just "monitor"? >>>>>>>>>>>> >>>>>>>>>>>> How about vmmonitor ? >>>>>>>>>>> Ok, changed. >>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>>> >>>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>>>> safepoint checks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>>> Done. >>>>>>>>>>>>> >>>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Apart from renaming this as suggested above, aren't there >>>>>>>>>>>>>> any suitable assertions we should have here? >>>>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>>>>>> Thread::current? >>>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>>>> Asserting safepoint-in-progress does not really work >>>>>>>>>>>>> because _state could change to _not_synchronized right >>>>>>>>>>>>> after you checked for it in TLBIVM. >>>>>>>>>>>> >>>>>>>>>>>> Okay. >>>>>>>>>>>> >>>>>>>>>>>>>> Nit: >>>>>>>>>>>>>> >>>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>>>>> >>>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>>>> issue. The second line should indent to the first comma, >>>>>>>>>>>>>> but that will make the second line extend way past 80 >>>>>>>>>>>>>> columns. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>>> _owner==Thread::current() into its own function or macro >>>>>>>>>>>>>> to avoid the repetition. >>>>>>>>>>>>> Corrected indentation based on Dan's reply to align with >>>>>>>>>>>>> _owner. >>>>>>>>>>>> >>>>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>>>> continuation of the same argument being passed to the >>>>>>>>>>>> assert "function". But I'm okay with Dan's suggestion. >>>>>>>>>>>> >>>>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>>>> still be good to avoid the repetition. >>>>>>>>>>> Ok, added new function assert_owned_by_self(). I could >>>>>>>>>>> change it to assert_owner(Thread*) and use it for the NULL >>>>>>>>>>> case too unifying the printed messages to something like >>>>>>>>>>> "invalid owner: owner=" INTPTR_FORMAT ", should be:" >>>>>>>>>>> INTPTR_FORMAT. What do you think? >>>>>>>>>>> >>>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>>> >>>>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>>>> Dan's comments. >>>>>>>>>>>>> Done. >>>>>>>>>>>>> >>>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>>> ??? } >>>>>>>>>>>>>> >>>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>>> Removed. >>>>>>>>>>>>> >>>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can >>>>>>>>>>>>>> just be a PlatformMonitor now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>>>>> retained. Not clear if we need to set the _owner field or >>>>>>>>>>>>>> can just skip it. >>>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>>> >>>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>>>>> // >>>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>>>> interoperate properly with the native >>>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>>>> >>>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>>>> wouldn't hurt. >>>>>>>>>>>> >>>>>>>>>>>> It's useful for checking usage errors, but we won't have >>>>>>>>>>>> that if we replace with PlatformMonitor, so may as well >>>>>>>>>>>> drop it now IMO. >>>>>>>>>>> Ok, I added asserts that _owner should be NULL after >>>>>>>>>>> acquiring it and before releasing it though. >>>>>>>>>>> >>>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>>>> destructor being called? >>>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>>> >>>>>>>>>>>> No need - assume other people have a better understanding >>>>>>>>>>>> of C++ than I do :) >>>>>>>>>>> >>>>>>>>>>> Below is version v04, which also contains a correction >>>>>>>>>>> pointed out off-list by Robbin to do a local poll first in >>>>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>>>>> changing _state to _synchronizing, if we only do a global >>>>>>>>>>> poll in the TLBIVM constructor we could detect there is a >>>>>>>>>>> safepoint in progress and callback but when coming back in >>>>>>>>>>> the destructor SafepointMechanism::should_block() could miss >>>>>>>>>>> detecting the safepoint in progress since that method checks >>>>>>>>>>> first for local polls. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Patricio >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>>>>> send v04. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Patricio >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From patricio.chilano.mateo at oracle.com Mon Feb 4 21:45:53 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Mon, 4 Feb 2019 16:45:53 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> Message-ID: <6fab938e-cf62-d610-a2d5-bcc71e83be67@oracle.com> On 2/4/19 4:25 PM, Daniel D. Daugherty wrote: > On 2/4/19 3:57 PM, Patricio Chilano wrote: >> Hi Dan, >> >> Here is v06. It also contains David's suggested changes for >> assert_owner(), and based on your correction about declaring pointers >> I fixed one in ThreadBlockInVMWithDeadlockCheck declaration. Files >> mutex.cpp and mutex.hpp have different styles of "pointer to" >> declarations so except the one you mentioned I didn't try to fix them >> all since I don't know if changing all of them to " * " is the right >> approach. >> >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > ??? No comments. > > src/hotspot/share/runtime/mutex.cpp > ??? No comments. > > src/hotspot/share/runtime/mutex.hpp > ??? No comments. > > src/hotspot/share/runtime/safepointMechanism.inline.hpp > ??? No comments. > > Thumbs up! Thanks Dan! Patricio > Dan > > >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ >> >> Thanks, >> Patricio >> >> On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: >>> On 2/4/19 2:40 PM, Patricio Chilano wrote: >>>> Hi Dan, >>>> >>>> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>>>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>>>> Hi all, >>>>>> >>>>>> Here is v05: >>>>>> >>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>>>> >>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>> ??? L295: // - When transitioning in (constructor), it checks for >>>>> safepoints without blocking, i.e calls >>>>> ??????? nit - s/i.e /i.e., / >>>>> ??????? (You missed the change from my v04 review) >>>> Done! I did made the change s/having to block/blocking from your >>>> review but didn't see the extra comma you added after i.e. >>> >>> Extra period and extra comma... I'm a font/typography nut... :-) >>> >>> >>>> >>>>> L299: class ThreadBlockinVMWithDeadlockCheck : public >>>>> ThreadStateTransition { >>>>> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >>>>> Monitor** in_flight_monitor_adr) >>>>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>>>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>>>> ??????? Lower case 'i' -> 'I' to match the >>>>> CamelCastStyleInOtherHelpers. >>>> Done. >>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> ??? L36: static inline void assert_owner(Thread *owner, Thread >>>>> *thread) { >>>>> ??????? nit - the predominant style in this file is ' * ' (space >>>>> on each side of '*') >>>> Ok, is that the style that we are supposed to follow in general ? >>>> Otherwise I can change all the ones that do not match the preferred >>>> style. >>> >>> That's a good question. The general rule is to follow the >>> predominant style in the file. However, I'm not sure what >>> the HotSpot recommended style is (I used to know this...). >>> >>> >>>> >>>>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" >>>>> INTPTR_FORMAT, >>>>> ??????? Another possible style of mesg: >>>>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", >>>>> expect=" INTPTR_FORMAT, >>>> I like more the first style, but if you really prefer the second >>>> one I can change it. >>> >>> I'm okay with what you have. >>> >>> >>>> >>>>> ThreadBlockinVMWithDeadlockCheck renames to >>>>> ThreadBlockInVMWithDeadlockCheck in >>>>> ??? this file also. >>>> Done. >>>> >>>>> src/hotspot/share/runtime/mutex.hpp >>>>> ??? No comments. >>>>> >>>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>>> ??? L83: ? if (!uses_thread_local_poll() || >>>>> local_poll_armed(thread)) { >>>>> ??????? Did you decide this line does not need a comment at all? >>>> How about adding the following comment based on your previous email: >>>> >>>> // If using thread local polls, we should not check the >>>> // global_poll() and callback via block() if the VMThread >>>> // has not yet armed the local poll. Otherwise, when used in >>>> // combination with should_block(), the latter could miss >>>> // detecting the same safepoint that this method would detect >>>> // if only checking global polls. >>> >>> I'm good with that comment. >>> >>> Dan >>> >>> >>>> >>>> >>>> Patricio >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Tested tiers 1-6. >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>> >>>>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have >>>>>>>>>>> a good suggestion. >>>>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut >>>>>>>>>>> is rather unwieldy. ;-) But the "Lock" part really doesn't >>>>>>>>>>> mean anything. So your suggestion of >>>>>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big >>>>>>>>>>> improvement to me. :) >>>>>>>>>> >>>>>>>>>> How about ThreadBlockInVMForLock ??? This answers the >>>>>>>>>> question "why" this class, vs. "what" this class does. Since >>>>>>>>>> the latter can change. >>>>>>>>> I like that name. Is that name okay with you David? >>>>>>>> >>>>>>>> Sorry no. "Lock" still adds zero information about when/why you >>>>>>>> would use this. It's used within Monitor::lock and >>>>>>>> Monitor::wait so is not specific to "locking" even in that >>>>>>>> class. This is about blocking in the VM and we need to know >>>>>>>> what this version does differently to the existing TBIVM. There >>>>>>>> are lots of different types of "locking" in the VM and we don't >>>>>>>> use this with them. >>>>>>>> >>>>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! >>>>>>>> ;-) >>>>>>> >>>>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>>>> >>>>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>>>> >>>>>>> ThreadBlockinVMWithDeadlockCheck >>>>>>> ThreadBlockinVMWithDeadlockChk >>>>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>>>> >>>>>>> Just pick a name and run with it... :-) >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Patricio >>>>>>>>>> thanks, >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> First, thanks for all the many weeks of work you've put >>>>>>>>>>>>>>> into this, pulling together a number of ideas from >>>>>>>>>>>>>>> different people to make it all work! >>>>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>>>>> implementation? : ) >>>>>>>>>>>>> >>>>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>>>> >>>>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>>>> Full: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>>>>> behaviour without having to duplicate so much of this >>>>>>>>>>>>>>> code. In any case the semantics of ThreadLockBlockInVM >>>>>>>>>>>>>>> needs to be described. >>>>>>>>>>>>>> I could do it with one extra argument, but I would need >>>>>>>>>>>>>> to add two extra branches in transition_and_fence(), one >>>>>>>>>>>>>> to decide if I'm in the Monitor case to avoid calling >>>>>>>>>>>>>> SafepointMechanism::block_if_requested() directly and >>>>>>>>>>>>>> another one to actually decide if I'm transitioning in or >>>>>>>>>>>>>> out, since the actions to perform are different. I think >>>>>>>>>>>>>> it is easier to read without adding new conditionals, and >>>>>>>>>>>>>> also we will save those extra branches, but if you think >>>>>>>>>>>>>> it's better this way I can change it. >>>>>>>>>>>>> >>>>>>>>>>>>> I would like something that tells me more clearly how this >>>>>>>>>>>>> new transition helper differs from the existing TBIVM. >>>>>>>>>>>>> Sharing the code between them and using different args >>>>>>>>>>>>> would be one way. Documenting the difference in comments >>>>>>>>>>>>> would be another. Your choice. >>>>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>>>> >>>>>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>>>> >>>>>>>>>>>>> That's not quite conveying the semantics. The problem is >>>>>>>>>>>>> that the semantics we are changing compared to TBIVM are >>>>>>>>>>>>> not evident in the TBIVM name. If TBIVM was actually >>>>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>>>>> transition would obviously be >>>>>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps that >>>>>>>>>>>>> lengthy, but clear name would be okay anyway? >>>>>>>>>>>> Not convinced on that name since we are blocking at >>>>>>>>>>>> safepoints in the destructor. Based on the comments I added >>>>>>>>>>>> how about ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>>>>> conditions for deadlocks). >>>>>>>>>>>> >>>>>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>>>>> preempt_by_safepoint don't really convey to me what >>>>>>>>>>>>>>> happens - what is being "preempted" here? I would >>>>>>>>>>>>>>> suggest a more direct Monitor::release_for_safepoint >>>>>>>>>>>>>> Changed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not >>>>>>>>>>>>>>> even sure if we need bother at all with the one logging >>>>>>>>>>>>>>> statement that is present. >>>>>>>>>>>>>> I added it to eventually track unbounded try locks. Not >>>>>>>>>>>>>> sure I follow you with the name, isn't that how we name >>>>>>>>>>>>>> this monitors? I tried to differentiate them from Java >>>>>>>>>>>>>> monitors. What about just "monitor"? >>>>>>>>>>>>> >>>>>>>>>>>>> How about vmmonitor ? >>>>>>>>>>>> Ok, changed. >>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>>>>> safepoint checks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Apart from renaming this as suggested above, aren't >>>>>>>>>>>>>>> there any suitable assertions we should have here? >>>>>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner >>>>>>>>>>>>>>> == Thread::current? >>>>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>>>>> Asserting safepoint-in-progress does not really work >>>>>>>>>>>>>> because _state could change to _not_synchronized right >>>>>>>>>>>>>> after you checked for it in TLBIVM. >>>>>>>>>>>>> >>>>>>>>>>>>> Okay. >>>>>>>>>>>>> >>>>>>>>>>>>>>> Nit: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>>>>> issue. The second line should indent to the first comma, >>>>>>>>>>>>>>> but that will make the second line extend way past 80 >>>>>>>>>>>>>>> columns. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>>>> _owner==Thread::current() into its own function or macro >>>>>>>>>>>>>>> to avoid the repetition. >>>>>>>>>>>>>> Corrected indentation based on Dan's reply to align with >>>>>>>>>>>>>> _owner. >>>>>>>>>>>>> >>>>>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>>>>> continuation of the same argument being passed to the >>>>>>>>>>>>> assert "function". But I'm okay with Dan's suggestion. >>>>>>>>>>>>> >>>>>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>>>>> still be good to avoid the repetition. >>>>>>>>>>>> Ok, added new function assert_owned_by_self(). I could >>>>>>>>>>>> change it to assert_owner(Thread*) and use it for the NULL >>>>>>>>>>>> case too unifying the printed messages to something like >>>>>>>>>>>> "invalid owner: owner=" INTPTR_FORMAT ", should be:" >>>>>>>>>>>> INTPTR_FORMAT. What do you think? >>>>>>>>>>>> >>>>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>>>>> Dan's comments. >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>>>> ??? } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>>>> Removed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can >>>>>>>>>>>>>>> just be a PlatformMonitor now. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>>>>>> retained. Not clear if we need to set the _owner field >>>>>>>>>>>>>>> or can just skip it. >>>>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>>>> >>>>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>>>>>> // >>>>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>>>>> interoperate properly with the native >>>>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>>>>> >>>>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace >>>>>>>>>>>>> them with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>>>>> wouldn't hurt. >>>>>>>>>>>>> >>>>>>>>>>>>> It's useful for checking usage errors, but we won't have >>>>>>>>>>>>> that if we replace with PlatformMonitor, so may as well >>>>>>>>>>>>> drop it now IMO. >>>>>>>>>>>> Ok, I added asserts that _owner should be NULL after >>>>>>>>>>>> acquiring it and before releasing it though. >>>>>>>>>>>> >>>>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>>>>> destructor being called? >>>>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>>>> >>>>>>>>>>>>> No need - assume other people have a better understanding >>>>>>>>>>>>> of C++ than I do :) >>>>>>>>>>>> >>>>>>>>>>>> Below is version v04, which also contains a correction >>>>>>>>>>>> pointed out off-list by Robbin to do a local poll first in >>>>>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>>>>>> changing _state to _synchronizing, if we only do a global >>>>>>>>>>>> poll in the TLBIVM constructor we could detect there is a >>>>>>>>>>>> safepoint in progress and callback but when coming back in >>>>>>>>>>>> the destructor SafepointMechanism::should_block() could >>>>>>>>>>>> miss detecting the safepoint in progress since that method >>>>>>>>>>>> checks first for local polls. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Patricio >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>>>>>> send v04. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Patricio >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Mon Feb 4 23:05:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 09:05:12 +1000 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> Message-ID: <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> On 5/02/2019 8:30 am, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Looks good in general. > > Just a couple minor comments below. > > I hope, you will update the copyright years before the push. > > > http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html > > ? Nice test! > > 37 import java.lang.reflect.*; > 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; > 39 import java.lang.instrument.*; > > ? The imports above can be re-ordered. > > 44 return new String("public class B" + count + " {" + > 45 " public static void compiledMethod() { " + > 46 " try{" + > 47 " Thread.currentThread().sleep(1); " + > 48 " } catch(InterruptedException ie) {" + > 49 " }" + > 50 " }" + > 51 "}"); > > ? Not clear, why sleep is needed here. Presumably just to give it some code and consume some time. Nit: But it should just be: Thread.sleep(1) not Thread.currentThread().sleep(1); sleep is a static method and as with all Thread static methods always applies to the current thread. David > > Thanks, > Serguei > > > On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >> Added the serviceability-dev back. >> >> Thanks, >> Serguei >> >> >> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>> >>> The links. >>> Thanks, >>> Coleen >>> >>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>> >>>> *This change touches the AOT and code cache code.? I tried to >>>> describe it in the comments in the RFE.? Basically, for >>>> redefinition, we walk the code cache per class redefined in order to >>>> find evol_method dependencies, then deoptimize if we find them, and >>>> then walk the code cache again to mark the deoptimized nmethods as >>>> not_entrant. >>>> >>>> I replaced this with only marking any nmethods for the class's >>>> methods to deoptimize (following InstanceKlass::_methods), also >>>> marking aot methods dependent on the class, and then doing the code >>>> cache walk to follow the evol_method dependencies at the end of >>>> redefinition for all the classes. The new code uses the >>>> Method::is_old() flag rather than comparing each method in the >>>> InstanceKlass.? Then deoptimization and marking not_entrant is done >>>> once at the end of the redefinition as well. >>>> >>>> Tested with tier1-6, all the redefinition tests locally: >>>> >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>> >&redefine.out >>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>> >>>> new test, and JMH test (see CR for results). >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Feb 5 00:00:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 16:00:21 -0800 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> Message-ID: On 2/4/19 15:05, David Holmes wrote: > On 5/02/2019 8:30 am, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Looks good in general. >> >> Just a couple minor comments below. >> >> I hope, you will update the copyright years before the push. >> >> >> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html >> >> >> ?? Nice test! >> >> ?? 37 import java.lang.reflect.*; >> ?? 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; >> ?? 39 import java.lang.instrument.*; >> >> ?? The imports above can be re-ordered. >> >> ?? 44???????? return new String("public class B" + count + " {" + >> ?? 45???????????????? "?? public static void compiledMethod() { " + >> ?? 46???????????????? "?????? try{" + >> ?? 47???????????????? " Thread.currentThread().sleep(1); " + >> ?? 48???????????????? "?????? } catch(InterruptedException ie) {" + >> ?? 49???????????????? "?????? }" + >> ?? 50???????????????? "?? }" + >> ?? 51???????????????? "}"); >> >> ?? Not clear, why sleep is needed here. > > Presumably just to give it some code and consume some time. Some print statement would be more simple and useful. But it is really minor. :) Thanks, Serguei > Nit: But it should just be: > > Thread.sleep(1) > > not > > Thread.currentThread().sleep(1); > > sleep is a static method and as with all Thread static methods always > applies to the current thread. > > David > >> >> Thanks, >> Serguei >> >> >> On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >>> Added the serviceability-dev back. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>>> >>>> The links. >>>> Thanks, >>>> Coleen >>>> >>>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>>> >>>>> *This change touches the AOT and code cache code.? I tried to >>>>> describe it in the comments in the RFE.? Basically, for >>>>> redefinition, we walk the code cache per class redefined in order >>>>> to find evol_method dependencies, then deoptimize if we find them, >>>>> and then walk the code cache again to mark the deoptimized >>>>> nmethods as not_entrant. >>>>> >>>>> I replaced this with only marking any nmethods for the class's >>>>> methods to deoptimize (following InstanceKlass::_methods), also >>>>> marking aot methods dependent on the class, and then doing the >>>>> code cache walk to follow the evol_method dependencies at the end >>>>> of redefinition for all the classes. The new code uses the >>>>> Method::is_old() flag rather than comparing each method in the >>>>> InstanceKlass.? Then deoptimization and marking not_entrant is >>>>> done once at the end of the redefinition as well. >>>>> >>>>> Tested with tier1-6, all the redefinition tests locally: >>>>> >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>>> >&jvmti.out >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>>> >&redefine.out >>>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>>> >>>>> new test, and JMH test (see CR for results). >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Tue Feb 5 00:06:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 10:06:29 +1000 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> Message-ID: v6 incremental looks good to me. Thanks, David ----- On 5/02/2019 6:57 am, Patricio Chilano wrote: > Hi Dan, > > Here is v06. It also contains David's suggested changes for > assert_owner(), and based on your correction about declaring pointers I > fixed one in ThreadBlockInVMWithDeadlockCheck declaration. Files > mutex.cpp and mutex.hpp have different styles of "pointer to" > declarations so except the one you mentioned I didn't try to fix them > all since I don't know if changing all of them to " * " is the right > approach. > > Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev > Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ > > Thanks, > Patricio > > On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: >> On 2/4/19 2:40 PM, Patricio Chilano wrote: >>> Hi Dan, >>> >>> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>>> Hi all, >>>>> >>>>> Here is v05: >>>>> >>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>>> >>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>> ??? L295: // - When transitioning in (constructor), it checks for >>>> safepoints without blocking, i.e calls >>>> ??????? nit - s/i.e /i.e., / >>>> ??????? (You missed the change from my v04 review) >>> Done! I did made the change s/having to block/blocking from your >>> review but didn't see the extra comma you added after i.e. >> >> Extra period and extra comma... I'm a font/typography nut... :-) >> >> >>> >>>> L299: class ThreadBlockinVMWithDeadlockCheck : public >>>> ThreadStateTransition { >>>> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >>>> Monitor** in_flight_monitor_adr) >>>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>>> ??????? Lower case 'i' -> 'I' to match the >>>> CamelCastStyleInOtherHelpers. >>> Done. >>> >>>> src/hotspot/share/runtime/mutex.cpp >>>> ??? L36: static inline void assert_owner(Thread *owner, Thread >>>> *thread) { >>>> ??????? nit - the predominant style in this file is ' * ' (space on >>>> each side of '*') >>> Ok, is that the style that we are supposed to follow in general ? >>> Otherwise I can change all the ones that do not match the preferred >>> style. >> >> That's a good question. The general rule is to follow the >> predominant style in the file. However, I'm not sure what >> the HotSpot recommended style is (I used to know this...). >> >> >>> >>>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" >>>> INTPTR_FORMAT, >>>> ??????? Another possible style of mesg: >>>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", expect=" >>>> INTPTR_FORMAT, >>> I like more the first style, but if you really prefer the second one >>> I can change it. >> >> I'm okay with what you have. >> >> >>> >>>> ThreadBlockinVMWithDeadlockCheck renames to >>>> ThreadBlockInVMWithDeadlockCheck in >>>> ??? this file also. >>> Done. >>> >>>> src/hotspot/share/runtime/mutex.hpp >>>> ??? No comments. >>>> >>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>> ??? L83: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { >>>> ??????? Did you decide this line does not need a comment at all? >>> How about adding the following comment based on your previous email: >>> >>> // If using thread local polls, we should not check the >>> // global_poll() and callback via block() if the VMThread >>> // has not yet armed the local poll. Otherwise, when used in >>> // combination with should_block(), the latter could miss >>> // detecting the same safepoint that this method would detect >>> // if only checking global polls. >> >> I'm good with that comment. >> >> Dan >> >> >>> >>> >>> Patricio >>>> Dan >>>> >>>> >>>>> >>>>> Tested tiers 1-6. >>>>> >>>>> Thanks, >>>>> Patricio >>>>> >>>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>>> >>>>>>> >>>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a >>>>>>>>>> good suggestion. >>>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is >>>>>>>>>> rather unwieldy. ;-) But the "Lock" part really doesn't mean >>>>>>>>>> anything. So your suggestion of >>>>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big improvement >>>>>>>>>> to me. :) >>>>>>>>> >>>>>>>>> How about ThreadBlockInVMForLock ??? This answers the question >>>>>>>>> "why" this class, vs. "what" this class does. Since the latter >>>>>>>>> can change. >>>>>>>> I like that name. Is that name okay with you David? >>>>>>> >>>>>>> Sorry no. "Lock" still adds zero information about when/why you >>>>>>> would use this. It's used within Monitor::lock and Monitor::wait >>>>>>> so is not specific to "locking" even in that class. This is about >>>>>>> blocking in the VM and we need to know what this version does >>>>>>> differently to the existing TBIVM. There are lots of different >>>>>>> types of "locking" in the VM and we don't use this with them. >>>>>>> >>>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>>>>> >>>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>>> >>>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>>> >>>>>> ThreadBlockinVMWithDeadlockCheck >>>>>> ThreadBlockinVMWithDeadlockChk >>>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>>> >>>>>> Just pick a name and run with it... :-) >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Patricio >>>>>>>>> thanks, >>>>>>>>> Coleen >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> First, thanks for all the many weeks of work you've put >>>>>>>>>>>>>> into this, pulling together a number of ideas from >>>>>>>>>>>>>> different people to make it all work! >>>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>>>> implementation? : ) >>>>>>>>>>>> >>>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>>> >>>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>>> Full: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>>>> behaviour without having to duplicate so much of this >>>>>>>>>>>>>> code. In any case the semantics of ThreadLockBlockInVM >>>>>>>>>>>>>> needs to be described. >>>>>>>>>>>>> I could do it with one extra argument, but I would need to >>>>>>>>>>>>> add two extra branches in transition_and_fence(), one to >>>>>>>>>>>>> decide if I'm in the Monitor case to avoid calling >>>>>>>>>>>>> SafepointMechanism::block_if_requested() directly and >>>>>>>>>>>>> another one to actually decide if I'm transitioning in or >>>>>>>>>>>>> out, since the actions to perform are different. I think it >>>>>>>>>>>>> is easier to read without adding new conditionals, and also >>>>>>>>>>>>> we will save those extra branches, but if you think it's >>>>>>>>>>>>> better this way I can change it. >>>>>>>>>>>> >>>>>>>>>>>> I would like something that tells me more clearly how this >>>>>>>>>>>> new transition helper differs from the existing TBIVM. >>>>>>>>>>>> Sharing the code between them and using different args would >>>>>>>>>>>> be one way. Documenting the difference in comments would be >>>>>>>>>>>> another. Your choice. >>>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>>> >>>>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>>> >>>>>>>>>>>> That's not quite conveying the semantics. The problem is >>>>>>>>>>>> that the semantics we are changing compared to TBIVM are not >>>>>>>>>>>> evident in the TBIVM name. If TBIVM was actually >>>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>>>> transition would obviously be >>>>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps that >>>>>>>>>>>> lengthy, but clear name would be okay anyway? >>>>>>>>>>> Not convinced on that name since we are blocking at >>>>>>>>>>> safepoints in the destructor. Based on the comments I added >>>>>>>>>>> how about ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>>>> conditions for deadlocks). >>>>>>>>>>> >>>>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>>>> preempt_by_safepoint don't really convey to me what >>>>>>>>>>>>>> happens - what is being "preempted" here? I would suggest >>>>>>>>>>>>>> a more direct Monitor::release_for_safepoint >>>>>>>>>>>>> Changed. >>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not >>>>>>>>>>>>>> even sure if we need bother at all with the one logging >>>>>>>>>>>>>> statement that is present. >>>>>>>>>>>>> I added it to eventually track unbounded try locks. Not >>>>>>>>>>>>> sure I follow you with the name, isn't that how we name >>>>>>>>>>>>> this monitors? I tried to differentiate them from Java >>>>>>>>>>>>> monitors. What about just "monitor"? >>>>>>>>>>>> >>>>>>>>>>>> How about vmmonitor ? >>>>>>>>>>> Ok, changed. >>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>>> >>>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>>>> safepoint checks. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>>> Done. >>>>>>>>>>>>> >>>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Apart from renaming this as suggested above, aren't there >>>>>>>>>>>>>> any suitable assertions we should have here? >>>>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner == >>>>>>>>>>>>>> Thread::current? >>>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>>>> Asserting safepoint-in-progress does not really work >>>>>>>>>>>>> because _state could change to _not_synchronized right >>>>>>>>>>>>> after you checked for it in TLBIVM. >>>>>>>>>>>> >>>>>>>>>>>> Okay. >>>>>>>>>>>> >>>>>>>>>>>>>> Nit: >>>>>>>>>>>>>> >>>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>>>>> >>>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>>>> issue. The second line should indent to the first comma, >>>>>>>>>>>>>> but that will make the second line extend way past 80 >>>>>>>>>>>>>> columns. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>>> _owner==Thread::current() into its own function or macro >>>>>>>>>>>>>> to avoid the repetition. >>>>>>>>>>>>> Corrected indentation based on Dan's reply to align with >>>>>>>>>>>>> _owner. >>>>>>>>>>>> >>>>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>>>> continuation of the same argument being passed to the assert >>>>>>>>>>>> "function". But I'm okay with Dan's suggestion. >>>>>>>>>>>> >>>>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>>>> still be good to avoid the repetition. >>>>>>>>>>> Ok, added new function assert_owned_by_self(). I could change >>>>>>>>>>> it to assert_owner(Thread*) and use it for the NULL case too >>>>>>>>>>> unifying the printed messages to something like "invalid >>>>>>>>>>> owner: owner=" INTPTR_FORMAT ", should be:" INTPTR_FORMAT. >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>>> >>>>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>>>> Dan's comments. >>>>>>>>>>>>> Done. >>>>>>>>>>>>> >>>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>>> ??? } >>>>>>>>>>>>>> >>>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>>> Removed. >>>>>>>>>>>>> >>>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can >>>>>>>>>>>>>> just be a PlatformMonitor now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>>>>> retained. Not clear if we need to set the _owner field or >>>>>>>>>>>>>> can just skip it. >>>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>>> >>>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>>>>> // >>>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>>>> interoperate properly with the native >>>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>>>> >>>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace them >>>>>>>>>>>> with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>>>> wouldn't hurt. >>>>>>>>>>>> >>>>>>>>>>>> It's useful for checking usage errors, but we won't have >>>>>>>>>>>> that if we replace with PlatformMonitor, so may as well drop >>>>>>>>>>>> it now IMO. >>>>>>>>>>> Ok, I added asserts that _owner should be NULL after >>>>>>>>>>> acquiring it and before releasing it though. >>>>>>>>>>> >>>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>>>> destructor being called? >>>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>>> >>>>>>>>>>>> No need - assume other people have a better understanding of >>>>>>>>>>>> C++ than I do :) >>>>>>>>>>> >>>>>>>>>>> Below is version v04, which also contains a correction >>>>>>>>>>> pointed out off-list by Robbin to do a local poll first in >>>>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>>>>> changing _state to _synchronizing, if we only do a global >>>>>>>>>>> poll in the TLBIVM constructor we could detect there is a >>>>>>>>>>> safepoint in progress and callback but when coming back in >>>>>>>>>>> the destructor SafepointMechanism::should_block() could miss >>>>>>>>>>> detecting the safepoint in progress since that method checks >>>>>>>>>>> first for local polls. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Patricio >>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>>>>> send v04. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Patricio >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Tue Feb 5 01:16:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 11:16:36 +1000 Subject: RFR(S) [12] : 8218197 : [failurehandler] parent processes shouldn't be killed till their children are handle In-Reply-To: References: Message-ID: Hi Igor, I think this looks okay. I'm not familiar with the overall tool but can see that you now apply the actions after gathering the info, which matches how you describe the issue. Thanks, David On 5/02/2019 3:37 am, Igor Ignatyev wrote: > A friendly reminder. > > -- Igor > >> On Feb 1, 2019, at 8:58 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html >>> 25 lines changed: 8 ins; 2 del; 15 mod; >> >> Hi all, >> >> could you please review this small fix for timeout handler? >> after 8205687[1], we start to kill a process to get a core dump. since we gather info from the parent process before its children and killing a parent can kill children, we started to observer suspiciously disappeared children processes (8176214[2], 8217170[3]). the patch changes the order we gather information, so we never kill a process till we gather from all its children. the other part of the patch fixes html-output. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8205687 >> [2] https://bugs.openjdk.java.net/browse/JDK-8176214 >> [3] https://bugs.openjdk.java.net/browse/JDK-8217170 >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8218197 >> testing: manually verified reports generated for all time-outing multi-processed test on linux, windows, solaris and mac. >> >> Thanks, >> -- Igor >> >> > From kim.barrett at oracle.com Tue Feb 5 01:46:34 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 4 Feb 2019 20:46:34 -0500 Subject: RFR(S) [12] : 8218197 : [failurehandler] parent processes shouldn't be killed till their children are handle In-Reply-To: References: Message-ID: <7C19A21A-74FC-4FED-963D-39A81007E97A@oracle.com> > On Feb 1, 2019, at 11:58 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html >> 25 lines changed: 8 ins; 2 del; 15 mod; > > Hi all, > > could you please review this small fix for timeout handler? > after 8205687[1], we start to kill a process to get a core dump. since we gather info from the parent process before its children and killing a parent can kill children, we started to observer suspiciously disappeared children processes (8176214[2], 8217170[3]). the patch changes the order we gather information, so we never kill a process till we gather from all its children. the other part of the patch fixes html-output. > > [1] https://bugs.openjdk.java.net/browse/JDK-8205687 > [2] https://bugs.openjdk.java.net/browse/JDK-8176214 > [3] https://bugs.openjdk.java.net/browse/JDK-8217170 > > webrev: http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8218197 > testing: manually verified reports generated for all time-outing multi-processed test on linux, windows, solaris and mac. > > Thanks, > -- Igor Looks good. From igor.ignatyev at oracle.com Tue Feb 5 01:55:13 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 4 Feb 2019 17:55:13 -0800 Subject: RFR(S) [12] : 8218197 : [failurehandler] parent processes shouldn't be killed till their children are handle In-Reply-To: <7C19A21A-74FC-4FED-963D-39A81007E97A@oracle.com> References: <7C19A21A-74FC-4FED-963D-39A81007E97A@oracle.com> Message-ID: <6E20C193-2815-4DB7-98C4-1BD05137C6FE@oracle.com> David, Kim, thank you for your review! pushed w/ copyright years updated in all the touched files. -- Igor > On Feb 4, 2019, at 5:46 PM, Kim Barrett wrote: > >> On Feb 1, 2019, at 11:58 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html >>> 25 lines changed: 8 ins; 2 del; 15 mod; >> >> Hi all, >> >> could you please review this small fix for timeout handler? >> after 8205687[1], we start to kill a process to get a core dump. since we gather info from the parent process before its children and killing a parent can kill children, we started to observer suspiciously disappeared children processes (8176214[2], 8217170[3]). the patch changes the order we gather information, so we never kill a process till we gather from all its children. the other part of the patch fixes html-output. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8205687 >> [2] https://bugs.openjdk.java.net/browse/JDK-8176214 >> [3] https://bugs.openjdk.java.net/browse/JDK-8217170 >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8218197/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8218197 >> testing: manually verified reports generated for all time-outing multi-processed test on linux, windows, solaris and mac. >> >> Thanks, >> -- Igor > > Looks good. > From coleen.phillimore at oracle.com Tue Feb 5 02:26:44 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 21:26:44 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> Message-ID: <33a1dbcb-d7c3-5d1a-1e65-8c9b85c9ca02@oracle.com> On 2/4/19 5:30 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Looks good in general. > > Just a couple minor comments below. > > I hope, you will update the copyright years before the push. Hi Serguei,? Thanks for reviewing this. Yes, I update the copyright years in my commit script. > > > http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html > > ? Nice test! > 37 import java.lang.reflect.*; > 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; > 39 import java.lang.instrument.*; > ? The imports above can be re-ordered. Alphabetically? > > 44 return new String("public class B" + count + " {" + > 45 " public static void compiledMethod() { " + > 46 " try{" + > 47 " Thread.currentThread().sleep(1); " + > 48 " } catch(InterruptedException ie) {" + > 49 " }" + > 50 " }" + > 51 "}"); > ? Not clear, why sleep is needed here. > Yes, the sleep was there so that the compiler didn't optimize away the function.? I didn't put a print because it would print too many times. Thanks, Coleen > > Thanks, > Serguei > > > On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >> Added the serviceability-dev back. >> >> Thanks, >> Serguei >> >> >> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>> >>> The links. >>> Thanks, >>> Coleen >>> >>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>> >>>> *This change touches the AOT and code cache code.? I tried to >>>> describe it in the comments in the RFE.? Basically, for >>>> redefinition, we walk the code cache per class redefined in order >>>> to find evol_method dependencies, then deoptimize if we find them, >>>> and then walk the code cache again to mark the deoptimized nmethods >>>> as not_entrant. >>>> >>>> I replaced this with only marking any nmethods for the class's >>>> methods to deoptimize (following InstanceKlass::_methods), also >>>> marking aot methods dependent on the class, and then doing the code >>>> cache walk to follow the evol_method dependencies at the end of >>>> redefinition for all the classes.?? The new code uses the >>>> Method::is_old() flag rather than comparing each method in the >>>> InstanceKlass.? Then deoptimization and marking not_entrant is done >>>> once at the end of the redefinition as well. >>>> >>>> Tested with tier1-6, all the redefinition tests locally: >>>> >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>> >&jvmti.out >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>> >&redefine.out >>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>> >>>> new test, and JMH test (see CR for results). >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Feb 5 02:28:40 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 21:28:40 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> Message-ID: <7e4fa698-40cf-47b4-7eb3-ae1716ce939f@oracle.com> On 2/4/19 6:05 PM, David Holmes wrote: > On 5/02/2019 8:30 am, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Looks good in general. >> >> Just a couple minor comments below. >> >> I hope, you will update the copyright years before the push. >> >> >> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html >> >> >> ?? Nice test! >> >> ?? 37 import java.lang.reflect.*; >> ?? 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; >> ?? 39 import java.lang.instrument.*; >> >> ?? The imports above can be re-ordered. >> >> ?? 44???????? return new String("public class B" + count + " {" + >> ?? 45???????????????? "?? public static void compiledMethod() { " + >> ?? 46???????????????? "?????? try{" + >> ?? 47???????????????? " Thread.currentThread().sleep(1); " + >> ?? 48???????????????? "?????? } catch(InterruptedException ie) {" + >> ?? 49???????????????? "?????? }" + >> ?? 50???????????????? "?? }" + >> ?? 51???????????????? "}"); >> >> ?? Not clear, why sleep is needed here. > > Presumably just to give it some code and consume some time. Yes and so it wouldn't be optimized away. > > Nit: But it should just be: > > Thread.sleep(1) > > not > > Thread.currentThread().sleep(1); > Got it. Thanks, Coleen > sleep is a static method and as with all Thread static methods always > applies to the current thread. > > David > >> >> Thanks, >> Serguei >> >> >> On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >>> Added the serviceability-dev back. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>>> >>>> The links. >>>> Thanks, >>>> Coleen >>>> >>>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>>> >>>>> *This change touches the AOT and code cache code.? I tried to >>>>> describe it in the comments in the RFE.? Basically, for >>>>> redefinition, we walk the code cache per class redefined in order >>>>> to find evol_method dependencies, then deoptimize if we find them, >>>>> and then walk the code cache again to mark the deoptimized >>>>> nmethods as not_entrant. >>>>> >>>>> I replaced this with only marking any nmethods for the class's >>>>> methods to deoptimize (following InstanceKlass::_methods), also >>>>> marking aot methods dependent on the class, and then doing the >>>>> code cache walk to follow the evol_method dependencies at the end >>>>> of redefinition for all the classes. The new code uses the >>>>> Method::is_old() flag rather than comparing each method in the >>>>> InstanceKlass.? Then deoptimization and marking not_entrant is >>>>> done once at the end of the redefinition as well. >>>>> >>>>> Tested with tier1-6, all the redefinition tests locally: >>>>> >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>>> >&jvmti.out >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>>> >&redefine.out >>>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>>> >>>>> new test, and JMH test (see CR for results). >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> From coleen.phillimore at oracle.com Tue Feb 5 03:32:37 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 22:32:37 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> <33a1dbcb-d7c3-5d1a-1e65-8c9b85c9ca02@oracle.com> Message-ID: <676e9102-4cea-acfb-48ab-3feb7f41f4c3@oracle.com> Thanks Serguei! Coleen On 2/4/19 9:32 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > > On 2/4/19 18:26, coleen.phillimore at oracle.com wrote: >> >> >> On 2/4/19 5:30 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> Looks good in general. >>> >>> Just a couple minor comments below. >>> >>> I hope, you will update the copyright years before the push. >> >> Hi Serguei,? Thanks for reviewing this. >> >> Yes, I update the copyright years in my commit script. >>> >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html >>> >>> ? Nice test! >>> 37 import java.lang.reflect.*; >>> 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; >>> 39 import java.lang.instrument.*; >>> ? The imports above can be re-ordered. >> >> Alphabetically? > > Yes. (No need in another webrev) > >>> >>> 44 return new String("public class B" + count + " {" + >>> 45 " public static void compiledMethod() { " + >>> 46 " try{" + >>> 47 " Thread.currentThread().sleep(1); " + >>> 48 " } catch(InterruptedException ie) {" + >>> 49 " }" + >>> 50 " }" + >>> 51 "}"); >>> ? Not clear, why sleep is needed here. >>> >> >> Yes, the sleep was there so that the compiler didn't optimize away >> the function.? I didn't put a print because it would print too many >> times. > > Okay. > I hate, I placed this comment. :) > > Thanks, > Serguei > > >> Thanks, >> Coleen >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >>>> Added the serviceability-dev back. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>>>> >>>>> The links. >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>>>> >>>>>> *This change touches the AOT and code cache code.? I tried to >>>>>> describe it in the comments in the RFE. Basically, for >>>>>> redefinition, we walk the code cache per class redefined in order >>>>>> to find evol_method dependencies, then deoptimize if we find >>>>>> them, and then walk the code cache again to mark the deoptimized >>>>>> nmethods as not_entrant. >>>>>> >>>>>> I replaced this with only marking any nmethods for the class's >>>>>> methods to deoptimize (following InstanceKlass::_methods), also >>>>>> marking aot methods dependent on the class, and then doing the >>>>>> code cache walk to follow the evol_method dependencies at the end >>>>>> of redefinition for all the classes.?? The new code uses the >>>>>> Method::is_old() flag rather than comparing each method in the >>>>>> InstanceKlass.? Then deoptimization and marking not_entrant is >>>>>> done once at the end of the redefinition as well. >>>>>> >>>>>> Tested with tier1-6, all the redefinition tests locally: >>>>>> >>>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>>>> >&jvmti.out >>>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>>>> >&redefine.out >>>>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>>>> >>>>>> new test, and JMH test (see CR for results). >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> >> > From patricio.chilano.mateo at oracle.com Tue Feb 5 04:03:37 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Mon, 4 Feb 2019 23:03:37 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> Message-ID: <3295f7a4-0fa8-eb30-1114-985c0f8b9bab@oracle.com> On 2/4/19 7:06 PM, David Holmes wrote: > v6 incremental looks good to me. Thanks David! Patricio > Thanks, > David > ----- > > On 5/02/2019 6:57 am, Patricio Chilano wrote: >> Hi Dan, >> >> Here is v06. It also contains David's suggested changes for >> assert_owner(), and based on your correction about declaring pointers >> I fixed one in ThreadBlockInVMWithDeadlockCheck declaration. Files >> mutex.cpp and mutex.hpp have different styles of "pointer to" >> declarations so except the one you mentioned I didn't try to fix them >> all since I don't know if changing all of them to " * " is the right >> approach. >> >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ >> >> Thanks, >> Patricio >> >> On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: >>> On 2/4/19 2:40 PM, Patricio Chilano wrote: >>>> Hi Dan, >>>> >>>> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>>>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>>>> Hi all, >>>>>> >>>>>> Here is v05: >>>>>> >>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>>>> >>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>> ??? L295: // - When transitioning in (constructor), it checks for >>>>> safepoints without blocking, i.e calls >>>>> ??????? nit - s/i.e /i.e., / >>>>> ??????? (You missed the change from my v04 review) >>>> Done! I did made the change s/having to block/blocking from your >>>> review but didn't see the extra comma you added after i.e. >>> >>> Extra period and extra comma... I'm a font/typography nut... :-) >>> >>> >>>> >>>>> L299: class ThreadBlockinVMWithDeadlockCheck : public >>>>> ThreadStateTransition { >>>>> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >>>>> Monitor** in_flight_monitor_adr) >>>>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>>>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>>>> ??????? Lower case 'i' -> 'I' to match the >>>>> CamelCastStyleInOtherHelpers. >>>> Done. >>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> ??? L36: static inline void assert_owner(Thread *owner, Thread >>>>> *thread) { >>>>> ??????? nit - the predominant style in this file is ' * ' (space >>>>> on each side of '*') >>>> Ok, is that the style that we are supposed to follow in general ? >>>> Otherwise I can change all the ones that do not match the preferred >>>> style. >>> >>> That's a good question. The general rule is to follow the >>> predominant style in the file. However, I'm not sure what >>> the HotSpot recommended style is (I used to know this...). >>> >>> >>>> >>>>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" >>>>> INTPTR_FORMAT, >>>>> ??????? Another possible style of mesg: >>>>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", >>>>> expect=" INTPTR_FORMAT, >>>> I like more the first style, but if you really prefer the second >>>> one I can change it. >>> >>> I'm okay with what you have. >>> >>> >>>> >>>>> ThreadBlockinVMWithDeadlockCheck renames to >>>>> ThreadBlockInVMWithDeadlockCheck in >>>>> ??? this file also. >>>> Done. >>>> >>>>> src/hotspot/share/runtime/mutex.hpp >>>>> ??? No comments. >>>>> >>>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>>> ??? L83: ? if (!uses_thread_local_poll() || >>>>> local_poll_armed(thread)) { >>>>> ??????? Did you decide this line does not need a comment at all? >>>> How about adding the following comment based on your previous email: >>>> >>>> // If using thread local polls, we should not check the >>>> // global_poll() and callback via block() if the VMThread >>>> // has not yet armed the local poll. Otherwise, when used in >>>> // combination with should_block(), the latter could miss >>>> // detecting the same safepoint that this method would detect >>>> // if only checking global polls. >>> >>> I'm good with that comment. >>> >>> Dan >>> >>> >>>> >>>> >>>> Patricio >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Tested tiers 1-6. >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>> >>>>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have >>>>>>>>>>> a good suggestion. >>>>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut >>>>>>>>>>> is rather unwieldy. ;-) But the "Lock" part really doesn't >>>>>>>>>>> mean anything. So your suggestion of >>>>>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big >>>>>>>>>>> improvement to me. :) >>>>>>>>>> >>>>>>>>>> How about ThreadBlockInVMForLock ??? This answers the >>>>>>>>>> question "why" this class, vs. "what" this class does. Since >>>>>>>>>> the latter can change. >>>>>>>>> I like that name. Is that name okay with you David? >>>>>>>> >>>>>>>> Sorry no. "Lock" still adds zero information about when/why you >>>>>>>> would use this. It's used within Monitor::lock and >>>>>>>> Monitor::wait so is not specific to "locking" even in that >>>>>>>> class. This is about blocking in the VM and we need to know >>>>>>>> what this version does differently to the existing TBIVM. There >>>>>>>> are lots of different types of "locking" in the VM and we don't >>>>>>>> use this with them. >>>>>>>> >>>>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! >>>>>>>> ;-) >>>>>>> >>>>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>>>> >>>>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>>>> >>>>>>> ThreadBlockinVMWithDeadlockCheck >>>>>>> ThreadBlockinVMWithDeadlockChk >>>>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>>>> >>>>>>> Just pick a name and run with it... :-) >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Patricio >>>>>>>>>> thanks, >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> First, thanks for all the many weeks of work you've put >>>>>>>>>>>>>>> into this, pulling together a number of ideas from >>>>>>>>>>>>>>> different people to make it all work! >>>>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>>>>> implementation? : ) >>>>>>>>>>>>> >>>>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>>>> >>>>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>>>> Full: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code >>>>>>>>>>>>>>> which is masking the actual difference between the two >>>>>>>>>>>>>>> wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>>>>> behaviour without having to duplicate so much of this >>>>>>>>>>>>>>> code. In any case the semantics of ThreadLockBlockInVM >>>>>>>>>>>>>>> needs to be described. >>>>>>>>>>>>>> I could do it with one extra argument, but I would need >>>>>>>>>>>>>> to add two extra branches in transition_and_fence(), one >>>>>>>>>>>>>> to decide if I'm in the Monitor case to avoid calling >>>>>>>>>>>>>> SafepointMechanism::block_if_requested() directly and >>>>>>>>>>>>>> another one to actually decide if I'm transitioning in or >>>>>>>>>>>>>> out, since the actions to perform are different. I think >>>>>>>>>>>>>> it is easier to read without adding new conditionals, and >>>>>>>>>>>>>> also we will save those extra branches, but if you think >>>>>>>>>>>>>> it's better this way I can change it. >>>>>>>>>>>>> >>>>>>>>>>>>> I would like something that tells me more clearly how this >>>>>>>>>>>>> new transition helper differs from the existing TBIVM. >>>>>>>>>>>>> Sharing the code between them and using different args >>>>>>>>>>>>> would be one way. Documenting the difference in comments >>>>>>>>>>>>> would be another. Your choice. >>>>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>>>> >>>>>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>>>> >>>>>>>>>>>>> That's not quite conveying the semantics. The problem is >>>>>>>>>>>>> that the semantics we are changing compared to TBIVM are >>>>>>>>>>>>> not evident in the TBIVM name. If TBIVM was actually >>>>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>>>>> transition would obviously be >>>>>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps that >>>>>>>>>>>>> lengthy, but clear name would be okay anyway? >>>>>>>>>>>> Not convinced on that name since we are blocking at >>>>>>>>>>>> safepoints in the destructor. Based on the comments I added >>>>>>>>>>>> how about ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>>>>> conditions for deadlocks). >>>>>>>>>>>> >>>>>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>>>>> preempt_by_safepoint don't really convey to me what >>>>>>>>>>>>>>> happens - what is being "preempted" here? I would >>>>>>>>>>>>>>> suggest a more direct Monitor::release_for_safepoint >>>>>>>>>>>>>> Changed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not >>>>>>>>>>>>>>> even sure if we need bother at all with the one logging >>>>>>>>>>>>>>> statement that is present. >>>>>>>>>>>>>> I added it to eventually track unbounded try locks. Not >>>>>>>>>>>>>> sure I follow you with the name, isn't that how we name >>>>>>>>>>>>>> this monitors? I tried to differentiate them from Java >>>>>>>>>>>>>> monitors. What about just "monitor"? >>>>>>>>>>>>> >>>>>>>>>>>>> How about vmmonitor ? >>>>>>>>>>>> Ok, changed. >>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>>>>> safepoint checks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Apart from renaming this as suggested above, aren't >>>>>>>>>>>>>>> there any suitable assertions we should have here? >>>>>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner >>>>>>>>>>>>>>> == Thread::current? >>>>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>>>>> Asserting safepoint-in-progress does not really work >>>>>>>>>>>>>> because _state could change to _not_synchronized right >>>>>>>>>>>>>> after you checked for it in TLBIVM. >>>>>>>>>>>>> >>>>>>>>>>>>> Okay. >>>>>>>>>>>>> >>>>>>>>>>>>>>> Nit: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>>>>> issue. The second line should indent to the first comma, >>>>>>>>>>>>>>> but that will make the second line extend way past 80 >>>>>>>>>>>>>>> columns. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>>>> _owner==Thread::current() into its own function or macro >>>>>>>>>>>>>>> to avoid the repetition. >>>>>>>>>>>>>> Corrected indentation based on Dan's reply to align with >>>>>>>>>>>>>> _owner. >>>>>>>>>>>>> >>>>>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>>>>> continuation of the same argument being passed to the >>>>>>>>>>>>> assert "function". But I'm okay with Dan's suggestion. >>>>>>>>>>>>> >>>>>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>>>>> still be good to avoid the repetition. >>>>>>>>>>>> Ok, added new function assert_owned_by_self(). I could >>>>>>>>>>>> change it to assert_owner(Thread*) and use it for the NULL >>>>>>>>>>>> case too unifying the printed messages to something like >>>>>>>>>>>> "invalid owner: owner=" INTPTR_FORMAT ", should be:" >>>>>>>>>>>> INTPTR_FORMAT. What do you think? >>>>>>>>>>>> >>>>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>>>>> Dan's comments. >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>>>> ??? } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>>>> Removed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can >>>>>>>>>>>>>>> just be a PlatformMonitor now. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This needs to be resolved before committing. Some of the >>>>>>>>>>>>>>> existing commentary on what raw monitors are needs to be >>>>>>>>>>>>>>> retained. Not clear if we need to set the _owner field >>>>>>>>>>>>>>> or can just skip it. >>>>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>>>> >>>>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java >>>>>>>>>>>>>> threads via JVM_RawMonitorEnter. >>>>>>>>>>>>>> // >>>>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>>>>> interoperate properly with the native >>>>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>>>>> >>>>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace >>>>>>>>>>>>> them with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>>>>> wouldn't hurt. >>>>>>>>>>>>> >>>>>>>>>>>>> It's useful for checking usage errors, but we won't have >>>>>>>>>>>>> that if we replace with PlatformMonitor, so may as well >>>>>>>>>>>>> drop it now IMO. >>>>>>>>>>>> Ok, I added asserts that _owner should be NULL after >>>>>>>>>>>> acquiring it and before releasing it though. >>>>>>>>>>>> >>>>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>>>>> destructor being called? >>>>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>>>> >>>>>>>>>>>>> No need - assume other people have a better understanding >>>>>>>>>>>>> of C++ than I do :) >>>>>>>>>>>> >>>>>>>>>>>> Below is version v04, which also contains a correction >>>>>>>>>>>> pointed out off-list by Robbin to do a local poll first in >>>>>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using >>>>>>>>>>>> local polls. Since the thread local poll is armed after >>>>>>>>>>>> changing _state to _synchronizing, if we only do a global >>>>>>>>>>>> poll in the TLBIVM constructor we could detect there is a >>>>>>>>>>>> safepoint in progress and callback but when coming back in >>>>>>>>>>>> the destructor SafepointMechanism::should_block() could >>>>>>>>>>>> miss detecting the safepoint in progress since that method >>>>>>>>>>>> checks first for local polls. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Patricio >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for looking into this! Waiting on your comments to >>>>>>>>>>>>>> send v04. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Patricio >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From kim.barrett at oracle.com Tue Feb 5 04:15:39 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 4 Feb 2019 23:15:39 -0500 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: <65CB5B51-4BBA-4CD3-8DA8-27BAB8211648@oracle.com> References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> <65CB5B51-4BBA-4CD3-8DA8-27BAB8211648@oracle.com> Message-ID: <6FCE4FD0-352C-47AE-BE8E-2C2BEFCD0B25@oracle.com> > On Feb 1, 2019, at 4:48 PM, Kim Barrett wrote: > >> On Feb 1, 2019, at 2:55 AM, David Holmes wrote: >>> In retrospect, ?MSVC? seems like a better choice than MSVCPP. >> >> Agreed. > > Especially since it seems what I actually used in the webrev was MSCPP :) > > Let?s go with ?MSVC? then. Here are the updated webrevs, using "MSVC". full: http://cr.openjdk.java.net/~kbarrett/8218164/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8218164/open.01.inc/ From david.holmes at oracle.com Tue Feb 5 05:02:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 15:02:48 +1000 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: <6FCE4FD0-352C-47AE-BE8E-2C2BEFCD0B25@oracle.com> References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> <65CB5B51-4BBA-4CD3-8DA8-27BAB8211648@oracle.com> <6FCE4FD0-352C-47AE-BE8E-2C2BEFCD0B25@oracle.com> Message-ID: <8d465582-fc33-c938-e72d-3882f3e7e90b@oracle.com> On 5/02/2019 2:15 pm, Kim Barrett wrote: >> On Feb 1, 2019, at 4:48 PM, Kim Barrett wrote: >> >>> On Feb 1, 2019, at 2:55 AM, David Holmes wrote: >>>> In retrospect, ?MSVC? seems like a better choice than MSVCPP. >>> >>> Agreed. >> >> Especially since it seems what I actually used in the webrev was MSCPP :) >> >> Let?s go with ?MSVC? then. > > Here are the updated webrevs, using "MSVC". > full: http://cr.openjdk.java.net/~kbarrett/8218164/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8218164/open.01.inc/ Looks good. Thanks, David From dean.long at oracle.com Tue Feb 5 06:50:48 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 4 Feb 2019 22:50:48 -0800 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> Message-ID: Could you move this code: ???? // Mark dependent AOT nmethods, which are only found via the class redefined. ???? AOTLoader::mark_evol_dependent_methods(ik); into this function: ???? CodeCache::mark_for_evol_deoptimization(ik) The rest looks good. dl On 2/4/19 7:08 AM, coleen.phillimore at oracle.com wrote: > Summary: Walk code cache and deoptimize once per redefinition.* > > *This change touches the AOT and code cache code.? I tried to describe > it in the comments in the RFE.? Basically, for redefinition, we walk > the code cache per class redefined in order to find evol_method > dependencies, then deoptimize if we find them, and then walk the code > cache again to mark the deoptimized nmethods as not_entrant. > > I replaced this with only marking any nmethods for the class's methods > to deoptimize (following InstanceKlass::_methods), also marking aot > methods dependent on the class, and then doing the code cache walk to > follow the evol_method dependencies at the end of redefinition for all > the classes.?? The new code uses the Method::is_old() flag rather than > comparing each method in the InstanceKlass.? Then deoptimization and > marking not_entrant is done once at the end of the redefinition as well. > > Tested with tier1-6, all the redefinition tests locally: > > make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out > make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out > make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests > >&redefine.out > make test TEST=open/test/jdk/java/lang/instrument >&instrument.out > > new test, and JMH test (see CR for results). > > Thanks, > Coleen > > From dean.long at oracle.com Tue Feb 5 07:17:46 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 4 Feb 2019 23:17:46 -0800 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: References: <91C357F2-1E1F-4813-9AF2-7B7B7E45E1F3@oracle.com> Message-ID: <49f8ca77-3785-f18b-2888-963c26089c69@oracle.com> On 2/4/19 10:45 AM, Lois Foltan wrote: >> Does jvmci use the method_type field?? Or was removing this assertion >> the only change needed? > This was the only instance of the use.? However, I have sent email to > Dean Long and cc'd Vladimir Kozlov asking for review. It looks fine to me. dl From kim.barrett at oracle.com Tue Feb 5 07:18:13 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Feb 2019 02:18:13 -0500 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: <8d465582-fc33-c938-e72d-3882f3e7e90b@oracle.com> References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> <65CB5B51-4BBA-4CD3-8DA8-27BAB8211648@oracle.com> <6FCE4FD0-352C-47AE-BE8E-2C2BEFCD0B25@oracle.com> <8d465582-fc33-c938-e72d-3882f3e7e90b@oracle.com> Message-ID: > On Feb 5, 2019, at 12:02 AM, David Holmes wrote: > > On 5/02/2019 2:15 pm, Kim Barrett wrote: >>> On Feb 1, 2019, at 4:48 PM, Kim Barrett wrote: >>> >>>> On Feb 1, 2019, at 2:55 AM, David Holmes wrote: >>>>> In retrospect, ?MSVC? seems like a better choice than MSVCPP. >>>> >>>> Agreed. >>> >>> Especially since it seems what I actually used in the webrev was MSCPP :) >>> >>> Let?s go with ?MSVC? then. >> Here are the updated webrevs, using "MSVC". >> full: http://cr.openjdk.java.net/~kbarrett/8218164/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8218164/open.01.inc/ > > Looks good. > > Thanks, > David Thanks. From robbin.ehn at oracle.com Tue Feb 5 07:58:17 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 5 Feb 2019 08:58:17 +0100 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <85a81ed8-da43-5ab1-1f62-8be4aca3c54d@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> Message-ID: <48d87b36-fd6c-e50d-1684-06eaddd8de90@oracle.com> On 2019-02-05 01:06, David Holmes wrote: > v6 incremental looks good to me. +1 /Robbin > > Thanks, > David > ----- > > On 5/02/2019 6:57 am, Patricio Chilano wrote: >> Hi Dan, >> >> Here is v06. It also contains David's suggested changes for assert_owner(), >> and based on your correction about declaring pointers I fixed one in >> ThreadBlockInVMWithDeadlockCheck declaration. Files mutex.cpp and mutex.hpp >> have different styles of "pointer to" declarations so except the one you >> mentioned I didn't try to fix them all since I don't know if changing all of >> them to " * " is the right approach. >> >> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev >> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ >> >> Thanks, >> Patricio >> >> On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: >>> On 2/4/19 2:40 PM, Patricio Chilano wrote: >>>> Hi Dan, >>>> >>>> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>>>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>>>> Hi all, >>>>>> >>>>>> Here is v05: >>>>>> >>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>>>> >>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>> ??? L295: // - When transitioning in (constructor), it checks for >>>>> safepoints without blocking, i.e calls >>>>> ??????? nit - s/i.e /i.e., / >>>>> ??????? (You missed the change from my v04 review) >>>> Done! I did made the change s/having to block/blocking from your review but >>>> didn't see the extra comma you added after i.e. >>> >>> Extra period and extra comma... I'm a font/typography nut... :-) >>> >>> >>>> >>>>> L299: class ThreadBlockinVMWithDeadlockCheck : public ThreadStateTransition { >>>>> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, Monitor** >>>>> in_flight_monitor_adr) >>>>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>>>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>>>> ??????? Lower case 'i' -> 'I' to match the CamelCastStyleInOtherHelpers. >>>> Done. >>>> >>>>> src/hotspot/share/runtime/mutex.cpp >>>>> ??? L36: static inline void assert_owner(Thread *owner, Thread *thread) { >>>>> ??????? nit - the predominant style in this file is ' * ' (space on each >>>>> side of '*') >>>> Ok, is that the style that we are supposed to follow in general ? Otherwise >>>> I can change all the ones that do not match the preferred style. >>> >>> That's a good question. The general rule is to follow the >>> predominant style in the file. However, I'm not sure what >>> the HotSpot recommended style is (I used to know this...). >>> >>> >>>> >>>>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should be=" >>>>> INTPTR_FORMAT, >>>>> ??????? Another possible style of mesg: >>>>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", expect=" >>>>> INTPTR_FORMAT, >>>> I like more the first style, but if you really prefer the second one I can >>>> change it. >>> >>> I'm okay with what you have. >>> >>> >>>> >>>>> ThreadBlockinVMWithDeadlockCheck renames to >>>>> ThreadBlockInVMWithDeadlockCheck in >>>>> ??? this file also. >>>> Done. >>>> >>>>> src/hotspot/share/runtime/mutex.hpp >>>>> ??? No comments. >>>>> >>>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>>> ??? L83: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { >>>>> ??????? Did you decide this line does not need a comment at all? >>>> How about adding the following comment based on your previous email: >>>> >>>> // If using thread local polls, we should not check the >>>> // global_poll() and callback via block() if the VMThread >>>> // has not yet armed the local poll. Otherwise, when used in >>>> // combination with should_block(), the latter could miss >>>> // detecting the same safepoint that this method would detect >>>> // if only checking global polls. >>> >>> I'm good with that comment. >>> >>> Dan >>> >>> >>>> >>>> >>>> Patricio >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Tested tiers 1-6. >>>>>> >>>>>> Thanks, >>>>>> Patricio >>>>>> >>>>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have a good >>>>>>>>>>> suggestion. >>>>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut is rather >>>>>>>>>>> unwieldy. ;-) But the "Lock" part really doesn't mean anything. So >>>>>>>>>>> your suggestion of ThreadBlockinVMWithDeadlockPrevention seems a big >>>>>>>>>>> improvement to me. :) >>>>>>>>>> >>>>>>>>>> How about ThreadBlockInVMForLock ??? This answers the question "why" >>>>>>>>>> this class, vs. "what" this class does. Since the latter can change. >>>>>>>>> I like that name. Is that name okay with you David? >>>>>>>> >>>>>>>> Sorry no. "Lock" still adds zero information about when/why you would >>>>>>>> use this. It's used within Monitor::lock and Monitor::wait so is not >>>>>>>> specific to "locking" even in that class. This is about blocking in the >>>>>>>> VM and we need to know what this version does differently to the >>>>>>>> existing TBIVM. There are lots of different types of "locking" in the VM >>>>>>>> and we don't use this with them. >>>>>>>> >>>>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush Dan! ;-) >>>>>>> >>>>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>>>> >>>>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>>>> >>>>>>> ThreadBlockinVMWithDeadlockCheck >>>>>>> ThreadBlockinVMWithDeadlockChk >>>>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>>>> >>>>>>> Just pick a name and run with it... :-) >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Patricio >>>>>>>>>> thanks, >>>>>>>>>> Coleen >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> First, thanks for all the many weeks of work you've put into >>>>>>>>>>>>>>> this, pulling together a number of ideas from different people to >>>>>>>>>>>>>>> make it all work! >>>>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor implementation? : ) >>>>>>>>>>>>> >>>>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>>>> >>>>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex code which is >>>>>>>>>>>>>>> masking the actual difference between the two wrappers to me. It >>>>>>>>>>>>>>> seems to me that an extra arg to transition_and_fence should >>>>>>>>>>>>>>> allow you to handle the new behaviour without having to duplicate >>>>>>>>>>>>>>> so much of this code. In any case the semantics of >>>>>>>>>>>>>>> ThreadLockBlockInVM needs to be described. >>>>>>>>>>>>>> I could do it with one extra argument, but I would need to add two >>>>>>>>>>>>>> extra branches in transition_and_fence(), one to decide if I'm in >>>>>>>>>>>>>> the Monitor case to avoid calling >>>>>>>>>>>>>> SafepointMechanism::block_if_requested() directly and another one >>>>>>>>>>>>>> to actually decide if I'm transitioning in or out, since the >>>>>>>>>>>>>> actions to perform are different. I think it is easier to read >>>>>>>>>>>>>> without adding new conditionals, and also we will save those extra >>>>>>>>>>>>>> branches, but if you think it's better this way I can change it. >>>>>>>>>>>>> >>>>>>>>>>>>> I would like something that tells me more clearly how this new >>>>>>>>>>>>> transition helper differs from the existing TBIVM. Sharing the code >>>>>>>>>>>>> between them and using different args would be one way. Documenting >>>>>>>>>>>>> the difference in comments would be another. Your choice. >>>>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>>>> >>>>>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM actually >>>>>>>>>>>>>>> refers to. I find the name quite jarring to read. >>>>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>>>> >>>>>>>>>>>>> That's not quite conveying the semantics. The problem is that the >>>>>>>>>>>>> semantics we are changing compared to TBIVM are not evident in the >>>>>>>>>>>>> TBIVM name. If TBIVM was actually >>>>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new transition >>>>>>>>>>>>> would obviously be ThreadBlockInVMWithoutSafepointBlocking - but >>>>>>>>>>>>> perhaps that lengthy, but clear name would be okay anyway? >>>>>>>>>>>> Not convinced on that name since we are blocking at safepoints in >>>>>>>>>>>> the destructor. Based on the comments I added how about >>>>>>>>>>>> ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>>>>> conditions for deadlocks). >>>>>>>>>>>> >>>>>>>>>>>>>>> On the subject of naming, do_preempt and preempt_by_safepoint >>>>>>>>>>>>>>> don't really convey to me what happens - what is being >>>>>>>>>>>>>>> "preempted" here? I would suggest a more direct >>>>>>>>>>>>>>> Monitor::release_for_safepoint >>>>>>>>>>>>>> Changed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp doesn't >>>>>>>>>>>>>>> relate to a "native" monitor?? Actually I'm not even sure if we >>>>>>>>>>>>>>> need bother at all with the one logging statement that is present. >>>>>>>>>>>>>> I added it to eventually track unbounded try locks. Not sure I >>>>>>>>>>>>>> follow you with the name, isn't that how we name this monitors? I >>>>>>>>>>>>>> tried to differentiate them from Java monitors. What about just >>>>>>>>>>>>>> "monitor"? >>>>>>>>>>>>> >>>>>>>>>>>>> How about vmmonitor ? >>>>>>>>>>>> Ok, changed. >>>>>>>>>>>> >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * self) { >>>>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow safepoint >>>>>>>>>>>>>>> checks. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Apart from renaming this as suggested above, aren't there any >>>>>>>>>>>>>>> suitable assertions we should have here? safepoint-in-progress or >>>>>>>>>>>>>>> handshake-in-progress? _owner == Thread::current? >>>>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. Asserting >>>>>>>>>>>>>> safepoint-in-progress does not really work because _state could >>>>>>>>>>>>>> change to _not_synchronized right after you checked for it in TLBIVM. >>>>>>>>>>>>> >>>>>>>>>>>>> Okay. >>>>>>>>>>>>> >>>>>>>>>>>>>>> Nit: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: owner=" >>>>>>>>>>>>>>> INTPTR_FORMAT >>>>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, p2i(_owner), >>>>>>>>>>>>>>> p2i(Thread::current())); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation issue. The >>>>>>>>>>>>>>> second line should indent to the first comma, but that will make >>>>>>>>>>>>>>> the second line extend way past 80 columns. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>>>> _owner==Thread::current() into its own function or macro to avoid >>>>>>>>>>>>>>> the repetition. >>>>>>>>>>>>>> Corrected indentation based on Dan's reply to align with _owner. >>>>>>>>>>>>> >>>>>>>>>>>>> I though it should indent to the comma because it is a continuation >>>>>>>>>>>>> of the same argument being passed to the assert "function". But I'm >>>>>>>>>>>>> okay with Dan's suggestion. >>>>>>>>>>>>> >>>>>>>>>>>>> Factoring it into its own little function or macro would still be >>>>>>>>>>>>> good to avoid the repetition. >>>>>>>>>>>> Ok, added new function assert_owned_by_self(). I could change it to >>>>>>>>>>>> assert_owner(Thread*) and use it for the NULL case too unifying the >>>>>>>>>>>> printed messages to something like "invalid owner: owner=" >>>>>>>>>>>> INTPTR_FORMAT ", should be:" INTPTR_FORMAT. What do you think? >>>>>>>>>>>> >>>>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This needs to be returned to its original place as per Dan's >>>>>>>>>>>>>>> comments. >>>>>>>>>>>>>> Done. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>>>> ??? } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>>>> Removed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can just be a >>>>>>>>>>>>>>> PlatformMonitor now. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This needs to be resolved before committing. Some of the existing >>>>>>>>>>>>>>> commentary on what raw monitors are needs to be retained. Not >>>>>>>>>>>>>>> clear if we need to set the _owner field or can just skip it. >>>>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>>>> >>>>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by non-Java threads >>>>>>>>>>>>>> via JVM_RawMonitorEnter. >>>>>>>>>>>>>> // >>>>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will interoperate >>>>>>>>>>>>>> properly with the native >>>>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>>>>> >>>>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace them with >>>>>>>>>>>>> direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it wouldn't >>>>>>>>>>>>>> hurt. >>>>>>>>>>>>> >>>>>>>>>>>>> It's useful for checking usage errors, but we won't have that if we >>>>>>>>>>>>> replace with PlatformMonitor, so may as well drop it now IMO. >>>>>>>>>>>> Ok, I added asserts that _owner should be NULL after acquiring it >>>>>>>>>>>> and before releasing it though. >>>>>>>>>>>> >>>>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" INTPTR_FORMAT, >>>>>>>>>>>>>>> p2i(_owner)); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will this automatically result in the PlatformMonitor destructor >>>>>>>>>>>>>>> being called? >>>>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>>>> >>>>>>>>>>>>> No need - assume other people have a better understanding of C++ >>>>>>>>>>>>> than I do :) >>>>>>>>>>>> >>>>>>>>>>>> Below is version v04, which also contains a correction pointed out >>>>>>>>>>>> off-list by Robbin to do a local poll first in >>>>>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are using local >>>>>>>>>>>> polls. Since the thread local poll is armed after changing _state to >>>>>>>>>>>> _synchronizing, if we only do a global poll in the TLBIVM >>>>>>>>>>>> constructor we could detect there is a safepoint in progress and >>>>>>>>>>>> callback but when coming back in the destructor >>>>>>>>>>>> SafepointMechanism::should_block() could miss detecting the >>>>>>>>>>>> safepoint in progress since that method checks first for local polls. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Patricio >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks for looking into this! Waiting on your comments to send v04. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Patricio >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> From goetz.lindenmaier at sap.com Tue Feb 5 08:59:10 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Feb 2019 08:59:10 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi Matthias, The demangle fix is kind of preliminary, but to get the compiler working it is acceptable to skip this code for now. The old xlc stuff is good to be removed. Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN altogether and replace its only use by USE_XLC_BUILTINS? Also, I think it makes sense to put #if __IBMCPP__ < 1000 #error "xlc < 10 not supported" #endif into the file. Probably we should even check for having at least xlc 12. Best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Montag, 4. Februar 2019 12:36 > To: David Holmes ; 'hotspot- > dev at openjdk.java.net' ; > 'magnus.ihse.bursie at oracle.com' > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi David, I want to follow your suggestion ?? . > I adjusted the comment , see globalDefinitions_xlc.hpp . > > Additionally I removed a strange ifdef handling pre-xlc10 versions that are > not useful today any more for OpenJDK > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > Best regards, Matthias > > > > > -----Original Message----- > > From: David Holmes > > Sent: Freitag, 1. Februar 2019 13:49 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' ; > > 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi Matthias, > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > New webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > I don't think it makes sense to keep the comment which was obviously > > copied from the gcc file: > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > __null to > > // integer variable will cause gcc warning. Use NULL_WORD in places > > where a > > // pointer is stored as integer value. On some platforms, > > sizeof(intptr_t) > > > // sizeof(void*), so here we want something which is integer type, > > but has the > > // same size as a pointer. > > > > Rather something like: > > > > // Some platform/tool-chain combinations can't assign NULL to an integer > > // type so we define NULL_WORD to use in those contexts. For xlc they > > // are the same. > > > > Thanks, > > David > > > > From thomas.schatzl at oracle.com Tue Feb 5 12:45:46 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 05 Feb 2019 13:45:46 +0100 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: <6FCE4FD0-352C-47AE-BE8E-2C2BEFCD0B25@oracle.com> References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> <65CB5B51-4BBA-4CD3-8DA8-27BAB8211648@oracle.com> <6FCE4FD0-352C-47AE-BE8E-2C2BEFCD0B25@oracle.com> Message-ID: <01ba1b15035e6c6b3cd99065d1e0fe12e8a81c7e.camel@oracle.com> Hi, On Mon, 2019-02-04 at 23:15 -0500, Kim Barrett wrote: > > On Feb 1, 2019, at 4:48 PM, Kim Barrett > > wrote: > > > > > On Feb 1, 2019, at 2:55 AM, David Holmes > > > wrote: > > > > In retrospect, ?MSVC? seems like a better choice than MSVCPP. > > > > > > Agreed. > > > > Especially since it seems what I actually used in the webrev was > > MSCPP :) > > > > Let?s go with ?MSVC? then. > > Here are the updated webrevs, using "MSVC". > full: http://cr.openjdk.java.net/~kbarrett/8218164/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8218164/open.01.inc/ > ship it. Thomas From coleen.phillimore at oracle.com Tue Feb 5 13:52:13 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 5 Feb 2019 08:52:13 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> Message-ID: Yes, I can do that.? Thank you for reviewing this! Coleen On 2/5/19 1:50 AM, dean.long at oracle.com wrote: > Could you move this code: > > ???? // Mark dependent AOT nmethods, which are only found via the > class redefined. > ???? AOTLoader::mark_evol_dependent_methods(ik); > > into this function: > > ???? CodeCache::mark_for_evol_deoptimization(ik) > > The rest looks good. > > dl > > On 2/4/19 7:08 AM, coleen.phillimore at oracle.com wrote: >> Summary: Walk code cache and deoptimize once per redefinition.* >> >> *This change touches the AOT and code cache code.? I tried to >> describe it in the comments in the RFE.? Basically, for redefinition, >> we walk the code cache per class redefined in order to find >> evol_method dependencies, then deoptimize if we find them, and then >> walk the code cache again to mark the deoptimized nmethods as >> not_entrant. >> >> I replaced this with only marking any nmethods for the class's >> methods to deoptimize (following InstanceKlass::_methods), also >> marking aot methods dependent on the class, and then doing the code >> cache walk to follow the evol_method dependencies at the end of >> redefinition for all the classes.?? The new code uses the >> Method::is_old() flag rather than comparing each method in the >> InstanceKlass.? Then deoptimization and marking not_entrant is done >> once at the end of the redefinition as well. >> >> Tested with tier1-6, all the redefinition tests locally: >> >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >> >&redefine.out >> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >> >> new test, and JMH test (see CR for results). >> >> Thanks, >> Coleen >> >> > From coleen.phillimore at oracle.com Tue Feb 5 13:59:07 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 5 Feb 2019 08:59:07 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <48d87b36-fd6c-e50d-1684-06eaddd8de90@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> <48d87b36-fd6c-e50d-1684-06eaddd8de90@oracle.com> Message-ID: <3f59a36a-9eb7-0f98-961c-6d77cad7f3e7@oracle.com> This looks great! Coleen On 2/5/19 2:58 AM, Robbin Ehn wrote: > On 2019-02-05 01:06, David Holmes wrote: >> v6 incremental looks good to me. > > +1 > > /Robbin > >> >> Thanks, >> David >> ----- >> >> On 5/02/2019 6:57 am, Patricio Chilano wrote: >>> Hi Dan, >>> >>> Here is v06. It also contains David's suggested changes for >>> assert_owner(), and based on your correction about declaring >>> pointers I fixed one in ThreadBlockInVMWithDeadlockCheck >>> declaration. Files mutex.cpp and mutex.hpp have different styles of >>> "pointer to" declarations so except the one you mentioned I didn't >>> try to fix them all since I don't know if changing all of them to " >>> * " is the right approach. >>> >>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev >>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ >>> >>> Thanks, >>> Patricio >>> >>> On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: >>>> On 2/4/19 2:40 PM, Patricio Chilano wrote: >>>>> Hi Dan, >>>>> >>>>> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>>>>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Here is v05: >>>>>>> >>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>>>>> >>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>> ??? L295: // - When transitioning in (constructor), it checks for >>>>>> safepoints without blocking, i.e calls >>>>>> ??????? nit - s/i.e /i.e., / >>>>>> ??????? (You missed the change from my v04 review) >>>>> Done! I did made the change s/having to block/blocking from your >>>>> review but didn't see the extra comma you added after i.e. >>>> >>>> Extra period and extra comma... I'm a font/typography nut... :-) >>>> >>>> >>>>> >>>>>> L299: class ThreadBlockinVMWithDeadlockCheck : public >>>>>> ThreadStateTransition { >>>>>> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >>>>>> Monitor** in_flight_monitor_adr) >>>>>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>>>>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>>>>> ??????? Lower case 'i' -> 'I' to match the >>>>>> CamelCastStyleInOtherHelpers. >>>>> Done. >>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> ??? L36: static inline void assert_owner(Thread *owner, Thread >>>>>> *thread) { >>>>>> ??????? nit - the predominant style in this file is ' * ' (space >>>>>> on each side of '*') >>>>> Ok, is that the style that we are supposed to follow in general ? >>>>> Otherwise I can change all the ones that do not match the >>>>> preferred style. >>>> >>>> That's a good question. The general rule is to follow the >>>> predominant style in the file. However, I'm not sure what >>>> the HotSpot recommended style is (I used to know this...). >>>> >>>> >>>>> >>>>>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should >>>>>> be=" INTPTR_FORMAT, >>>>>> ??????? Another possible style of mesg: >>>>>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", >>>>>> expect=" INTPTR_FORMAT, >>>>> I like more the first style, but if you really prefer the second >>>>> one I can change it. >>>> >>>> I'm okay with what you have. >>>> >>>> >>>>> >>>>>> ThreadBlockinVMWithDeadlockCheck renames to >>>>>> ThreadBlockInVMWithDeadlockCheck in >>>>>> ??? this file also. >>>>> Done. >>>>> >>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>> ??? No comments. >>>>>> >>>>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>>>> ??? L83: ? if (!uses_thread_local_poll() || >>>>>> local_poll_armed(thread)) { >>>>>> ??????? Did you decide this line does not need a comment at all? >>>>> How about adding the following comment based on your previous email: >>>>> >>>>> // If using thread local polls, we should not check the >>>>> // global_poll() and callback via block() if the VMThread >>>>> // has not yet armed the local poll. Otherwise, when used in >>>>> // combination with should_block(), the latter could miss >>>>> // detecting the same safepoint that this method would detect >>>>> // if only checking global polls. >>>> >>>> I'm good with that comment. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> >>>>> Patricio >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> Tested tiers 1-6. >>>>>>> >>>>>>> Thanks, >>>>>>> Patricio >>>>>>> >>>>>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have >>>>>>>>>>>> a good suggestion. >>>>>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut >>>>>>>>>>>> is rather unwieldy. ;-) But the "Lock" part really doesn't >>>>>>>>>>>> mean anything. So your suggestion of >>>>>>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big >>>>>>>>>>>> improvement to me. :) >>>>>>>>>>> >>>>>>>>>>> How about ThreadBlockInVMForLock ??? This answers the >>>>>>>>>>> question "why" this class, vs. "what" this class does. Since >>>>>>>>>>> the latter can change. >>>>>>>>>> I like that name. Is that name okay with you David? >>>>>>>>> >>>>>>>>> Sorry no. "Lock" still adds zero information about when/why >>>>>>>>> you would use this. It's used within Monitor::lock and >>>>>>>>> Monitor::wait so is not specific to "locking" even in that >>>>>>>>> class. This is about blocking in the VM and we need to know >>>>>>>>> what this version does differently to the existing TBIVM. >>>>>>>>> There are lots of different types of "locking" in the VM and >>>>>>>>> we don't use this with them. >>>>>>>>> >>>>>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush >>>>>>>>> Dan! ;-) >>>>>>>> >>>>>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>>>>> >>>>>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>>>>> >>>>>>>> ThreadBlockinVMWithDeadlockCheck >>>>>>>> ThreadBlockinVMWithDeadlockChk >>>>>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>>>>> >>>>>>>> Just pick a name and run with it... :-) >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Patricio >>>>>>>>>>> thanks, >>>>>>>>>>> Coleen >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> First, thanks for all the many weeks of work you've put >>>>>>>>>>>>>>>> into this, pulling together a number of ideas from >>>>>>>>>>>>>>>> different people to make it all work! >>>>>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>>>>>> implementation? : ) >>>>>>>>>>>>>> >>>>>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>>>>> Full: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex >>>>>>>>>>>>>>>> code which is masking the actual difference between the >>>>>>>>>>>>>>>> two wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>>>>>> behaviour without having to duplicate so much of this >>>>>>>>>>>>>>>> code. In any case the semantics of ThreadLockBlockInVM >>>>>>>>>>>>>>>> needs to be described. >>>>>>>>>>>>>>> I could do it with one extra argument, but I would need >>>>>>>>>>>>>>> to add two extra branches in transition_and_fence(), one >>>>>>>>>>>>>>> to decide if I'm in the Monitor case to avoid calling >>>>>>>>>>>>>>> SafepointMechanism::block_if_requested() directly and >>>>>>>>>>>>>>> another one to actually decide if I'm transitioning in >>>>>>>>>>>>>>> or out, since the actions to perform are different. I >>>>>>>>>>>>>>> think it is easier to read without adding new >>>>>>>>>>>>>>> conditionals, and also we will save those extra >>>>>>>>>>>>>>> branches, but if you think it's better this way I can >>>>>>>>>>>>>>> change it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would like something that tells me more clearly how >>>>>>>>>>>>>> this new transition helper differs from the existing >>>>>>>>>>>>>> TBIVM. Sharing the code between them and using different >>>>>>>>>>>>>> args would be one way. Documenting the difference in >>>>>>>>>>>>>> comments would be another. Your choice. >>>>>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>>>>> >>>>>>>>>>>>>> That's not quite conveying the semantics. The problem is >>>>>>>>>>>>>> that the semantics we are changing compared to TBIVM are >>>>>>>>>>>>>> not evident in the TBIVM name. If TBIVM was actually >>>>>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>>>>>> transition would obviously be >>>>>>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps >>>>>>>>>>>>>> that lengthy, but clear name would be okay anyway? >>>>>>>>>>>>> Not convinced on that name since we are blocking at >>>>>>>>>>>>> safepoints in the destructor. Based on the comments I >>>>>>>>>>>>> added how about ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>>>>>> conditions for deadlocks). >>>>>>>>>>>>> >>>>>>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>>>>>> preempt_by_safepoint don't really convey to me what >>>>>>>>>>>>>>>> happens - what is being "preempted" here? I would >>>>>>>>>>>>>>>> suggest a more direct Monitor::release_for_safepoint >>>>>>>>>>>>>>> Changed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not >>>>>>>>>>>>>>>> even sure if we need bother at all with the one logging >>>>>>>>>>>>>>>> statement that is present. >>>>>>>>>>>>>>> I added it to eventually track unbounded try locks. Not >>>>>>>>>>>>>>> sure I follow you with the name, isn't that how we name >>>>>>>>>>>>>>> this monitors? I tried to differentiate them from Java >>>>>>>>>>>>>>> monitors. What about just "monitor"? >>>>>>>>>>>>>> >>>>>>>>>>>>>> How about vmmonitor ? >>>>>>>>>>>>> Ok, changed. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * >>>>>>>>>>>>>>>> self) { >>>>>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>>>>>> safepoint checks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Apart from renaming this as suggested above, aren't >>>>>>>>>>>>>>>> there any suitable assertions we should have here? >>>>>>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner >>>>>>>>>>>>>>>> == Thread::current? >>>>>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>>>>>> Asserting safepoint-in-progress does not really work >>>>>>>>>>>>>>> because _state could change to _not_synchronized right >>>>>>>>>>>>>>> after you checked for it in TLBIVM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Okay. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nit: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, >>>>>>>>>>>>>>>> p2i(_owner), p2i(Thread::current())); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>>>>>> issue. The second line should indent to the first >>>>>>>>>>>>>>>> comma, but that will make the second line extend way >>>>>>>>>>>>>>>> past 80 columns. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>>>>> _owner==Thread::current() into its own function or >>>>>>>>>>>>>>>> macro to avoid the repetition. >>>>>>>>>>>>>>> Corrected indentation based on Dan's reply to align with >>>>>>>>>>>>>>> _owner. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>>>>>> continuation of the same argument being passed to the >>>>>>>>>>>>>> assert "function". But I'm okay with Dan's suggestion. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>>>>>> still be good to avoid the repetition. >>>>>>>>>>>>> Ok, added new function assert_owned_by_self(). I could >>>>>>>>>>>>> change it to assert_owner(Thread*) and use it for the NULL >>>>>>>>>>>>> case too unifying the printed messages to something like >>>>>>>>>>>>> "invalid owner: owner=" INTPTR_FORMAT ", should be:" >>>>>>>>>>>>> INTPTR_FORMAT. What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>>>>>> Dan's comments. >>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>>>>> ??? } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>>>>> Removed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can >>>>>>>>>>>>>>>> just be a PlatformMonitor now. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This needs to be resolved before committing. Some of >>>>>>>>>>>>>>>> the existing commentary on what raw monitors are needs >>>>>>>>>>>>>>>> to be retained. Not clear if we need to set the _owner >>>>>>>>>>>>>>>> field or can just skip it. >>>>>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by >>>>>>>>>>>>>>> non-Java threads via JVM_RawMonitorEnter. >>>>>>>>>>>>>>> // >>>>>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>>>>>> interoperate properly with the native >>>>>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace >>>>>>>>>>>>>> them with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>>>>>> wouldn't hurt. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's useful for checking usage errors, but we won't have >>>>>>>>>>>>>> that if we replace with PlatformMonitor, so may as well >>>>>>>>>>>>>> drop it now IMO. >>>>>>>>>>>>> Ok, I added asserts that _owner should be NULL after >>>>>>>>>>>>> acquiring it and before releasing it though. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>>>>>> destructor being called? >>>>>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>>>>> >>>>>>>>>>>>>> No need - assume other people have a better understanding >>>>>>>>>>>>>> of C++ than I do :) >>>>>>>>>>>>> >>>>>>>>>>>>> Below is version v04, which also contains a correction >>>>>>>>>>>>> pointed out off-list by Robbin to do a local poll first in >>>>>>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are >>>>>>>>>>>>> using local polls. Since the thread local poll is armed >>>>>>>>>>>>> after changing _state to _synchronizing, if we only do a >>>>>>>>>>>>> global poll in the TLBIVM constructor we could detect >>>>>>>>>>>>> there is a safepoint in progress and callback but when >>>>>>>>>>>>> coming back in the destructor >>>>>>>>>>>>> SafepointMechanism::should_block() could miss detecting >>>>>>>>>>>>> the safepoint in progress since that method checks first >>>>>>>>>>>>> for local polls. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>>>>> Inc: >>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Patricio >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for looking into this! Waiting on your comments >>>>>>>>>>>>>>> to send v04. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Patricio >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> From kim.barrett at oracle.com Tue Feb 5 14:35:56 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 5 Feb 2019 09:35:56 -0500 Subject: RFR: 8218164: Improve local control of compiler warnings In-Reply-To: <01ba1b15035e6c6b3cd99065d1e0fe12e8a81c7e.camel@oracle.com> References: <3EB7AC16-D549-4C77-B854-0468F5E61A5C@oracle.com> <33505f89-0c31-122f-3146-c650a2891f64@oracle.com> <88BBBE5D-DF0A-4281-ACC9-47ADB9519ABB@oracle.com> <65CB5B51-4BBA-4CD3-8DA8-27BAB8211648@oracle.com> <6FCE4FD0-352C-47AE-BE8E-2C2BEFCD0B25@oracle.com> <01ba1b15035e6c6b3cd99065d1e0fe12e8a81c7e.camel@oracle.com> Message-ID: <92AC71E4-3305-448A-9D12-CF8554260652@oracle.com> > On Feb 5, 2019, at 7:45 AM, Thomas Schatzl wrote: >> >> Here are the updated webrevs, using "MSVC". >> full: http://cr.openjdk.java.net/~kbarrett/8218164/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8218164/open.01.inc/ >> > > ship it. > > Thomas Thanks. From patricio.chilano.mateo at oracle.com Tue Feb 5 15:00:02 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Tue, 5 Feb 2019 10:00:02 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <48d87b36-fd6c-e50d-1684-06eaddd8de90@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> <48d87b36-fd6c-e50d-1684-06eaddd8de90@oracle.com> Message-ID: <94861304-12b2-3b4f-6d0c-2bc1945b46b6@oracle.com> On 2/5/19 2:58 AM, Robbin Ehn wrote: > On 2019-02-05 01:06, David Holmes wrote: >> v6 incremental looks good to me. > > +1 Thanks Robbin! Patricio > /Robbin > >> >> Thanks, >> David >> ----- >> >> On 5/02/2019 6:57 am, Patricio Chilano wrote: >>> Hi Dan, >>> >>> Here is v06. It also contains David's suggested changes for >>> assert_owner(), and based on your correction about declaring >>> pointers I fixed one in ThreadBlockInVMWithDeadlockCheck >>> declaration. Files mutex.cpp and mutex.hpp have different styles of >>> "pointer to" declarations so except the one you mentioned I didn't >>> try to fix them all since I don't know if changing all of them to " >>> * " is the right approach. >>> >>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev >>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ >>> >>> Thanks, >>> Patricio >>> >>> On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: >>>> On 2/4/19 2:40 PM, Patricio Chilano wrote: >>>>> Hi Dan, >>>>> >>>>> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>>>>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Here is v05: >>>>>>> >>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>>>>> >>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>> ??? L295: // - When transitioning in (constructor), it checks for >>>>>> safepoints without blocking, i.e calls >>>>>> ??????? nit - s/i.e /i.e., / >>>>>> ??????? (You missed the change from my v04 review) >>>>> Done! I did made the change s/having to block/blocking from your >>>>> review but didn't see the extra comma you added after i.e. >>>> >>>> Extra period and extra comma... I'm a font/typography nut... :-) >>>> >>>> >>>>> >>>>>> L299: class ThreadBlockinVMWithDeadlockCheck : public >>>>>> ThreadStateTransition { >>>>>> ??? L312: ? ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >>>>>> Monitor** in_flight_monitor_adr) >>>>>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>>>>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>>>>> ??????? Lower case 'i' -> 'I' to match the >>>>>> CamelCastStyleInOtherHelpers. >>>>> Done. >>>>> >>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>> ??? L36: static inline void assert_owner(Thread *owner, Thread >>>>>> *thread) { >>>>>> ??????? nit - the predominant style in this file is ' * ' (space >>>>>> on each side of '*') >>>>> Ok, is that the style that we are supposed to follow in general ? >>>>> Otherwise I can change all the ones that do not match the >>>>> preferred style. >>>> >>>> That's a good question. The general rule is to follow the >>>> predominant style in the file. However, I'm not sure what >>>> the HotSpot recommended style is (I used to know this...). >>>> >>>> >>>>> >>>>>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should >>>>>> be=" INTPTR_FORMAT, >>>>>> ??????? Another possible style of mesg: >>>>>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", >>>>>> expect=" INTPTR_FORMAT, >>>>> I like more the first style, but if you really prefer the second >>>>> one I can change it. >>>> >>>> I'm okay with what you have. >>>> >>>> >>>>> >>>>>> ThreadBlockinVMWithDeadlockCheck renames to >>>>>> ThreadBlockInVMWithDeadlockCheck in >>>>>> ??? this file also. >>>>> Done. >>>>> >>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>> ??? No comments. >>>>>> >>>>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>>>> ??? L83: ? if (!uses_thread_local_poll() || >>>>>> local_poll_armed(thread)) { >>>>>> ??????? Did you decide this line does not need a comment at all? >>>>> How about adding the following comment based on your previous email: >>>>> >>>>> // If using thread local polls, we should not check the >>>>> // global_poll() and callback via block() if the VMThread >>>>> // has not yet armed the local poll. Otherwise, when used in >>>>> // combination with should_block(), the latter could miss >>>>> // detecting the same safepoint that this method would detect >>>>> // if only checking global polls. >>>> >>>> I'm good with that comment. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> >>>>> Patricio >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> Tested tiers 1-6. >>>>>>> >>>>>>> Thanks, >>>>>>> Patricio >>>>>>> >>>>>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't have >>>>>>>>>>>> a good suggestion. >>>>>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut >>>>>>>>>>>> is rather unwieldy. ;-) But the "Lock" part really doesn't >>>>>>>>>>>> mean anything. So your suggestion of >>>>>>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big >>>>>>>>>>>> improvement to me. :) >>>>>>>>>>> >>>>>>>>>>> How about ThreadBlockInVMForLock ??? This answers the >>>>>>>>>>> question "why" this class, vs. "what" this class does. Since >>>>>>>>>>> the latter can change. >>>>>>>>>> I like that name. Is that name okay with you David? >>>>>>>>> >>>>>>>>> Sorry no. "Lock" still adds zero information about when/why >>>>>>>>> you would use this. It's used within Monitor::lock and >>>>>>>>> Monitor::wait so is not specific to "locking" even in that >>>>>>>>> class. This is about blocking in the VM and we need to know >>>>>>>>> what this version does differently to the existing TBIVM. >>>>>>>>> There are lots of different types of "locking" in the VM and >>>>>>>>> we don't use this with them. >>>>>>>>> >>>>>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush >>>>>>>>> Dan! ;-) >>>>>>>> >>>>>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>>>>> >>>>>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>>>>> >>>>>>>> ThreadBlockinVMWithDeadlockCheck >>>>>>>> ThreadBlockinVMWithDeadlockChk >>>>>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>>>>> >>>>>>>> Just pick a name and run with it... :-) >>>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Patricio >>>>>>>>>>> thanks, >>>>>>>>>>> Coleen >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> First, thanks for all the many weeks of work you've put >>>>>>>>>>>>>>>> into this, pulling together a number of ideas from >>>>>>>>>>>>>>>> different people to make it all work! >>>>>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>>>>>> implementation? : ) >>>>>>>>>>>>>> >>>>>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>>>>> Full: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex >>>>>>>>>>>>>>>> code which is masking the actual difference between the >>>>>>>>>>>>>>>> two wrappers to me. It seems to me that an extra arg to >>>>>>>>>>>>>>>> transition_and_fence should allow you to handle the new >>>>>>>>>>>>>>>> behaviour without having to duplicate so much of this >>>>>>>>>>>>>>>> code. In any case the semantics of ThreadLockBlockInVM >>>>>>>>>>>>>>>> needs to be described. >>>>>>>>>>>>>>> I could do it with one extra argument, but I would need >>>>>>>>>>>>>>> to add two extra branches in transition_and_fence(), one >>>>>>>>>>>>>>> to decide if I'm in the Monitor case to avoid calling >>>>>>>>>>>>>>> SafepointMechanism::block_if_requested() directly and >>>>>>>>>>>>>>> another one to actually decide if I'm transitioning in >>>>>>>>>>>>>>> or out, since the actions to perform are different. I >>>>>>>>>>>>>>> think it is easier to read without adding new >>>>>>>>>>>>>>> conditionals, and also we will save those extra >>>>>>>>>>>>>>> branches, but if you think it's better this way I can >>>>>>>>>>>>>>> change it. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would like something that tells me more clearly how >>>>>>>>>>>>>> this new transition helper differs from the existing >>>>>>>>>>>>>> TBIVM. Sharing the code between them and using different >>>>>>>>>>>>>> args would be one way. Documenting the difference in >>>>>>>>>>>>>> comments would be another. Your choice. >>>>>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also I'm unclear what the "Lock" in ThreadLockBlockInVM >>>>>>>>>>>>>>>> actually refers to. I find the name quite jarring to read. >>>>>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>>>>> >>>>>>>>>>>>>> That's not quite conveying the semantics. The problem is >>>>>>>>>>>>>> that the semantics we are changing compared to TBIVM are >>>>>>>>>>>>>> not evident in the TBIVM name. If TBIVM was actually >>>>>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>>>>>> transition would obviously be >>>>>>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps >>>>>>>>>>>>>> that lengthy, but clear name would be okay anyway? >>>>>>>>>>>>> Not convinced on that name since we are blocking at >>>>>>>>>>>>> safepoints in the destructor. Based on the comments I >>>>>>>>>>>>> added how about ThreadBlockinVMWithDeadlockPrevention ? or >>>>>>>>>>>>> ThreadBlockinVMWithPreemption? (as in eliminate one of the >>>>>>>>>>>>> conditions for deadlocks). >>>>>>>>>>>>> >>>>>>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>>>>>> preempt_by_safepoint don't really convey to me what >>>>>>>>>>>>>>>> happens - what is being "preempted" here? I would >>>>>>>>>>>>>>>> suggest a more direct Monitor::release_for_safepoint >>>>>>>>>>>>>>> Changed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm not >>>>>>>>>>>>>>>> even sure if we need bother at all with the one logging >>>>>>>>>>>>>>>> statement that is present. >>>>>>>>>>>>>>> I added it to eventually track unbounded try locks. Not >>>>>>>>>>>>>>> sure I follow you with the name, isn't that how we name >>>>>>>>>>>>>>> this monitors? I tried to differentiate them from Java >>>>>>>>>>>>>>> monitors. What about just "monitor"? >>>>>>>>>>>>>> >>>>>>>>>>>>>> How about vmmonitor ? >>>>>>>>>>>>> Ok, changed. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * >>>>>>>>>>>>>>>> self) { >>>>>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>>>>>> safepoint checks. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Apart from renaming this as suggested above, aren't >>>>>>>>>>>>>>>> there any suitable assertions we should have here? >>>>>>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner >>>>>>>>>>>>>>>> == Thread::current? >>>>>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>>>>>> Asserting safepoint-in-progress does not really work >>>>>>>>>>>>>>> because _state could change to _not_synchronized right >>>>>>>>>>>>>>> after you checked for it in TLBIVM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Okay. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nit: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, >>>>>>>>>>>>>>>> p2i(_owner), p2i(Thread::current())); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>>>>>> issue. The second line should indent to the first >>>>>>>>>>>>>>>> comma, but that will make the second line extend way >>>>>>>>>>>>>>>> past 80 columns. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>>>>> _owner==Thread::current() into its own function or >>>>>>>>>>>>>>>> macro to avoid the repetition. >>>>>>>>>>>>>>> Corrected indentation based on Dan's reply to align with >>>>>>>>>>>>>>> _owner. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>>>>>> continuation of the same argument being passed to the >>>>>>>>>>>>>> assert "function". But I'm okay with Dan's suggestion. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>>>>>> still be good to avoid the repetition. >>>>>>>>>>>>> Ok, added new function assert_owned_by_self(). I could >>>>>>>>>>>>> change it to assert_owner(Thread*) and use it for the NULL >>>>>>>>>>>>> case too unifying the printed messages to something like >>>>>>>>>>>>> "invalid owner: owner=" INTPTR_FORMAT ", should be:" >>>>>>>>>>>>> INTPTR_FORMAT. What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>>>>>> Dan's comments. >>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>>>>> ??? } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>>>>> Removed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor can >>>>>>>>>>>>>>>> just be a PlatformMonitor now. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This needs to be resolved before committing. Some of >>>>>>>>>>>>>>>> the existing commentary on what raw monitors are needs >>>>>>>>>>>>>>>> to be retained. Not clear if we need to set the _owner >>>>>>>>>>>>>>>> field or can just skip it. >>>>>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by >>>>>>>>>>>>>>> non-Java threads via JVM_RawMonitorEnter. >>>>>>>>>>>>>>> // >>>>>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>>>>>> interoperate properly with the native >>>>>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>>>>> // native Mutex-Monitors simply as a matter of convenience. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace >>>>>>>>>>>>>> them with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least it >>>>>>>>>>>>>>> wouldn't hurt. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It's useful for checking usage errors, but we won't have >>>>>>>>>>>>>> that if we replace with PlatformMonitor, so may as well >>>>>>>>>>>>>> drop it now IMO. >>>>>>>>>>>>> Ok, I added asserts that _owner should be NULL after >>>>>>>>>>>>> acquiring it and before releasing it though. >>>>>>>>>>>>> >>>>>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>>>>>> destructor being called? >>>>>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>>>>> >>>>>>>>>>>>>> No need - assume other people have a better understanding >>>>>>>>>>>>>> of C++ than I do :) >>>>>>>>>>>>> >>>>>>>>>>>>> Below is version v04, which also contains a correction >>>>>>>>>>>>> pointed out off-list by Robbin to do a local poll first in >>>>>>>>>>>>> SafepointMechanism::callback_if_safepoint() if we are >>>>>>>>>>>>> using local polls. Since the thread local poll is armed >>>>>>>>>>>>> after changing _state to _synchronizing, if we only do a >>>>>>>>>>>>> global poll in the TLBIVM constructor we could detect >>>>>>>>>>>>> there is a safepoint in progress and callback but when >>>>>>>>>>>>> coming back in the destructor >>>>>>>>>>>>> SafepointMechanism::should_block() could miss detecting >>>>>>>>>>>>> the safepoint in progress since that method checks first >>>>>>>>>>>>> for local polls. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>>>>> Inc: >>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Patricio >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for looking into this! Waiting on your comments >>>>>>>>>>>>>>> to send v04. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Patricio >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> From patricio.chilano.mateo at oracle.com Tue Feb 5 15:02:23 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Tue, 5 Feb 2019 10:02:23 -0500 Subject: RFR: 8210832: Remove sneaky locking in class Monitor In-Reply-To: <3f59a36a-9eb7-0f98-961c-6d77cad7f3e7@oracle.com> References: <7e111d06-a29a-67cc-4967-958da08766a4@oracle.com> <4562855b-fa0e-9f70-da0f-00f84984d78f@oracle.com> <384133a1-c2e0-11f2-6890-798c3646222f@oracle.com> <6654f80f-9932-28f4-63f6-eece68966a56@oracle.com> <45718944-1e85-e979-2843-f93b9e6bb9b6@oracle.com> <6ad146c6-618e-ab21-fcf4-12668a8d78ab@oracle.com> <531eb85a-b9e6-ed28-f615-da86a0fc2412@oracle.com> <74409422-9545-f327-d806-9acf5ec8f39b@oracle.com> <827bca8a-358a-c643-d4da-0c7439421d32@oracle.com> <14fae70a-8403-4ca7-a48a-d28db6197b8c@oracle.com> <48d87b36-fd6c-e50d-1684-06eaddd8de90@oracle.com> <3f59a36a-9eb7-0f98-961c-6d77cad7f3e7@oracle.com> Message-ID: On 2/5/19 8:59 AM, coleen.phillimore at oracle.com wrote: > This looks great! Thanks Coleen! Patricio > Coleen > > On 2/5/19 2:58 AM, Robbin Ehn wrote: >> On 2019-02-05 01:06, David Holmes wrote: >>> v6 incremental looks good to me. >> >> +1 >> >> /Robbin >> >>> >>> Thanks, >>> David >>> ----- >>> >>> On 5/02/2019 6:57 am, Patricio Chilano wrote: >>>> Hi Dan, >>>> >>>> Here is v06. It also contains David's suggested changes for >>>> assert_owner(), and based on your correction about declaring >>>> pointers I fixed one in ThreadBlockInVMWithDeadlockCheck >>>> declaration. Files mutex.cpp and mutex.hpp have different styles of >>>> "pointer to" declarations so except the one you mentioned I didn't >>>> try to fix them all since I don't know if changing all of them to " >>>> * " is the right approach. >>>> >>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/inc/webrev >>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v06/webrev/ >>>> >>>> Thanks, >>>> Patricio >>>> >>>> On 2/4/19 2:47 PM, Daniel D. Daugherty wrote: >>>>> On 2/4/19 2:40 PM, Patricio Chilano wrote: >>>>>> Hi Dan, >>>>>> >>>>>> On 2/4/19 2:05 PM, Daniel D. Daugherty wrote: >>>>>>> On 2/3/19 8:46 PM, Patricio Chilano wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Here is v05: >>>>>>>> >>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/webrev/ >>>>>>>> Inc: http://cr.openjdk.java.net/~pchilanomate/8210832/v05/inc/ >>>>>>> >>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>> ??? L295: // - When transitioning in (constructor), it checks >>>>>>> for safepoints without blocking, i.e calls >>>>>>> ??????? nit - s/i.e /i.e., / >>>>>>> ??????? (You missed the change from my v04 review) >>>>>> Done! I did made the change s/having to block/blocking from your >>>>>> review but didn't see the extra comma you added after i.e. >>>>> >>>>> Extra period and extra comma... I'm a font/typography nut... :-) >>>>> >>>>> >>>>>> >>>>>>> L299: class ThreadBlockinVMWithDeadlockCheck : public >>>>>>> ThreadStateTransition { >>>>>>> ??? L312: ThreadBlockinVMWithDeadlockCheck(JavaThread *thread, >>>>>>> Monitor** in_flight_monitor_adr) >>>>>>> ??? L326: ? ~ThreadBlockinVMWithDeadlockCheck() { >>>>>>> s/ThreadBlockinVMWithDeadlockCheck/ThreadBlockInVMWithDeadlockCheck/ >>>>>>> >>>>>>> ??????? Lower case 'i' -> 'I' to match the >>>>>>> CamelCastStyleInOtherHelpers. >>>>>> Done. >>>>>> >>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>> ??? L36: static inline void assert_owner(Thread *owner, Thread >>>>>>> *thread) { >>>>>>> ??????? nit - the predominant style in this file is ' * ' (space >>>>>>> on each side of '*') >>>>>> Ok, is that the style that we are supposed to follow in general ? >>>>>> Otherwise I can change all the ones that do not match the >>>>>> preferred style. >>>>> >>>>> That's a good question. The general rule is to follow the >>>>> predominant style in the file. However, I'm not sure what >>>>> the HotSpot recommended style is (I used to know this...). >>>>> >>>>> >>>>>> >>>>>>> L38: ???????? "invalid owner: owner=" INTPTR_FORMAT ", should >>>>>>> be=" INTPTR_FORMAT, >>>>>>> ??????? Another possible style of mesg: >>>>>>> ????????????????? "invalid owner: actual=" INTPTR_FORMAT ", >>>>>>> expect=" INTPTR_FORMAT, >>>>>> I like more the first style, but if you really prefer the second >>>>>> one I can change it. >>>>> >>>>> I'm okay with what you have. >>>>> >>>>> >>>>>> >>>>>>> ThreadBlockinVMWithDeadlockCheck renames to >>>>>>> ThreadBlockInVMWithDeadlockCheck in >>>>>>> ??? this file also. >>>>>> Done. >>>>>> >>>>>>> src/hotspot/share/runtime/mutex.hpp >>>>>>> ??? No comments. >>>>>>> >>>>>>> src/hotspot/share/runtime/safepointMechanism.inline.hpp >>>>>>> ??? L83: ? if (!uses_thread_local_poll() || >>>>>>> local_poll_armed(thread)) { >>>>>>> ??????? Did you decide this line does not need a comment at all? >>>>>> How about adding the following comment based on your previous email: >>>>>> >>>>>> // If using thread local polls, we should not check the >>>>>> // global_poll() and callback via block() if the VMThread >>>>>> // has not yet armed the local poll. Otherwise, when used in >>>>>> // combination with should_block(), the latter could miss >>>>>> // detecting the same safepoint that this method would detect >>>>>> // if only checking global polls. >>>>> >>>>> I'm good with that comment. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> >>>>>> Patricio >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Tested tiers 1-6. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Patricio >>>>>>>> >>>>>>>> On 2/1/19 7:58 PM, Daniel D. Daugherty wrote: >>>>>>>>> On 2/1/19 7:49 PM, David Holmes wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2/02/2019 7:48 am, Patricio Chilano wrote: >>>>>>>>>>> On 2/1/19 4:28 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>>>>> In regards to the name ThreadLockBlockInVM ... I don't >>>>>>>>>>>>> have a good suggestion. >>>>>>>>>>>>> ThreadBlockInVMWithSafepointCheckingButOnlyBlockOnTheWayOut >>>>>>>>>>>>> is rather unwieldy. ;-) But the "Lock" part really doesn't >>>>>>>>>>>>> mean anything. So your suggestion of >>>>>>>>>>>>> ThreadBlockinVMWithDeadlockPrevention seems a big >>>>>>>>>>>>> improvement to me. :) >>>>>>>>>>>> >>>>>>>>>>>> How about ThreadBlockInVMForLock ??? This answers the >>>>>>>>>>>> question "why" this class, vs. "what" this class does. >>>>>>>>>>>> Since the latter can change. >>>>>>>>>>> I like that name. Is that name okay with you David? >>>>>>>>>> >>>>>>>>>> Sorry no. "Lock" still adds zero information about when/why >>>>>>>>>> you would use this. It's used within Monitor::lock and >>>>>>>>>> Monitor::wait so is not specific to "locking" even in that >>>>>>>>>> class. This is about blocking in the VM and we need to know >>>>>>>>>> what this version does differently to the existing TBIVM. >>>>>>>>>> There are lots of different types of "locking" in the VM and >>>>>>>>>> we don't use this with them. >>>>>>>>>> >>>>>>>>>> Dan can be a tie-breaker on this bikeshed. Grab your brush >>>>>>>>>> Dan! ;-) >>>>>>>>> >>>>>>>>> ThreadBlockInVMBecauseSneakyLockingIsEvil? >>>>>>>>> >>>>>>>>> ThreadBlockinVMWithDeadlockPrevention is okay. >>>>>>>>> >>>>>>>>> ThreadBlockinVMWithDeadlockCheck >>>>>>>>> ThreadBlockinVMWithDeadlockChk >>>>>>>>> ThreadBlockinVMWithDeadlockCk (David won't like this one :-) ) >>>>>>>>> >>>>>>>>> Just pick a name and run with it... :-) >>>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Patricio >>>>>>>>>>>> thanks, >>>>>>>>>>>> Coleen >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>> On 1/02/2019 3:05 pm, Patricio Chilano wrote: >>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 1/31/19 12:54 AM, David Holmes wrote: >>>>>>>>>>>>>>> On 31/01/2019 7:37 am, Patricio Chilano wrote: >>>>>>>>>>>>>>>> Hi David, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 1/30/19 2:29 AM, David Holmes wrote: >>>>>>>>>>>>>>>>> Hi Patricio, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> First, thanks for all the many weeks of work you've >>>>>>>>>>>>>>>>> put into this, pulling together a number of ideas from >>>>>>>>>>>>>>>>> different people to make it all work! >>>>>>>>>>>>>>>> Thanks! Credit to you for the PlatformMonitor >>>>>>>>>>>>>>>> implementation? : ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> :) Nothing innovative there. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've only got a few minor comments/suggestions. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 30/01/2019 10:24 am, Patricio Chilano wrote: >>>>>>>>>>>>>>>>>> Full: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/webrev/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v03/inc/webrev/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/hotspot/share/runtime/interfaceSupport.inline.hpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm very unclear how ThreadLockBlockInVM differs from >>>>>>>>>>>>>>>>> ThreadBlockInVM. You've duplicated a lot of complex >>>>>>>>>>>>>>>>> code which is masking the actual difference between >>>>>>>>>>>>>>>>> the two wrappers to me. It seems to me that an extra >>>>>>>>>>>>>>>>> arg to transition_and_fence should allow you to handle >>>>>>>>>>>>>>>>> the new behaviour without having to duplicate so much >>>>>>>>>>>>>>>>> of this code. In any case the semantics of >>>>>>>>>>>>>>>>> ThreadLockBlockInVM needs to be described. >>>>>>>>>>>>>>>> I could do it with one extra argument, but I would need >>>>>>>>>>>>>>>> to add two extra branches in transition_and_fence(), >>>>>>>>>>>>>>>> one to decide if I'm in the Monitor case to avoid >>>>>>>>>>>>>>>> calling SafepointMechanism::block_if_requested() >>>>>>>>>>>>>>>> directly and another one to actually decide if I'm >>>>>>>>>>>>>>>> transitioning in or out, since the actions to perform >>>>>>>>>>>>>>>> are different. I think it is easier to read without >>>>>>>>>>>>>>>> adding new conditionals, and also we will save those >>>>>>>>>>>>>>>> extra branches, but if you think it's better this way I >>>>>>>>>>>>>>>> can change it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would like something that tells me more clearly how >>>>>>>>>>>>>>> this new transition helper differs from the existing >>>>>>>>>>>>>>> TBIVM. Sharing the code between them and using different >>>>>>>>>>>>>>> args would be one way. Documenting the difference in >>>>>>>>>>>>>>> comments would be another. Your choice. >>>>>>>>>>>>>> Ok, I added a description on top of TLBIVM. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also I'm unclear what the "Lock" in >>>>>>>>>>>>>>>>> ThreadLockBlockInVM actually refers to. I find the >>>>>>>>>>>>>>>>> name quite jarring to read. >>>>>>>>>>>>>>>> What about changing it to ThreadBlockinMonitor? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That's not quite conveying the semantics. The problem is >>>>>>>>>>>>>>> that the semantics we are changing compared to TBIVM are >>>>>>>>>>>>>>> not evident in the TBIVM name. If TBIVM was actually >>>>>>>>>>>>>>> ThreadBlockInVMWithSafepointBlocking, then this new >>>>>>>>>>>>>>> transition would obviously be >>>>>>>>>>>>>>> ThreadBlockInVMWithoutSafepointBlocking - but perhaps >>>>>>>>>>>>>>> that lengthy, but clear name would be okay anyway? >>>>>>>>>>>>>> Not convinced on that name since we are blocking at >>>>>>>>>>>>>> safepoints in the destructor. Based on the comments I >>>>>>>>>>>>>> added how about ThreadBlockinVMWithDeadlockPrevention ? >>>>>>>>>>>>>> or ThreadBlockinVMWithPreemption? (as in eliminate one of >>>>>>>>>>>>>> the conditions for deadlocks). >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On the subject of naming, do_preempt and >>>>>>>>>>>>>>>>> preempt_by_safepoint don't really convey to me what >>>>>>>>>>>>>>>>> happens - what is being "preempted" here? I would >>>>>>>>>>>>>>>>> suggest a more direct Monitor::release_for_safepoint >>>>>>>>>>>>>>>> Changed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Logging: why "nativemonitor"? The logging in mutex.cpp >>>>>>>>>>>>>>>>> doesn't relate to a "native" monitor?? Actually I'm >>>>>>>>>>>>>>>>> not even sure if we need bother at all with the one >>>>>>>>>>>>>>>>> logging statement that is present. >>>>>>>>>>>>>>>> I added it to eventually track unbounded try locks. Not >>>>>>>>>>>>>>>> sure I follow you with the name, isn't that how we name >>>>>>>>>>>>>>>> this monitors? I tried to differentiate them from Java >>>>>>>>>>>>>>>> monitors. What about just "monitor"? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> How about vmmonitor ? >>>>>>>>>>>>>> Ok, changed. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> src/hotspot/share/runtime/mutex.cpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> void Monitor::lock_without_safepoint_check(Thread * >>>>>>>>>>>>>>>>> self) { >>>>>>>>>>>>>>>>> ? // Ensure that the Monitor does not require or allow >>>>>>>>>>>>>>>>> safepoint checks. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The comment there should only say "not require". >>>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> void Monitor::preempt_by_safepoint() { >>>>>>>>>>>>>>>>> ? _lock.unlock(); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Apart from renaming this as suggested above, aren't >>>>>>>>>>>>>>>>> there any suitable assertions we should have here? >>>>>>>>>>>>>>>>> safepoint-in-progress or handshake-in-progress? _owner >>>>>>>>>>>>>>>>> == Thread::current? >>>>>>>>>>>>>>>> Ok, I added an assertion that owner should be NULL. >>>>>>>>>>>>>>>> Asserting safepoint-in-progress does not really work >>>>>>>>>>>>>>>> because _state could change to _not_synchronized right >>>>>>>>>>>>>>>> after you checked for it in TLBIVM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Okay. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Nit: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> assert(_owner == Thread::current(), "should be equal: >>>>>>>>>>>>>>>>> owner=" INTPTR_FORMAT >>>>>>>>>>>>>>>>> ?????????????????? ", self=" INTPTR_FORMAT, >>>>>>>>>>>>>>>>> p2i(_owner), p2i(Thread::current())); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> with Dan's enhanced assertions there's an indentation >>>>>>>>>>>>>>>>> issue. The second line should indent to the first >>>>>>>>>>>>>>>>> comma, but that will make the second line extend way >>>>>>>>>>>>>>>>> past 80 columns. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Also you could factor that assertion for >>>>>>>>>>>>>>>>> _owner==Thread::current() into its own function or >>>>>>>>>>>>>>>>> macro to avoid the repetition. >>>>>>>>>>>>>>>> Corrected indentation based on Dan's reply to align >>>>>>>>>>>>>>>> with _owner. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I though it should indent to the comma because it is a >>>>>>>>>>>>>>> continuation of the same argument being passed to the >>>>>>>>>>>>>>> assert "function". But I'm okay with Dan's suggestion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Factoring it into its own little function or macro would >>>>>>>>>>>>>>> still be good to avoid the repetition. >>>>>>>>>>>>>> Ok, added new function assert_owned_by_self(). I could >>>>>>>>>>>>>> change it to assert_owner(Thread*) and use it for the >>>>>>>>>>>>>> NULL case too unifying the printed messages to something >>>>>>>>>>>>>> like "invalid owner: owner=" INTPTR_FORMAT ", should be:" >>>>>>>>>>>>>> INTPTR_FORMAT. What do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ?OSThreadWaitState osts(self->osthread(), false /* not >>>>>>>>>>>>>>>>> Object.wait() */); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This needs to be returned to its original place as per >>>>>>>>>>>>>>>>> Dan's comments. >>>>>>>>>>>>>>>> Done. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> ??? } else { >>>>>>>>>>>>>>>>> ????? Monitor::lock(self); >>>>>>>>>>>>>>>>> ??? } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You don't need Monitor:: here >>>>>>>>>>>>>>>> Removed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> // Temporary JVM_RawMonitor* support. A raw monitor >>>>>>>>>>>>>>>>> can just be a PlatformMonitor now. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This needs to be resolved before committing. Some of >>>>>>>>>>>>>>>>> the existing commentary on what raw monitors are needs >>>>>>>>>>>>>>>>> to be retained. Not clear if we need to set the _owner >>>>>>>>>>>>>>>>> field or can just skip it. >>>>>>>>>>>>>>>> Is it okay if I keep the following comments? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> // Yet another degenerate version of Monitor::lock() or >>>>>>>>>>>>>>>> lock_without_safepoint_check() >>>>>>>>>>>>>>>> // jvm_raw_lock() and _unlock() can be called by >>>>>>>>>>>>>>>> non-Java threads via JVM_RawMonitorEnter. >>>>>>>>>>>>>>>> // >>>>>>>>>>>>>>>> // There's no expectation that JVM_RawMonitors will >>>>>>>>>>>>>>>> interoperate properly with the native >>>>>>>>>>>>>>>> // Mutex-Monitor constructs.? We happen to implement >>>>>>>>>>>>>>>> JVM_RawMonitors in terms of >>>>>>>>>>>>>>>> // native Mutex-Monitors simply as a matter of >>>>>>>>>>>>>>>> convenience. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yep that's perfect. And as a future RFE we can replace >>>>>>>>>>>>>>> them with direct use of PlatformMonitor (or PlatformMutex). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I could keep setting the owner as _owner = >>>>>>>>>>>>>>>> Thread::current_or_null() in jvm_raw_lock(), at least >>>>>>>>>>>>>>>> it wouldn't hurt. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It's useful for checking usage errors, but we won't have >>>>>>>>>>>>>>> that if we replace with PlatformMonitor, so may as well >>>>>>>>>>>>>>> drop it now IMO. >>>>>>>>>>>>>> Ok, I added asserts that _owner should be NULL after >>>>>>>>>>>>>> acquiring it and before releasing it though. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Monitor::~Monitor() { >>>>>>>>>>>>>>>>> ? assert(_owner == NULL, "should be NULL: owner=" >>>>>>>>>>>>>>>>> INTPTR_FORMAT, p2i(_owner)); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Will this automatically result in the PlatformMonitor >>>>>>>>>>>>>>>>> destructor being called? >>>>>>>>>>>>>>>> Yes, should I add a comment to make it clear that >>>>>>>>>>>>>>>> ~PlatformMonitor() will be executed? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> No need - assume other people have a better >>>>>>>>>>>>>>> understanding of C++ than I do :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Below is version v04, which also contains a correction >>>>>>>>>>>>>> pointed out off-list by Robbin to do a local poll first >>>>>>>>>>>>>> in SafepointMechanism::callback_if_safepoint() if we are >>>>>>>>>>>>>> using local polls. Since the thread local poll is armed >>>>>>>>>>>>>> after changing _state to _synchronizing, if we only do a >>>>>>>>>>>>>> global poll in the TLBIVM constructor we could detect >>>>>>>>>>>>>> there is a safepoint in progress and callback but when >>>>>>>>>>>>>> coming back in the destructor >>>>>>>>>>>>>> SafepointMechanism::should_block() could miss detecting >>>>>>>>>>>>>> the safepoint in progress since that method checks first >>>>>>>>>>>>>> for local polls. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Full: http://cr.openjdk.java.net/~pchilanomate/8210832/v04/ >>>>>>>>>>>>>> Inc: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~pchilanomate/8210832/v04/inc/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Patricio >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for looking into this! Waiting on your comments >>>>>>>>>>>>>>>> to send v04. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Patricio >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> ----- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> > From lois.foltan at oracle.com Tue Feb 5 15:26:10 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 5 Feb 2019 10:26:10 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: <49f8ca77-3785-f18b-2888-963c26089c69@oracle.com> References: <91C357F2-1E1F-4813-9AF2-7B7B7E45E1F3@oracle.com> <49f8ca77-3785-f18b-2888-963c26089c69@oracle.com> Message-ID: Thank you Dean for taking a look at this! Lois On 2/5/2019 2:17 AM, dean.long at oracle.com wrote: > On 2/4/19 10:45 AM, Lois Foltan wrote: >>> Does jvmci use the method_type field?? Or was removing this >>> assertion the only change needed? >> This was the only instance of the use.? However, I have sent email to >> Dean Long and cc'd Vladimir Kozlov asking for review. > > It looks fine to me. > > dl From matthias.baesken at sap.com Tue Feb 5 16:55:53 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 5 Feb 2019 16:55:53 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: Hi G?tz, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ > The old xlc stuff is good to be removed. > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > altogether and replace its only use by USE_XLC_BUILTINS? > Done . > Also, I think it makes sense to put > #if __IBMCPP__ < 1000 > #error "xlc < 10 not supported" > #endif > into the file. > > Probably we should even check for having at least xlc 12. I added a check for xlc 12. Also slightly changed the check for AIX (_AIX macro) in globalDefinitions_xlc.hpp . > > The demangle fix is kind of preliminary, but to get the compiler > working it is acceptable to skip this code for now. > There might be a fix for xlc16 in the future but so far we have to live with it. Best regards, Matthias > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 5. Februar 2019 09:59 > To: Baesken, Matthias ; David Holmes > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi Matthias, > > The demangle fix is kind of preliminary, but to get the compiler > working it is acceptable to skip this code for now. > > The old xlc stuff is good to be removed. > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > altogether and replace its only use by USE_XLC_BUILTINS? > > Also, I think it makes sense to put > #if __IBMCPP__ < 1000 > #error "xlc < 10 not supported" > #endif > into the file. > > Probably we should even check for having at least xlc 12. > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Montag, 4. Februar 2019 12:36 > > To: David Holmes ; 'hotspot- > > dev at openjdk.java.net' ; > > 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi David, I want to follow your suggestion ?? . > > I adjusted the comment , see globalDefinitions_xlc.hpp . > > > > Additionally I removed a strange ifdef handling pre-xlc10 versions that are > > not useful today any more for OpenJDK > > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > > > > Best regards, Matthias > > > > > > > > > -----Original Message----- > > > From: David Holmes > > > Sent: Freitag, 1. Februar 2019 13:49 > > > To: Baesken, Matthias ; 'hotspot- > > > dev at openjdk.java.net' ; > > > 'magnus.ihse.bursie at oracle.com' > > > Cc: 'build-dev at openjdk.java.net' > > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > xlc16 on AIX > > > > > > Hi Matthias, > > > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > > New webrev : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > > > I don't think it makes sense to keep the comment which was obviously > > > copied from the gcc file: > > > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > > __null to > > > // integer variable will cause gcc warning. Use NULL_WORD in places > > > where a > > > // pointer is stored as integer value. On some platforms, > > > sizeof(intptr_t) > > > > // sizeof(void*), so here we want something which is integer type, > > > but has the > > > // same size as a pointer. > > > > > > Rather something like: > > > > > > // Some platform/tool-chain combinations can't assign NULL to an integer > > > // type so we define NULL_WORD to use in those contexts. For xlc they > > > // are the same. > > > > > > Thanks, > > > David > > > > > > > From goetz.lindenmaier at sap.com Tue Feb 5 17:05:00 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Feb 2019 17:05:00 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: Message-ID: <59210a384d3b40f0936ede10b2d77886@sap.com> looks good, thanks for the adjustment! Best regards, Goetz. > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 5. Februar 2019 17:56 > To: Lindenmaier, Goetz ; David Holmes > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > Hi G?tz, new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ > > > > The old xlc stuff is good to be removed. > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > Done . > > > Also, I think it makes sense to put > > #if __IBMCPP__ < 1000 > > #error "xlc < 10 not supported" > > #endif > > into the file. > > > > Probably we should even check for having at least xlc 12. > > I added a check for xlc 12. > Also slightly changed the check for AIX (_AIX macro) in > globalDefinitions_xlc.hpp . > > > > > > The demangle fix is kind of preliminary, but to get the compiler > > working it is acceptable to skip this code for now. > > > > There might be a fix for xlc16 in the future but so far we have to live with it. > > > Best regards, Matthias > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Dienstag, 5. Februar 2019 09:59 > > To: Baesken, Matthias ; David Holmes > > ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > > > Cc: 'build-dev at openjdk.java.net' > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi Matthias, > > > > The demangle fix is kind of preliminary, but to get the compiler > > working it is acceptable to skip this code for now. > > > > The old xlc stuff is good to be removed. > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > Also, I think it makes sense to put > > #if __IBMCPP__ < 1000 > > #error "xlc < 10 not supported" > > #endif > > into the file. > > > > Probably we should even check for having at least xlc 12. > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Montag, 4. Februar 2019 12:36 > > > To: David Holmes ; 'hotspot- > > > dev at openjdk.java.net' ; > > > 'magnus.ihse.bursie at oracle.com' > > > Cc: 'build-dev at openjdk.java.net' > > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > xlc16 on AIX > > > > > > Hi David, I want to follow your suggestion ?? . > > > I adjusted the comment , see globalDefinitions_xlc.hpp . > > > > > > Additionally I removed a strange ifdef handling pre-xlc10 versions that are > > > not useful today any more for OpenJDK > > > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > > > > > New webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > > > > > > > Best regards, Matthias > > > > > > > > > > > > > -----Original Message----- > > > > From: David Holmes > > > > Sent: Freitag, 1. Februar 2019 13:49 > > > > To: Baesken, Matthias ; 'hotspot- > > > > dev at openjdk.java.net' ; > > > > 'magnus.ihse.bursie at oracle.com' > > > > Cc: 'build-dev at openjdk.java.net' > > > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > > xlc16 on AIX > > > > > > > > Hi Matthias, > > > > > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > > > New webrev : > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > > > > > I don't think it makes sense to keep the comment which was obviously > > > > copied from the gcc file: > > > > > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > > > __null to > > > > // integer variable will cause gcc warning. Use NULL_WORD in places > > > > where a > > > > // pointer is stored as integer value. On some platforms, > > > > sizeof(intptr_t) > > > > > // sizeof(void*), so here we want something which is integer type, > > > > but has the > > > > // same size as a pointer. > > > > > > > > Rather something like: > > > > > > > > // Some platform/tool-chain combinations can't assign NULL to an integer > > > > // type so we define NULL_WORD to use in those contexts. For xlc they > > > > // are the same. > > > > > > > > Thanks, > > > > David > > > > > > > > > > > From coleen.phillimore at oracle.com Tue Feb 5 23:01:11 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 5 Feb 2019 18:01:11 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: References: Message-ID: Hi Lois,? I like that there are no longer two resolved references for indy instructions, especially if it wasn't used. http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/interpreter/linkResolver.cpp.udiff.html I can't find a call where set_handle() passes false for the _has_local_sig field. Can you rename CallInfo::_has_local_signature, since it's not that much longer and reads better? + const bool has_local_sig = call_info.has_local_signature(); + assert(has_local_sig, "MHs and indy are always sig-poly"); So why do you need this field if it's always true?? Was hoping for a cpCache bit back :) Perhaps there's a future use? http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/oops/cpCache.hpp.udiff.html + has_local_signature_shift = 25, // (M) does the call site have a per-site signature (sig-poly methods)? Can you make this an "S" vs. "M" and change the coment in the top of cpCache.hpp: // _flags???? [tos|0|F=0|M|A|I|f|0|vf|indy_rf|000|00000|psize] (for method entries) // bit length [ 4 |1| 1 |1|1|1|1|1|1 |-4--|--8--|--8--] And a line under this: // A????? = call site has an appendix argument (loaded from resolved references) Although I don't like this comment because it gets out of date. Thanks, Coleen On 2/4/19 7:32 AM, Lois Foltan wrote: > Please review this change that removes the unused method_type field > associated with the appendix field of an indy or method handle call.? > This is the first of a series of changes working towards JDK-8210685: > Bootstrap method consolidation. > > open webrev at: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ > bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 > co-contributors: Lois Foltan & John Rose > > Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux > only), JCK vm & lang (linux only) > > Thanks, > Lois From goetz.lindenmaier at sap.com Wed Feb 6 07:37:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 6 Feb 2019 07:37:42 +0000 Subject: RFR(XS): 8218544: Fix build on windows: missing include Message-ID: Hi the windows build is broken for a few days. This adds the missing include. http://cr.openjdk.java.net/~goetz/wr19/8218544-win_build/01/ Please review. disassembler.obj : error LNK2019: unresolved external symbol "public: static char const * __cdecl os::dll_file_extension(void)" Best regards, Goetz. From matthias.baesken at sap.com Wed Feb 6 08:05:41 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 6 Feb 2019 08:05:41 +0000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: <59210a384d3b40f0936ede10b2d77886@sap.com> References: <59210a384d3b40f0936ede10b2d77886@sap.com> Message-ID: Thank's G?tz ! David + Magnus may I add you as reviewers ? Best regards, Matthias > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 5. Februar 2019 18:05 > To: Baesken, Matthias ; David Holmes > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > Cc: 'build-dev at openjdk.java.net' > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > xlc16 on AIX > > looks good, thanks for the adjustment! > > Best regards, > Goetz. > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Dienstag, 5. Februar 2019 17:56 > > To: Lindenmaier, Goetz ; David Holmes > > ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > > > Cc: 'build-dev at openjdk.java.net' > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > xlc16 on AIX > > > > Hi G?tz, new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ > > > > > > > The old xlc stuff is good to be removed. > > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > > > > Done . > > > > > Also, I think it makes sense to put > > > #if __IBMCPP__ < 1000 > > > #error "xlc < 10 not supported" > > > #endif > > > into the file. > > > > > > Probably we should even check for having at least xlc 12. > > > > I added a check for xlc 12. > > Also slightly changed the check for AIX (_AIX macro) in > > globalDefinitions_xlc.hpp . > > > > > > > > > > The demangle fix is kind of preliminary, but to get the compiler > > > working it is acceptable to skip this code for now. > > > > > > > There might be a fix for xlc16 in the future but so far we have to live with > it. > > > > > > Best regards, Matthias > > > > > > > > > -----Original Message----- > > > From: Lindenmaier, Goetz > > > Sent: Dienstag, 5. Februar 2019 09:59 > > > To: Baesken, Matthias ; David Holmes > > > ; 'hotspot-dev at openjdk.java.net' > > > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' > > > > > > Cc: 'build-dev at openjdk.java.net' > > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from > > > xlc16 on AIX > > > > > > Hi Matthias, > > > > > > The demangle fix is kind of preliminary, but to get the compiler > > > working it is acceptable to skip this code for now. > > > > > > The old xlc stuff is good to be removed. > > > Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN > > > altogether and replace its only use by USE_XLC_BUILTINS? > > > > > > Also, I think it makes sense to put > > > #if __IBMCPP__ < 1000 > > > #error "xlc < 10 not supported" > > > #endif > > > into the file. > > > > > > Probably we should even check for having at least xlc 12. > > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: hotspot-dev On > Behalf > > > Of > > > > Baesken, Matthias > > > > Sent: Montag, 4. Februar 2019 12:36 > > > > To: David Holmes ; 'hotspot- > > > > dev at openjdk.java.net' ; > > > > 'magnus.ihse.bursie at oracle.com' > > > > Cc: 'build-dev at openjdk.java.net' > > > > Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ > from > > > > xlc16 on AIX > > > > > > > > Hi David, I want to follow your suggestion ?? . > > > > I adjusted the comment , see globalDefinitions_xlc.hpp . > > > > > > > > Additionally I removed a strange ifdef handling pre-xlc10 versions that > are > > > > not useful today any more for OpenJDK > > > > ( we most likely cannot build jdk/jdk with xlc versions < 10). > > > > > > > > New webrev : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ > > > > > > > > > > > > Best regards, Matthias > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: David Holmes > > > > > Sent: Freitag, 1. Februar 2019 13:49 > > > > > To: Baesken, Matthias ; 'hotspot- > > > > > dev at openjdk.java.net' ; > > > > > 'magnus.ihse.bursie at oracle.com' > > > > > Cc: 'build-dev at openjdk.java.net' > > > > > Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ > from > > > > > xlc16 on AIX > > > > > > > > > > Hi Matthias, > > > > > > > > > > On 1/02/2019 10:36 pm, Baesken, Matthias wrote: > > > > > > New webrev : > > > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ > > > > > > > > > > > > - adjusted globalDefinitions_xlc.hpp > > > > > > > > > > I don't think it makes sense to keep the comment which was > obviously > > > > > copied from the gcc file: > > > > > > > > > > // On Linux NULL is defined as a special type '__null'. Assigning > > > > > __null to > > > > > // integer variable will cause gcc warning. Use NULL_WORD in places > > > > > where a > > > > > // pointer is stored as integer value. On some platforms, > > > > > sizeof(intptr_t) > > > > > > // sizeof(void*), so here we want something which is integer type, > > > > > but has the > > > > > // same size as a pointer. > > > > > > > > > > Rather something like: > > > > > > > > > > // Some platform/tool-chain combinations can't assign NULL to an > integer > > > > > // type so we define NULL_WORD to use in those contexts. For xlc > they > > > > > // are the same. > > > > > > > > > > Thanks, > > > > > David > > > > > > > > > > > > > > > > From thomas.stuefe at gmail.com Wed Feb 6 08:08:03 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 6 Feb 2019 09:08:03 +0100 Subject: RFR(XS): 8218544: Fix build on windows: missing include In-Reply-To: References: Message-ID: Hi Goetz, I do not understand how 8218041 could have caused this? Plus, does this error show only up in our builds, not in Oracles? Fix looks fine. ...Thomas On Wed, Feb 6, 2019 at 8:38 AM Lindenmaier, Goetz wrote: > Hi > > the windows build is broken for a few days. This adds the missing > include. > http://cr.openjdk.java.net/~goetz/wr19/8218544-win_build/01/ > > Please review. > > disassembler.obj : error LNK2019: unresolved external symbol "public: > static char const * __cdecl os::dll_file_extension(void)" > > Best regards, > Goetz. > > From goetz.lindenmaier at sap.com Wed Feb 6 08:38:29 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 6 Feb 2019 08:38:29 +0000 Subject: RFR(XS): 8218544: Fix build on windows: missing include In-Reply-To: References: Message-ID: <9b5e4f0588474fe793c06f2d913995ad@sap.com> Hi Thomas, > I do not understand how 8218041 could have caused this? Plus, does this error > show only up in our builds, not in Oracles? I didn't track this down, but somehow transitively the include of os.inline.hpp must have disappeared. Our build worked with 8217578, but broke with 8218140, and 8218041 was in between these and caused other similar issues. So I guessed. Probably others use precompiled headers. Best regards, Goetz. > > Fix looks fine. > > ...Thomas > > > > > On Wed, Feb 6, 2019 at 8:38 AM Lindenmaier, Goetz > > wrote: > > > Hi > > the windows build is broken for a few days. This adds the missing > include. > http://cr.openjdk.java.net/~goetz/wr19/8218544-win_build/01/ > > Please review. > > disassembler.obj : error LNK2019: unresolved external symbol "public: > static char const * __cdecl os::dll_file_extension(void)" > > Best regards, > Goetz. > > From tobias.hartmann at oracle.com Wed Feb 6 09:23:57 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 6 Feb 2019 10:23:57 +0100 Subject: [11u] RFR(M): 8214206: Fix for JDK-8213419 is broken on 32-bit In-Reply-To: <87ef8r394i.fsf@redhat.com> References: <87ef8r394i.fsf@redhat.com> Message-ID: Hi Roland, looks good to me. Best regards, Tobias On 01.02.19 14:56, Roland Westrelin wrote: > > I'd like to backport this fix to 11u but the patch doesn't apply cleanly > some I'm requesting a new review. > > http://cr.openjdk.java.net/~roland/8214206.11u/webrev.00/ > > jdk 12 fix: > https://bugs.openjdk.java.net/browse/JDK-8214206 > http://hg.openjdk.java.net/jdk/jdk/rev/7d3cde494494 > > Roland. > From david.holmes at oracle.com Wed Feb 6 11:54:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Feb 2019 21:54:47 +1000 Subject: RFR(XS): 8218544: Fix build on windows: missing include In-Reply-To: <9b5e4f0588474fe793c06f2d913995ad@sap.com> References: <9b5e4f0588474fe793c06f2d913995ad@sap.com> Message-ID: <5b5c500a-c7fe-7d13-fa1e-c83bfb311532@oracle.com> 8218041 was tested with and without PCH and we do not see any failures in our builds. Very perplexing. But reviewed. Thanks, David On 6/02/2019 6:38 pm, Lindenmaier, Goetz wrote: > Hi Thomas, > >> I do not understand how 8218041 could have caused this? Plus, does this error >> show only up in our builds, not in Oracles? > I didn't track this down, but somehow transitively the include of os.inline.hpp > must have disappeared. > Our build worked with 8217578, but broke with 8218140, and 8218041 was > in between these and caused other similar issues. So I guessed. > > Probably others use precompiled headers. > > Best regards, > Goetz. > > > >> >> Fix looks fine. >> >> ...Thomas >> >> >> >> >> On Wed, Feb 6, 2019 at 8:38 AM Lindenmaier, Goetz >> > wrote: >> >> >> Hi >> >> the windows build is broken for a few days. This adds the missing >> include. >> http://cr.openjdk.java.net/~goetz/wr19/8218544-win_build/01/ >> >> Please review. >> >> disassembler.obj : error LNK2019: unresolved external symbol "public: >> static char const * __cdecl os::dll_file_extension(void)" >> >> Best regards, >> Goetz. >> >> > From david.holmes at oracle.com Wed Feb 6 11:55:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Feb 2019 21:55:35 +1000 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: <59210a384d3b40f0936ede10b2d77886@sap.com> Message-ID: <80e7bfaa-a519-a865-da3e-6857a492fbdf@oracle.com> On 6/02/2019 6:05 pm, Baesken, Matthias wrote: > Thank's G?tz ! > > David + Magnus may I add you as reviewers ? Sure - though my review was only partial. You seem to have it all covered now. :) Thanks, David > Best regards, Matthias > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 5. Februar 2019 18:05 >> To: Baesken, Matthias ; David Holmes >> ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >> >> Cc: 'build-dev at openjdk.java.net' >> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >> xlc16 on AIX >> >> looks good, thanks for the adjustment! >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Dienstag, 5. Februar 2019 17:56 >>> To: Lindenmaier, Goetz ; David Holmes >>> ; 'hotspot-dev at openjdk.java.net' >> dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >>> >>> Cc: 'build-dev at openjdk.java.net' >>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>> xlc16 on AIX >>> >>> Hi G?tz, new webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ >>> >>> >>>> The old xlc stuff is good to be removed. >>>> Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN >>>> altogether and replace its only use by USE_XLC_BUILTINS? >>>> >>> >>> Done . >>> >>>> Also, I think it makes sense to put >>>> #if __IBMCPP__ < 1000 >>>> #error "xlc < 10 not supported" >>>> #endif >>>> into the file. >>>> >>>> Probably we should even check for having at least xlc 12. >>> >>> I added a check for xlc 12. >>> Also slightly changed the check for AIX (_AIX macro) in >>> globalDefinitions_xlc.hpp . >>> >>> >>>> >>>> The demangle fix is kind of preliminary, but to get the compiler >>>> working it is acceptable to skip this code for now. >>>> >>> >>> There might be a fix for xlc16 in the future but so far we have to live with >> it. >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Dienstag, 5. Februar 2019 09:59 >>>> To: Baesken, Matthias ; David Holmes >>>> ; 'hotspot-dev at openjdk.java.net' >> >>> dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >>>> >>>> Cc: 'build-dev at openjdk.java.net' >>>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>>> xlc16 on AIX >>>> >>>> Hi Matthias, >>>> >>>> The demangle fix is kind of preliminary, but to get the compiler >>>> working it is acceptable to skip this code for now. >>>> >>>> The old xlc stuff is good to be removed. >>>> Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN >>>> altogether and replace its only use by USE_XLC_BUILTINS? >>>> >>>> Also, I think it makes sense to put >>>> #if __IBMCPP__ < 1000 >>>> #error "xlc < 10 not supported" >>>> #endif >>>> into the file. >>>> >>>> Probably we should even check for having at least xlc 12. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev On >> Behalf >>>> Of >>>>> Baesken, Matthias >>>>> Sent: Montag, 4. Februar 2019 12:36 >>>>> To: David Holmes ; 'hotspot- >>>>> dev at openjdk.java.net' ; >>>>> 'magnus.ihse.bursie at oracle.com' >>>>> Cc: 'build-dev at openjdk.java.net' >>>>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ >> from >>>>> xlc16 on AIX >>>>> >>>>> Hi David, I want to follow your suggestion ?? . >>>>> I adjusted the comment , see globalDefinitions_xlc.hpp . >>>>> >>>>> Additionally I removed a strange ifdef handling pre-xlc10 versions that >> are >>>>> not useful today any more for OpenJDK >>>>> ( we most likely cannot build jdk/jdk with xlc versions < 10). >>>>> >>>>> New webrev : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Freitag, 1. Februar 2019 13:49 >>>>>> To: Baesken, Matthias ; 'hotspot- >>>>>> dev at openjdk.java.net' ; >>>>>> 'magnus.ihse.bursie at oracle.com' >>>>>> Cc: 'build-dev at openjdk.java.net' >>>>>> Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ >> from >>>>>> xlc16 on AIX >>>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> On 1/02/2019 10:36 pm, Baesken, Matthias wrote: >>>>>>> New webrev : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ >>>>>>> >>>>>>> - adjusted globalDefinitions_xlc.hpp >>>>>> >>>>>> I don't think it makes sense to keep the comment which was >> obviously >>>>>> copied from the gcc file: >>>>>> >>>>>> // On Linux NULL is defined as a special type '__null'. Assigning >>>>>> __null to >>>>>> // integer variable will cause gcc warning. Use NULL_WORD in places >>>>>> where a >>>>>> // pointer is stored as integer value. On some platforms, >>>>>> sizeof(intptr_t) > >>>>>> // sizeof(void*), so here we want something which is integer type, >>>>>> but has the >>>>>> // same size as a pointer. >>>>>> >>>>>> Rather something like: >>>>>> >>>>>> // Some platform/tool-chain combinations can't assign NULL to an >> integer >>>>>> // type so we define NULL_WORD to use in those contexts. For xlc >> they >>>>>> // are the same. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>> >>> >> > From shade at redhat.com Wed Feb 6 11:58:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Feb 2019 12:58:14 +0100 Subject: RFR(XS): 8218544: Fix build on windows: missing include In-Reply-To: <5b5c500a-c7fe-7d13-fa1e-c83bfb311532@oracle.com> References: <9b5e4f0588474fe793c06f2d913995ad@sap.com> <5b5c500a-c7fe-7d13-fa1e-c83bfb311532@oracle.com> Message-ID: On 2/6/19 12:54 PM, David Holmes wrote: > 8218041? was tested with and without PCH and we do not see any failures in our builds. Same. > Very perplexing. Same. > But reviewed. Same. -Aleksey From rwestrel at redhat.com Wed Feb 6 12:43:56 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 06 Feb 2019 13:43:56 +0100 Subject: [11u] RFR(M): 8214206: Fix for JDK-8213419 is broken on 32-bit In-Reply-To: References: <87ef8r394i.fsf@redhat.com> Message-ID: <87tvhh13zn.fsf@redhat.com> Thanks for the review, Tobias. Roland. From matthias.baesken at sap.com Wed Feb 6 13:18:40 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 6 Feb 2019 13:18:40 +0000 Subject: open-calls in hotspot code instead of os::open ? Message-ID: Hello, I noticed a few calls to open instead of os::open in the hotspot C++ code . For example : share/memory/filemap.cpp:553: int fd = open(_full_path, O_RDONLY | O_BINARY, 0); share/memory/filemap.cpp:588: int fd = open(_full_path, O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0444); share/utilities/vmError.cpp:1197: fd = open(buf, O_RDWR | O_CREAT | O_EXCL, 0666); share/utilities/ostream.cpp:563: _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); share/ci/ciEnv.cpp:1256: int fd = open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); share/ci/ciEnv.cpp:1274: int fd = open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); share/classfile/compactHashtable.cpp:201: _fd = open(filename, O_RDONLY | O_BINARY, 0); share/compiler/compileLog.cpp:210: int partial_fd = open(partial_file, O_RDONLY); This might be often fine, but in special cases we miss platform specific extensions done in os::open , for example for Windows the unc/extended path handling done in os::open ( calls create_unc_path for long paths) : int os::open(const char *path, int oflag, int mode) { char* pathbuf = (char*)os::strdup(path, mtInternal); . . . os::native_path(pathbuf); int ret; if (strlen(path) < MAX_PATH) { ret = ::open(pathbuf, oflag | O_BINARY | O_NOINHERIT, mode); } else { errno_t err = ERROR_SUCCESS; wchar_t* wpath = create_unc_path(pathbuf, err); . . . ret = ::_wopen(wpath, oflag | O_BINARY | O_NOINHERIT, mode); Should I open a bug and replace the open calls by os::open ? Thanks , Matthias From ioi.lam at oracle.com Wed Feb 6 14:08:21 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 6 Feb 2019 06:08:21 -0800 Subject: open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: I think this should be fixed. BTW, is there a way to forbid all the calls to ::open()? Thanks - Ioi On 2/6/19 5:18 AM, Baesken, Matthias wrote: > Hello, I noticed a few calls to open instead of os::open in the hotspot C++ code . > For example : > > share/memory/filemap.cpp:553: int fd = open(_full_path, O_RDONLY | O_BINARY, 0); > share/memory/filemap.cpp:588: int fd = open(_full_path, O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0444); > share/utilities/vmError.cpp:1197: fd = open(buf, O_RDWR | O_CREAT | O_EXCL, 0666); > share/utilities/ostream.cpp:563: _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); > > share/ci/ciEnv.cpp:1256: int fd = open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); > share/ci/ciEnv.cpp:1274: int fd = open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); > share/classfile/compactHashtable.cpp:201: _fd = open(filename, O_RDONLY | O_BINARY, 0); > share/compiler/compileLog.cpp:210: int partial_fd = open(partial_file, O_RDONLY); > > > This might be often fine, but in special cases we miss platform specific extensions done in os::open , > for example for Windows the unc/extended path handling done in os::open ( calls create_unc_path for long paths) : > > > int os::open(const char *path, int oflag, int mode) { > char* pathbuf = (char*)os::strdup(path, mtInternal); > . . . > os::native_path(pathbuf); > int ret; > if (strlen(path) < MAX_PATH) { > ret = ::open(pathbuf, oflag | O_BINARY | O_NOINHERIT, mode); > } else { > errno_t err = ERROR_SUCCESS; > wchar_t* wpath = create_unc_path(pathbuf, err); > . . . > ret = ::_wopen(wpath, oflag | O_BINARY | O_NOINHERIT, mode); > > > Should I open a bug and replace the open calls by os::open ? > > Thanks , Matthias > > > From harold.seigel at oracle.com Wed Feb 6 14:18:02 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 6 Feb 2019 09:18:02 -0500 Subject: RFR 8214719: Deprecate -Xverify:none option Message-ID: Hi, Please review this change to deprecate the -Xverify:none and -noverify options in JDK-13.? The following warning message will be issued when these options are used: ?warning: Options -Xverify:none and -noverify were deprecated in version 13.0 and will likely be removed in a future release. The options were removed from tests that no longer needed them or the options were changed as needed. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on Linux-x64, and by running JCK Lang and VM tests on Linux-x64. Thanks, Harold From shade at redhat.com Wed Feb 6 14:26:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Feb 2019 15:26:39 +0100 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: References: Message-ID: <0cd0c5ff-11a5-44db-aea1-d02748b6728f@redhat.com> On 2/6/19 3:18 PM, Harold Seigel wrote: > Please review this change to deprecate the -Xverify:none and -noverify options in JDK-13.? The > following warning message will be issued when these options are used: > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8214719 I am against removing this option: it is used to skip verification overhead on known-good class files, and also is used to see if verifier _is_ indeed the performance problem for those cases. I see David Holmes made similar comment in the bug, which was left unacknowledged. -Aleksey From goetz.lindenmaier at sap.com Wed Feb 6 14:38:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 6 Feb 2019 14:38:42 +0000 Subject: RFR(XS): 8218544: Fix build on windows: missing include In-Reply-To: References: <9b5e4f0588474fe793c06f2d913995ad@sap.com> <5b5c500a-c7fe-7d13-fa1e-c83bfb311532@oracle.com> Message-ID: <29efd374994e4c869ce659f2041b9d49@sap.com> Hi David, Aleksey, thanks for reviewing! Maybe it's because we configure with --enable-aot=no? But I don't want to track it down, as the fix is obviously needed and correct ... as you confirmed, thanks! Best regards, Goetz. > -----Original Message----- > From: Aleksey Shipilev > Sent: Mittwoch, 6. Februar 2019 12:58 > To: David Holmes ; Lindenmaier, Goetz > ; Thomas St?fe > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): 8218544: Fix build on windows: missing include > > On 2/6/19 12:54 PM, David Holmes wrote: > > 8218041? was tested with and without PCH and we do not see any failures in > our builds. > > Same. > > > Very perplexing. > > Same. > > > But reviewed. > > Same. > > -Aleksey From magnus.ihse.bursie at oracle.com Wed Feb 6 15:12:42 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 Feb 2019 16:12:42 +0100 Subject: RFR : 8218136: minor hotspot adjustments for xlclang++ from xlc16 on AIX In-Reply-To: References: <59210a384d3b40f0936ede10b2d77886@sap.com> Message-ID: On 2019-02-06 09:05, Baesken, Matthias wrote: > Thank's G?tz ! > > David + Magnus may I add you as reviewers ? Sure. /Magnus > > Best regards, Matthias > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 5. Februar 2019 18:05 >> To: Baesken, Matthias ; David Holmes >> ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >> >> Cc: 'build-dev at openjdk.java.net' >> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >> xlc16 on AIX >> >> looks good, thanks for the adjustment! >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Dienstag, 5. Februar 2019 17:56 >>> To: Lindenmaier, Goetz ; David Holmes >>> ; 'hotspot-dev at openjdk.java.net' >> dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >>> >>> Cc: 'build-dev at openjdk.java.net' >>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>> xlc16 on AIX >>> >>> Hi G?tz, new webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.4/ >>> >>> >>>> The old xlc stuff is good to be removed. >>>> Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN >>>> altogether and replace its only use by USE_XLC_BUILTINS? >>>> >>> Done . >>> >>>> Also, I think it makes sense to put >>>> #if __IBMCPP__ < 1000 >>>> #error "xlc < 10 not supported" >>>> #endif >>>> into the file. >>>> >>>> Probably we should even check for having at least xlc 12. >>> I added a check for xlc 12. >>> Also slightly changed the check for AIX (_AIX macro) in >>> globalDefinitions_xlc.hpp . >>> >>> >>>> The demangle fix is kind of preliminary, but to get the compiler >>>> working it is acceptable to skip this code for now. >>>> >>> There might be a fix for xlc16 in the future but so far we have to live with >> it. >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Dienstag, 5. Februar 2019 09:59 >>>> To: Baesken, Matthias ; David Holmes >>>> ; 'hotspot-dev at openjdk.java.net' >> >>> dev at openjdk.java.net>; 'magnus.ihse.bursie at oracle.com' >>>> >>>> Cc: 'build-dev at openjdk.java.net' >>>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ from >>>> xlc16 on AIX >>>> >>>> Hi Matthias, >>>> >>>> The demangle fix is kind of preliminary, but to get the compiler >>>> working it is acceptable to skip this code for now. >>>> >>>> The old xlc stuff is good to be removed. >>>> Could you please remove USE_XLC_PREFETCH_WRITE_BUILTIN >>>> altogether and replace its only use by USE_XLC_BUILTINS? >>>> >>>> Also, I think it makes sense to put >>>> #if __IBMCPP__ < 1000 >>>> #error "xlc < 10 not supported" >>>> #endif >>>> into the file. >>>> >>>> Probably we should even check for having at least xlc 12. >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev On >> Behalf >>>> Of >>>>> Baesken, Matthias >>>>> Sent: Montag, 4. Februar 2019 12:36 >>>>> To: David Holmes ; 'hotspot- >>>>> dev at openjdk.java.net' ; >>>>> 'magnus.ihse.bursie at oracle.com' >>>>> Cc: 'build-dev at openjdk.java.net' >>>>> Subject: RE: RFR : 8218136: minor hotspot adjustments for xlclang++ >> from >>>>> xlc16 on AIX >>>>> >>>>> Hi David, I want to follow your suggestion ?? . >>>>> I adjusted the comment , see globalDefinitions_xlc.hpp . >>>>> >>>>> Additionally I removed a strange ifdef handling pre-xlc10 versions that >> are >>>>> not useful today any more for OpenJDK >>>>> ( we most likely cannot build jdk/jdk with xlc versions < 10). >>>>> >>>>> New webrev : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.2/ >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Freitag, 1. Februar 2019 13:49 >>>>>> To: Baesken, Matthias ; 'hotspot- >>>>>> dev at openjdk.java.net' ; >>>>>> 'magnus.ihse.bursie at oracle.com' >>>>>> Cc: 'build-dev at openjdk.java.net' >>>>>> Subject: Re: RFR : 8218136: minor hotspot adjustments for xlclang++ >> from >>>>>> xlc16 on AIX >>>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> On 1/02/2019 10:36 pm, Baesken, Matthias wrote: >>>>>>> New webrev : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218136.1/ >>>>>>> >>>>>>> - adjusted globalDefinitions_xlc.hpp >>>>>> I don't think it makes sense to keep the comment which was >> obviously >>>>>> copied from the gcc file: >>>>>> >>>>>> // On Linux NULL is defined as a special type '__null'. Assigning >>>>>> __null to >>>>>> // integer variable will cause gcc warning. Use NULL_WORD in places >>>>>> where a >>>>>> // pointer is stored as integer value. On some platforms, >>>>>> sizeof(intptr_t) > >>>>>> // sizeof(void*), so here we want something which is integer type, >>>>>> but has the >>>>>> // same size as a pointer. >>>>>> >>>>>> Rather something like: >>>>>> >>>>>> // Some platform/tool-chain combinations can't assign NULL to an >> integer >>>>>> // type so we define NULL_WORD to use in those contexts. For xlc >> they >>>>>> // are the same. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> From matthias.baesken at sap.com Wed Feb 6 15:17:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 6 Feb 2019 15:17:51 +0000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings Message-ID: Hello, please review this small change . I noticed (when looking into AIX xlc16 / xlclang++) the following: in the case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims to be a gcc . This is a bit misleading. This change adjusts the setting for clang usage on AIX (for future usage with xlclang++) and macOSX. Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy Oracle / Sun Studio versions ). Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8218562 http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ Thanks, Matthias From magnus.ihse.bursie at oracle.com Wed Feb 6 16:38:11 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 Feb 2019 17:38:11 +0100 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: References: Message-ID: <9588d9f5-4207-b0c8-3793-d3b1643d6781@oracle.com> On 2019-02-06 16:17, Baesken, Matthias wrote: > Hello, please review this small change . > > I noticed (when looking into AIX xlc16 / xlclang++) the following: in the case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims to be a gcc . > This is a bit misleading. > This change adjusts the setting for clang usage on AIX (for future usage with xlclang++) and macOSX. > > Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy Oracle / Sun Studio versions ). > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218562 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ Looks good to me. /Magnus > > > Thanks, Matthias From harold.seigel at oracle.com Wed Feb 6 19:39:28 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 6 Feb 2019 14:39:28 -0500 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <0cd0c5ff-11a5-44db-aea1-d02748b6728f@redhat.com> References: <0cd0c5ff-11a5-44db-aea1-d02748b6728f@redhat.com> Message-ID: <5d581b70-a575-777e-0f29-8aae92cd4d93@oracle.com> Hi Aleksey, Thank you for pointing out that I had not acknowledged David's comment.? I have since entered a response pointing out that users can now use AppCDS to get their performance boost because AppCDS code is verified at archive time. Does the availability of AppCDS allay your concerns about this change? Thanks, Harold On 2/6/2019 9:26 AM, Aleksey Shipilev wrote: > On 2/6/19 3:18 PM, Harold Seigel wrote: >> Please review this change to deprecate the -Xverify:none and -noverify options in JDK-13.? The >> following warning message will be issued when these options are used: >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8214719 > I am against removing this option: it is used to skip verification overhead on known-good class > files, and also is used to see if verifier _is_ indeed the performance problem for those cases. I > see David Holmes made similar comment in the bug, which was left unacknowledged. > > -Aleksey > From ioi.lam at oracle.com Wed Feb 6 19:56:44 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 6 Feb 2019 11:56:44 -0800 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <5d581b70-a575-777e-0f29-8aae92cd4d93@oracle.com> References: <0cd0c5ff-11a5-44db-aea1-d02748b6728f@redhat.com> <5d581b70-a575-777e-0f29-8aae92cd4d93@oracle.com> Message-ID: <31f17b94-bb37-d404-47dc-d26fd32b1b8a@oracle.com> Hi Harold, Is the plan to (eventually) deprecate BytecodeVerificationRemote and BytecodeVerificationLocal as well? Thanks - Ioi On 2/6/19 11:39 AM, Harold Seigel wrote: > Hi Aleksey, > > Thank you for pointing out that I had not acknowledged David's > comment.? I have since entered a response pointing out that users can > now use AppCDS to get their performance boost because AppCDS code is > verified at archive time. > > Does the availability of AppCDS allay your concerns about this change? > > Thanks, Harold > > On 2/6/2019 9:26 AM, Aleksey Shipilev wrote: >> On 2/6/19 3:18 PM, Harold Seigel wrote: >>> Please review this change to deprecate the -Xverify:none and >>> -noverify options in JDK-13.? The >>> following warning message will be issued when these options are used: >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 >> I am against removing this option: it is used to skip verification >> overhead on known-good class >> files, and also is used to see if verifier _is_ indeed the >> performance problem for those cases. I >> see David Holmes made similar comment in the bug, which was left >> unacknowledged. >> >> -Aleksey >> From lois.foltan at oracle.com Wed Feb 6 20:34:51 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 6 Feb 2019 15:34:51 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: References: Message-ID: <55957964-5eab-6467-6ea9-bfd1bf6e33e0@oracle.com> On 2/5/2019 6:01 PM, coleen.phillimore at oracle.com wrote: > > Hi Lois,? I like that there are no longer two resolved references for > indy instructions, especially if it wasn't used. Thanks Coleen for the review!? More below. > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/interpreter/linkResolver.cpp.udiff.html > > > I can't find a call where set_handle() passes false for the > _has_local_sig field. There is no call to set_handle() that passes false for the _has_local_sig field.? It is set to false initially in CallInfo::set_common.? I considered not passing the "has_local_sig" parameter to set_handle and just always set CallInfo::_has_local_sig to true within that method but I am assuming John wanted to allow for the possibility that it could be set to false in the future. > > Can you rename CallInfo::_has_local_signature, since it's not that > much longer and reads better? > > + const bool has_local_sig = call_info.has_local_signature(); > + assert(has_local_sig, "MHs and indy are always sig-poly"); I'm confused.? The field currently within CallInfo is named CallInfo::_has_local_sig.? Are you referring to the method CallInfo::has_local_signature()?? Do you want that shortened? > > So why do you need this field if it's always true?? Was hoping for a > cpCache bit back :) It's not always true. > > Perhaps there's a future use? > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/oops/cpCache.hpp.udiff.html > > > + has_local_signature_shift = 25, // (M) does the call site have a > per-site signature (sig-poly methods)? > > > Can you make this an "S" vs. "M" and change the coment in the top of > cpCache.hpp: > > // _flags???? [tos|0|F=0|M|A|I|f|0|vf|indy_rf|000|00000|psize] (for > method entries) > // bit length [ 4 |1| 1 |1|1|1|1|1|1 |-4--|--8--|--8--] Done, changed the "M" to "S" in both places.? The comment in the top of cpCache.hpp does not refer to the method_type in any form, so unclear as to how you want me to change it?? I am assuming you want me to remove the "method_type info (t_section) from this comment? // _flags?? = method type info (t section), //??????????? virtual final bit (vfinal), > > And a line under this: > > // A????? = call site has an appendix argument (loaded from resolved > references) Not sure what you mean by this? Thanks, Lois > > Although I don't like this comment because it gets out of date. > > Thanks, > Coleen > > On 2/4/19 7:32 AM, Lois Foltan wrote: >> Please review this change that removes the unused method_type field >> associated with the appendix field of an indy or method handle call.? >> This is the first of a series of changes working towards JDK-8210685: >> Bootstrap method consolidation. >> >> open webrev at: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ >> bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 >> co-contributors: Lois Foltan & John Rose >> >> Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux >> only), JCK vm & lang (linux only) >> >> Thanks, >> Lois > From harold.seigel at oracle.com Wed Feb 6 20:46:45 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 6 Feb 2019 15:46:45 -0500 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <31f17b94-bb37-d404-47dc-d26fd32b1b8a@oracle.com> References: <0cd0c5ff-11a5-44db-aea1-d02748b6728f@redhat.com> <5d581b70-a575-777e-0f29-8aae92cd4d93@oracle.com> <31f17b94-bb37-d404-47dc-d26fd32b1b8a@oracle.com> Message-ID: <943aeb27-6ab9-e0d4-2bec-f83fb10df6d7@oracle.com> Hi Ioi, There are no current plans to deprecate those two options. Harold On 2/6/2019 2:56 PM, Ioi Lam wrote: > Hi Harold, > > Is the plan to (eventually) deprecate BytecodeVerificationRemote and > BytecodeVerificationLocal as well? > > Thanks > > - Ioi > > On 2/6/19 11:39 AM, Harold Seigel wrote: >> Hi Aleksey, >> >> Thank you for pointing out that I had not acknowledged David's >> comment.? I have since entered a response pointing out that users can >> now use AppCDS to get their performance boost because AppCDS code is >> verified at archive time. >> >> Does the availability of AppCDS allay your concerns about this change? >> >> Thanks, Harold >> >> On 2/6/2019 9:26 AM, Aleksey Shipilev wrote: >>> On 2/6/19 3:18 PM, Harold Seigel wrote: >>>> Please review this change to deprecate the -Xverify:none and >>>> -noverify options in JDK-13.? The >>>> following warning message will be issued when these options are used: >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >>>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 >>> I am against removing this option: it is used to skip verification >>> overhead on known-good class >>> files, and also is used to see if verifier _is_ indeed the >>> performance problem for those cases. I >>> see David Holmes made similar comment in the bug, which was left >>> unacknowledged. >>> >>> -Aleksey >>> From forax at univ-mlv.fr Wed Feb 6 22:15:23 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 6 Feb 2019 23:15:23 +0100 (CET) Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: References: Message-ID: <415534781.908016.1549491323891.JavaMail.zimbra@u-pem.fr> Hi Harold, -noverify is very useful for debugging, i use it either because i think that the verifier has an error (array covariance of value types is a recent example) or because i want to simulate in a test a class that will not be verified at runtime (by example an anonymous classes). I see no problem to move it under the diagnostic flag but deprecate it (and then its removal) will make my life more painful. R?mi ----- Mail original ----- > De: "Harold David Seigel" > ?: "hotspot-dev" > Envoy?: Mercredi 6 F?vrier 2019 15:18:02 > Objet: RFR 8214719: Deprecate -Xverify:none option > Hi, > > Please review this change to deprecate the -Xverify:none and -noverify > options in JDK-13.? The following warning message will be issued when > these options are used: > > ?warning: Options -Xverify:none and -noverify were deprecated in > version 13.0 and will likely be removed in a future release. > > The options were removed from tests that no longer needed them or the > options were changed as needed. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html > > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on > Linux-x64, and by running JCK Lang and VM tests on Linux-x64. > > Thanks, Harold From forax at univ-mlv.fr Wed Feb 6 22:16:54 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 6 Feb 2019 23:16:54 +0100 (CET) Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <5d581b70-a575-777e-0f29-8aae92cd4d93@oracle.com> References: <0cd0c5ff-11a5-44db-aea1-d02748b6728f@redhat.com> <5d581b70-a575-777e-0f29-8aae92cd4d93@oracle.com> Message-ID: <1564073457.908034.1549491414372.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Harold David Seigel" > ?: "Aleksey Shipilev" , "hotspot-dev" > Envoy?: Mercredi 6 F?vrier 2019 20:39:28 > Objet: Re: RFR 8214719: Deprecate -Xverify:none option > Hi Aleksey, > > Thank you for pointing out that I had not acknowledged David's comment. > I have since entered a response pointing out that users can now use > AppCDS to get their performance boost because AppCDS code is verified at > archive time. > > Does the availability of AppCDS allay your concerns about this change? AppCDS has a cost in term of disk space, so use it is a trade off. > > Thanks, Harold R?mi > > On 2/6/2019 9:26 AM, Aleksey Shipilev wrote: >> On 2/6/19 3:18 PM, Harold Seigel wrote: >>> Please review this change to deprecate the -Xverify:none and -noverify options >>> in JDK-13.? The >>> following warning message will be issued when these options are used: >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8214719 >> I am against removing this option: it is used to skip verification overhead on >> known-good class >> files, and also is used to see if verifier _is_ indeed the performance problem >> for those cases. I >> see David Holmes made similar comment in the bug, which was left unacknowledged. >> >> -Aleksey From david.holmes at oracle.com Thu Feb 7 02:58:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Feb 2019 12:58:12 +1000 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <415534781.908016.1549491323891.JavaMail.zimbra@u-pem.fr> References: <415534781.908016.1549491323891.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, On 7/02/2019 8:15 am, Remi Forax wrote: > Hi Harold, > -noverify is very useful for debugging, > i use it either because i think that the verifier has an error (array covariance of value types is a recent example) or because i want to simulate in a test a class that will not be verified at runtime (by example an anonymous classes). > > I see no problem to move it under the diagnostic flag but deprecate it (and then its removal) will make my life more painful. You can use the -XX flags previously mentioned instead. The existence of -noverify could be seen as a historical error as it's defined as a standard launcher flag when at best it should have been a -X flag, or more appropriately -XX. Cheers, David > > R?mi > > ----- Mail original ----- >> De: "Harold David Seigel" >> ?: "hotspot-dev" >> Envoy?: Mercredi 6 F?vrier 2019 15:18:02 >> Objet: RFR 8214719: Deprecate -Xverify:none option > >> Hi, >> >> Please review this change to deprecate the -Xverify:none and -noverify >> options in JDK-13.? The following warning message will be issued when >> these options are used: >> >> ?warning: Options -Xverify:none and -noverify were deprecated in >> version 13.0 and will likely be removed in a future release. >> >> The options were removed from tests that no longer needed them or the >> options were changed as needed. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >> >> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests and >> builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on >> Linux-x64, and by running JCK Lang and VM tests on Linux-x64. >> >> Thanks, Harold From david.holmes at oracle.com Thu Feb 7 04:59:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Feb 2019 14:59:12 +1000 Subject: RFR(XS): 8218544: Fix build on windows: missing include In-Reply-To: <29efd374994e4c869ce659f2041b9d49@sap.com> References: <9b5e4f0588474fe793c06f2d913995ad@sap.com> <5b5c500a-c7fe-7d13-fa1e-c83bfb311532@oracle.com> <29efd374994e4c869ce659f2041b9d49@sap.com> Message-ID: On 7/02/2019 12:38 am, Lindenmaier, Goetz wrote: > Hi David, Aleksey, > > thanks for reviewing! > > Maybe it's because we configure with --enable-aot=no? > But I don't want to track it down, as the fix is obviously > needed and correct ... as you confirmed, thanks! I think, looking closer, that we only build with no-PCH on linux, and so missed this because the set of inline os functions differs by platform Cheers, David > Best regards, > Goetz. > >> -----Original Message----- >> From: Aleksey Shipilev >> Sent: Mittwoch, 6. Februar 2019 12:58 >> To: David Holmes ; Lindenmaier, Goetz >> ; Thomas St?fe >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XS): 8218544: Fix build on windows: missing include >> >> On 2/6/19 12:54 PM, David Holmes wrote: >>> 8218041? was tested with and without PCH and we do not see any failures in >> our builds. >> >> Same. >> >>> Very perplexing. >> >> Same. >> >>> But reviewed. >> >> Same. >> >> -Aleksey > From matthias.baesken at sap.com Thu Feb 7 09:12:39 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 7 Feb 2019 09:12:39 +0000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: <9588d9f5-4207-b0c8-3793-d3b1643d6781@oracle.com> References: <9588d9f5-4207-b0c8-3793-d3b1643d6781@oracle.com> Message-ID: Thanks . A second review would be great . Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Mittwoch, 6. Februar 2019 17:38 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; 'build- > dev at openjdk.java.net' > Subject: Re: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for > clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings > > On 2019-02-06 16:17, Baesken, Matthias wrote: > > Hello, please review this small change . > > > > I noticed (when looking into AIX xlc16 / xlclang++) the following: in the > case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims > to be a gcc . > > This is a bit misleading. > > This change adjusts the setting for clang usage on AIX (for future usage > with xlclang++) and macOSX. > > > > Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy > Oracle / Sun Studio versions ). > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218562 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ > Looks good to me. > > /Magnus > > > > > > Thanks, Matthias From martin.doerr at sap.com Thu Feb 7 09:17:33 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 7 Feb 2019 09:17:33 +0000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: References: <9588d9f5-4207-b0c8-3793-d3b1643d6781@oracle.com> Message-ID: Hi Matthias, looks good to me, too. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Baesken, Matthias Sent: Donnerstag, 7. Februar 2019 10:13 To: Magnus Ihse Bursie ; 'hotspot-dev at openjdk.java.net' ; 'build-dev at openjdk.java.net' Subject: RE: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings Thanks . A second review would be great . Best regards, Matthias > -----Original Message----- > From: Magnus Ihse Bursie > Sent: Mittwoch, 6. Februar 2019 17:38 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; 'build- > dev at openjdk.java.net' > Subject: Re: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for > clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings > > On 2019-02-06 16:17, Baesken, Matthias wrote: > > Hello, please review this small change . > > > > I noticed (when looking into AIX xlc16 / xlclang++) the following: in the > case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims > to be a gcc . > > This is a bit misleading. > > This change adjusts the setting for clang usage on AIX (for future usage > with xlclang++) and macOSX. > > > > Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy > Oracle / Sun Studio versions ). > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8218562 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ > Looks good to me. > > /Magnus > > > > > > Thanks, Matthias From david.holmes at oracle.com Thu Feb 7 09:36:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Feb 2019 19:36:23 +1000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: References: Message-ID: <0fcee21f-f147-fd78-4571-8f683e4a8bc4@oracle.com> Hi Matthias, On 7/02/2019 1:17 am, Baesken, Matthias wrote: > Hello, please review this small change . > > I noticed (when looking into AIX xlc16 / xlclang++) the following: in the case that clang is used for compilation, HOTSPOT_BUILD_COMPILER claims to be a gcc . > This is a bit misleading. > This change adjusts the setting for clang usage on AIX (for future usage with xlclang++) and macOSX. > > Additionally I removed some old HOTSPOT_BUILD_COMPILER for legacy Oracle / Sun Studio versions ). Possibly more could be removed :) Changes seem fine. I've always been irked by the fact we can access an actual version string from the compilers themselves, so we wouldn't need this code. Thanks, David > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8218562 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ > > > Thanks, Matthias > From magnus.ihse.bursie at oracle.com Thu Feb 7 11:38:10 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Feb 2019 12:38:10 +0100 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: <0fcee21f-f147-fd78-4571-8f683e4a8bc4@oracle.com> References: <0fcee21f-f147-fd78-4571-8f683e4a8bc4@oracle.com> Message-ID: <33d2b12a-8ab4-256d-701f-c47798ed749e@oracle.com> On 2019-02-07 10:36, David Holmes wrote: > Hi Matthias, > > On 7/02/2019 1:17 am, Baesken, Matthias wrote: >> Hello, please review this small change . >> >> I noticed (when looking into AIX xlc16 / xlclang++)? the >> following:??? in the case that? clang is used for compilation,??? >> HOTSPOT_BUILD_COMPILER?? claims to be a gcc . >> This is a bit misleading. >> This change? adjusts the setting for clang usage on? AIX? (for future >> usage with xlclang++)?? and macOSX. >> >> Additionally I removed some? old? HOTSPOT_BUILD_COMPILER?? for legacy >> Oracle / Sun Studio versions ). > > Possibly more could be removed :) > > Changes seem fine. > > I've always been irked by the fact we can access an actual version > string from the compilers themselves, so we wouldn't need this code. How do you do that? I'm having this kind of background low-intensity itch to fix the duplication between hotspot and build system in this (and related system detection code). It never rises to enough annoyance to actually get me to do anything about it, though. /Magnus > > Thanks, > David > >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8218562 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ >> >> >> Thanks, Matthias >> From david.holmes at oracle.com Thu Feb 7 11:44:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Feb 2019 21:44:47 +1000 Subject: RFR [XS] : 8218562: handle HOTSPOT_BUILD_COMPILER for clang/xlclang and cleanup HOTSPOT_BUILD_COMPILER settings In-Reply-To: <33d2b12a-8ab4-256d-701f-c47798ed749e@oracle.com> References: <0fcee21f-f147-fd78-4571-8f683e4a8bc4@oracle.com> <33d2b12a-8ab4-256d-701f-c47798ed749e@oracle.com> Message-ID: <008410b9-87cb-1fdd-1b97-8b96900122cc@oracle.com> On 7/02/2019 9:38 pm, Magnus Ihse Bursie wrote: > On 2019-02-07 10:36, David Holmes wrote: >> Hi Matthias, >> >> On 7/02/2019 1:17 am, Baesken, Matthias wrote: >>> Hello, please review this small change . >>> >>> I noticed (when looking into AIX xlc16 / xlclang++)? the >>> following:??? in the case that? clang is used for compilation, >>> HOTSPOT_BUILD_COMPILER?? claims to be a gcc . >>> This is a bit misleading. >>> This change? adjusts the setting for clang usage on? AIX? (for future >>> usage with xlclang++)?? and macOSX. >>> >>> Additionally I removed some? old? HOTSPOT_BUILD_COMPILER?? for legacy >>> Oracle / Sun Studio versions ). >> >> Possibly more could be removed :) >> >> Changes seem fine. >> >> I've always been irked by the fact we can access an actual version >> string from the compilers themselves, so we wouldn't need this code. > How do you do that? Sorry typo s/we can access/we can't access/ > I'm having this kind of background low-intensity itch to fix the > duplication between hotspot and build system in this (and related system > detection code). It never rises to enough annoyance to actually get me > to do anything about it, though. I guess configure could generate a version string for hotspot to use, but it's probably not the brief version string we prefer to have. David > /Magnus > > >> >> Thanks, >> David >> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8218562 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218562.0/ >>> >>> >>> Thanks, Matthias >>> > From forax at univ-mlv.fr Thu Feb 7 12:56:42 2019 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 7 Feb 2019 13:56:42 +0100 (CET) Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: References: <415534781.908016.1549491323891.JavaMail.zimbra@u-pem.fr> Message-ID: <449476725.1066493.1549544202442.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David Holmes" > ?: "Remi Forax" , "Harold David Seigel" > Cc: "hotspot-dev" > Envoy?: Jeudi 7 F?vrier 2019 03:58:12 > Objet: Re: RFR 8214719: Deprecate -Xverify:none option > Hi Remi, > > On 7/02/2019 8:15 am, Remi Forax wrote: >> Hi Harold, >> -noverify is very useful for debugging, >> i use it either because i think that the verifier has an error (array covariance >> of value types is a recent example) or because i want to simulate in a test a >> class that will not be verified at runtime (by example an anonymous classes). >> >> I see no problem to move it under the diagnostic flag but deprecate it (and then >> its removal) will make my life more painful. > > You can use the -XX flags previously mentioned instead. you mean, -XX:-BytecodeVerificationRemote and -XX:-BytecodeVerificationLocal yes, i've just discovered them. > > The existence of -noverify could be seen as a historical error as it's > defined as a standard launcher flag when at best it should have been a > -X flag, or more appropriately -XX. > i agree. > Cheers, > David regards, R?mi > >> >> R?mi >> >> ----- Mail original ----- >>> De: "Harold David Seigel" >>> ?: "hotspot-dev" >>> Envoy?: Mercredi 6 F?vrier 2019 15:18:02 >>> Objet: RFR 8214719: Deprecate -Xverify:none option >> >>> Hi, >>> >>> Please review this change to deprecate the -Xverify:none and -noverify >>> options in JDK-13.? The following warning message will be issued when >>> these options are used: >>> >>> ?warning: Options -Xverify:none and -noverify were deprecated in >>> version 13.0 and will likely be removed in a future release. >>> >>> The options were removed from tests that no longer needed them or the >>> options were changed as needed. >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >>> >>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 >>> >>> The fix was regression tested by running Mach5 tiers 1 and 2 tests and >>> builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on >>> Linux-x64, and by running JCK Lang and VM tests on Linux-x64. >>> > >> Thanks, Harold From shade at redhat.com Thu Feb 7 13:07:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 7 Feb 2019 14:07:40 +0100 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <943aeb27-6ab9-e0d4-2bec-f83fb10df6d7@oracle.com> References: <0cd0c5ff-11a5-44db-aea1-d02748b6728f@redhat.com> <5d581b70-a575-777e-0f29-8aae92cd4d93@oracle.com> <31f17b94-bb37-d404-47dc-d26fd32b1b8a@oracle.com> <943aeb27-6ab9-e0d4-2bec-f83fb10df6d7@oracle.com> Message-ID: <353767b8-54a6-db6f-25a9-2c662e725af6@redhat.com> On 2/6/19 9:46 PM, Harold Seigel wrote: >> On 2/6/19 11:39 AM, Harold Seigel wrote: >>> Thank you for pointing out that I had not acknowledged David's comment.? I have since entered a >>> response pointing out that users can now use AppCDS to get their performance boost because AppCDS >>> code is verified at archive time. >>> >>> Does the availability of AppCDS allay your concerns about this change? The availability of AppCDS does not resolve my concerns: it requires additional work, has space overheads, potential I/O overheads, etc. The availability of -XX:+BytecodeVerification{Local,Remote} options does resolve my concerns, though! Is there a way to print out the message for "replacement" options in the deprecation message? Thanks, -Aleksey From robbin.ehn at oracle.com Thu Feb 7 16:05:11 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 7 Feb 2019 17:05:11 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: Hi all, here is the promised re-base (v06) on 8210832: Remove sneaky locking in class Monitor. v06_1 is just a straight re-base. Full: http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ Inc: http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ Passes stress test and t1-5. But there is a 'better' way. Before I added the more graceful "_vm_wait->wait();" semaphore in the while (_waiting_to_block > 0) { loop, it was a just a busy spin using the same back-off as the rolling forward loop. It turns out that we mostly never spin here at all, when all java threads are stop the callbacks is often already done. So the addition of the semaphore have no impact on our benchmarks and is mostly unused. This is because most threads are in java which we need to spin-wait since they can elide into native without doing a callback. My proposed re-base removes the the callbacks completely and let the vm thread do all thread accounting. All that the stopping threads needs to do is write state and safepoint id, everything else is handle by the vm thread. We trade 2 atomics + a local store per thread against doing 2 stores per thread by the vm thread. This makes it possible for a thread in vm to transition into blocked WITHOUT safepoint poll. Just set thread_blocked and promise to do safepoint poll when leaving that state. v06_2 Full: http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ Inc against v05: http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ Inc against v06_1: http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ v06_2 simplifies and removes ~200 LOC with same performance. If there is a case with a thread in vm taking long time, it will already screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I see no reason why we should not push v06_2. Passes stress test and t1-5. Thanks, Robbin On 1/15/19 11:39 AM, Robbin Ehn wrote: > Hi all, please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 > Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ > > Thanks to Dan for pre-reviewing a lot! > > Background: > ZGC often does very short safepoint operations. For a perspective, in a > specJBB2015 run, G1 can have young collection stops lasting about 170 ms. While > in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which > operation it is. The time it takes to stop and start the JavaThreads is relative > very large to a ZGC safepoint. With an operation that just takes 0.2ms the > overhead of stopping and starting JavaThreads is several times the operation. > > High-level functionality change: > Serializing the starting over Threads_lock takes time. > - Don't wait on Threads_lock use the WaitBarrier. > Serializing the stopping over Safepoint_lock takes time. > - Let threads stop in parallel, remove Safepoint_lock. > > Details: > JavaThreads have 2 abstract logical states: unsafe or safe. > - Safe means the JavaThread will not touch Java heap or VM internal structures > ? without doing a transition and block before doing so. > ??????? - The safe states are: > ??????????????? - When polls armed: _thread_in_native and _thread_blocked. > ??????????????? - When Threads_lock is held: externally suspended flag is set. > ??????? - VM Thread have polls armed and holds the Threads_lock during a > ????????? safepoint. > - Unsafe means that either Java heap or VM internal structures can be accessed > ? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. > ??????? - All combination that are not safe are unsafe. > > We cannot start a safepoint until all unsafe threads have transitioned to a safe > state. To make them safe, we arm polls in compiled code and make sure any > transition to another unsafe state will be blocked. JavaThreads which are unsafe > with state _thread_in_Java may transition to _thread_in_native without being > blocked, since it just became a safe thread and we can proceed. Any safe thread > may try to transition at any time to an unsafe state, thus coming into the > safepoint blocking code at any moment, e.g., after the safepoint is over, or > even at the beginning of next safepoint. > > The VMThread cannot tolerate false positives from the JavaThread thread state > because that would mean starting the safepoint without all JavaThreads being > safe. The two locks (Threads_lock and Safepoint_lock) make sure we never observe > false positives from the safepoint blocking code, if we remove them, how do we > handle false positives? > > By first publishing which barrier tag (safepoint counter) we will call > WaitBarrier.wait() with as the threads safepoint id and then change the state to > _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of > the state. A stable load of the thread state is successful if the thread > safepoint id is the same both before and after the load of the state and > safepoint id is current or InactiveSafepointCounter. If the stable load fails, > the thread is considered safepoint unsafe. It's no longer enough that thread is > have state _thread_blocked it must also have correct safepoint id before and > after we read the state. > > Performance: > The result of faster safepoints is that the average CPU time for JavaThreads > between safepoints is higher, thus increasing the allocation rate. The thread > that stops first waits shorter time until it gets started. Even the thread that > stops last also have shorter stop since we start them faster. If your > application is using a concurrent GC it may need re-tunning since each java > worker thread have an increased CPU time/allocation rate. Often this means max > performance is achieved using slightly less java worker threads than before. > Also the increase allocation rate means shorter time between GC safepoints. > - If you are using a non-concurrent GC, you should see improved latency and > ? throughput. > - After re-tunning with a concurrent GC throughput should be equal or better but > ? with better latency. But bear in mind this is a latency patch, not a > ? throughput one. > With current code a java thread is not to guarantee to run between safepoint (in > theory a java thread can be starved indefinitely), since the VM thread may > re-grab the Threads_locks before it woke up from previous safepoint. If the > GC/VM don't respect MMU (minimum mutator utilization) or if your machine is very > over-provisioned this can happen. > The current schema thus re-safepoint quickly if the java threads have not > started yet at the cost of latency. Since the new code uses the WaitBarrier with > the safepoint counter, all threads must roll forward to next safepoint by > getting at least some CPU time between two safepoints. Meaning MMU violations > are more obvious. > > Some examples on numbers: > - On a 16 strand machine synchronization and un-synchronization/starting is at > ? least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and > ? starting ~400->~100us. > ? (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). > - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster > ? synchronization time on 16 strands and ~5% score increase. In this case the GC > ? op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. > - specJBB2015 ParGC ~9% increase in critical-jops. > > Thanks, Robbin From kim.barrett at oracle.com Thu Feb 7 17:40:00 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 7 Feb 2019 12:40:00 -0500 Subject: open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5@oracle.com> > On Feb 6, 2019, at 9:08 AM, Ioi Lam wrote: > > I think this should be fixed. +1 > BTW, is there a way to forbid all the calls to ::open()? Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 From mandy.chung at oracle.com Thu Feb 7 18:07:36 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Feb 2019 10:07:36 -0800 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: References: Message-ID: The java launcher accepts `-noverify` and passes `-Xverify:none` to JVM. I expect the launcher should also be updated to pass -XX flags. Mandy On 2/6/19 6:18 AM, Harold Seigel wrote: > Hi, > > Please review this change to deprecate the -Xverify:none and -noverify > options in JDK-13.? The following warning message will be issued when > these options are used: > > ??? ?warning: Options -Xverify:none and -noverify were deprecated in > ?? version 13.0 and will likely be removed in a future release. > > The options were removed from tests that no longer needed them or the > options were changed as needed. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html > > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on > Linux-x64, and by running JCK Lang and VM tests on Linux-x64. > > Thanks, Harold > From ecki at zusammenkunft.net Thu Feb 7 19:17:56 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 7 Feb 2019 20:17:56 +0100 Subject: C2 Crash in Chunk/Arena - but with fine registers? Message-ID: <5c5c8463.1c69fb81.56f68.1874@mx.google.com> Hello, I have the Problem of randomly crashing OpenJDK JVMs (in my case Azul Zulu 8). Azul support was trying to help me, but the Problem seems to be elusive. The below happens in the C2 compiler while VM warmup (but very sporadic), but I expect it to be a more General Problem, so I am hoping somebody with Debugger black belt can explain what we see. One Thing we noticed is, that if you look at the crashdump, the PC and the Register Content do not match up: Stack with Debugging Symbols: # jvm!Chunk::operator new # jvm!Arena::grow+0x3c # jvm!OopFlow::make+0xb4 # jvm!Compile::BuildOopMaps+0x381 # jvm!Compile::Output+0x3b4 # jvm!Compile::Code_Gen+0x422 # jvm!Compile::Compile+0xbfe # jvm!C2Compiler::compile_method+0xa2 # jvm!CompileBroker::invoke_compiler_on_method+0x488 # jvm!CompileBroker::compiler_thread_loop+0x2ef # jvm!JavaThread::thread_main_inner+0xaf # jvm!java_start+0x8a # msvcr100!_callthreadstartex+0x17 # msvcr100!_threadstartex+0x7f # kernel32!BaseThreadInitThunk+0xd # ntdll!RtlUserThreadStart+0x1d Operation under PC # jvm!Chunk::operator new+0 [zulu-src\hotspot\src\share\vm\memory\allocation.cpp @ 375] # 00000000`64fb9180 48895c2410????? mov???? qword ptr [rsp+10h],rbx But the Registers in the exception record suggest they do not Point into page Zero/address 0x40: # EXCEPTION_RECORD:? (.exr -1) # ExceptionAddress: 0000000064fb9180 (jvm!Chunk::operator new) # ExceptionCode: c0000005 (Access violation) # ExceptionFlags: 00000000 # NumberParameters: 2 # Parameter[0]: 0000000000000000 # Parameter[1]: 0000000000000040 # Attempt to read from address 0000000000000040 # Registers: # RBX=0x000000002ec17da0 # RSP=0x000000003025c4b8 is pointing into the stack for thread: 0x000000002ee08800 Did you ever seen that? Is that a Problem of the Dump or can that be some microcode Problems related to Spectre (I feel it happens more often since BIOS update). Rest of the error log. Current thread (0x000000002ee08800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=2212, stack(0x0000000030160000,0x0000000030260000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000040 Registers: RAX=0x0000000000000000, RBX=0x000000002ec17da0, RCX=0x0000000000000010, RDX=0x0000000000000000 RSP=0x000000003025c4b8, RBP=0x00000000000007b0, RSI=0x0000000000007fd8, RDI=0x0000000032976e10 R8 =0x0000000000007fd8, R9 =0x0000000000000002, R10=0x0000000000000010, R11=0x0000000000000002 R12=0x00000000000000f5, R13=0x000000003025eb00, R14=0x0000000032785930, R15=0x0000000030d824a0 RIP=0x0000000064fb9180, EFLAGS=0x0000000000010297 Top of Stack: (sp=0x000000003025c4b8) 0x000000003025c4b8: 0000000064fb970c 00000000329777f0 0x000000003025c4c8: 0000000000000030 00000000000000f4 0x000000003025c4d8: 000000003025c740 00000000000007b0 0x000000003025c4e8: 0000000065334e64 000000002ec17da0 0x000000003025c4f8: 000000003297e470 000000003297e660 0x000000003025c508: 000000003025eb00 0000000000000008 0x000000003025c518: 000000003025eb00 0000000030d823b0 0x000000003025c528: 00000000653360c1 0000000031288f50 0x000000003025c538: 000000003025c5a8 000000003297e440 0x000000003025c548: 00000000325ff120 000000002ec17da0 0x000000003025c558: 00000000325ff120 000000002ec17da0 0x000000003025c568: 00000000000001e8 00000000000007a0 0x000000003025c578: 0000000000000080 000000002ec17da0 0x000000003025c588: 0000000032aedb10 0000000000000046 0x000000003025c598: 000000002ee08800 000000002f007ab0 0x000000003025c5a8: 00000000654bc3a8 000000003025eb00 Instructions: (pc=0x0000000064fb9180) 0x0000000064fb9160: 00 00 e8 29 ff ff ff 48 8b 0d 8a 8d 71 00 ba 05 0x0000000064fb9170: 00 00 00 48 83 c4 28 e9 14 ff ff ff cc cc cc cc 0x0000000064fb9180: 48 89 5c 24 10 57 48 83 ec 60 48 8d 59 0f 8b fa 0x0000000064fb9190: 48 83 e3 f0 49 03 d8 49 81 f8 d8 00 00 00 0f 84 Register to memory mapping: RAX=0x0000000000000000 is an unknown value RBX=0x000000002ec17da0 is an unknown value RCX=0x0000000000000010 is an unknown value RDX=0x0000000000000000 is an unknown value RSP=0x000000003025c4b8 is pointing into the stack for thread: 0x000000002ee08800 RBP=0x00000000000007b0 is an unknown value RSI=0x0000000000007fd8 is an unknown value RDI=0x0000000032976e10 is an unknown value R8 =0x0000000000007fd8 is an unknown value R9 =0x0000000000000002 is an unknown value R10=0x0000000000000010 is an unknown value R11=0x0000000000000002 is an unknown value R12=0x00000000000000f5 is an unknown value R13=0x000000003025eb00 is pointing into the stack for thread: 0x000000002ee08800 R14=0x0000000032785930 is an unknown value R15=0x0000000030d824a0 is an unknown value Stack: [0x0000000030160000,0x0000000030260000], sp=0x000000003025c4b8, free space=1009k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0xa9180] V [jvm.dll+0xa970c] V [jvm.dll+0x424e64] V [jvm.dll+0x4260c1] V [jvm.dll+0x4cb8c4] V [jvm.dll+0x442192] V [jvm.dll+0x44492e] V [jvm.dll+0x427952] V [jvm.dll+0x82148] V [jvm.dll+0x82a7f] V [jvm.dll+0x21e16f] V [jvm.dll+0x26f9ba] C [msvcr100.dll+0x21d9f] C [msvcr100.dll+0x21e3b] C [KERNEL32.DLL+0x16ad] C [ntdll.dll+0x74629] I also have the minidump if needed (I dont have the Symbols Right now) Gruss Bernd -- http://bernd.eckenfels.net From mandy.chung at oracle.com Thu Feb 7 19:25:35 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 7 Feb 2019 11:25:35 -0800 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: References: Message-ID: I see it now that no launcher change is needed as we want VM to detect if -noverify is used and emit the warning as well. No issue from me now. Mandy On 2/7/19 10:07 AM, Mandy Chung wrote: > The java launcher accepts `-noverify` and passes `-Xverify:none` to > JVM.? I expect the launcher should also be updated to pass -XX > flags. > > Mandy > > On 2/6/19 6:18 AM, Harold Seigel wrote: >> Hi, >> >> Please review this change to deprecate the -Xverify:none and -noverify >> options in JDK-13.? The following warning message will be issued when >> these options are used: >> >> ???? ?warning: Options -Xverify:none and -noverify were deprecated in >> ??? version 13.0 and will likely be removed in a future release. >> >> The options were removed from tests that no longer needed them or the >> options were changed as needed. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >> >> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests and >> builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on >> Linux-x64, and by running JCK Lang and VM tests on Linux-x64. >> >> Thanks, Harold >> From ecki at zusammenkunft.net Thu Feb 7 20:35:24 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 7 Feb 2019 21:35:24 +0100 Subject: RFR 8214719: Deprecate -Xverify:none option Message-ID: <5c5c968c.1c69fb81.e4d29.450f@mx.google.com> BTW, just want to mention, we had quite some work to do to remove -verify:none from a complex application Server due to class Validation fail when the classpath (especially in OSGi) was incomplete. Verifying a class seems to fail if types used in the signature of the class are missing. This new requirement of validating classes is not present when verifyer is turned off ? which means those unused but needed classes can creep into your deployment. So it is not trivial to fix and therefore a deprecation Messages (as opposed to doc) should exist to give people a heads up. Besides I would agree that with less and less sandbox Java applications and with a plan to downsize the security Manager having the non-verifyer optimization removed seems contraproductive (especially as Long as CDS is not mature). Gruss Bernd -- http://bernd.eckenfels.net From mikael.vidstedt at oracle.com Thu Feb 7 21:58:50 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 7 Feb 2019 13:58:50 -0800 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <5c5c968c.1c69fb81.e4d29.450f@mx.google.com> References: <5c5c968c.1c69fb81.e4d29.450f@mx.google.com> Message-ID: <258D1EF9-F7FC-4580-A617-21897A4B5716@oracle.com> > On Feb 7, 2019, at 12:35 PM, Bernd Eckenfels wrote: > > Besides I would agree that with less and less sandbox Java applications and with a plan to downsize the security Manager having the non-verifyer optimization removed seems contraproductive (especially as Long as CDS is not mature). Out of curiosity, what makes you say that CDS is not mature? Cheers, Mikael From ecki at zusammenkunft.net Thu Feb 7 23:59:34 2019 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 7 Feb 2019 23:59:34 +0000 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <258D1EF9-F7FC-4580-A617-21897A4B5716@oracle.com> References: <5c5c968c.1c69fb81.e4d29.450f@mx.google.com>, <258D1EF9-F7FC-4580-A617-21897A4B5716@oracle.com> Message-ID: Mostly the age of the feature, App CDS is rather young. I would feel uneasy to use that in production, but maybe it?s just me. Furthermore, as far as I understand it does not yet work with Java EE servers or OSGi frameworks. Both are the most heavy candidates for verify:none. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Mikael Vidstedt Gesendet: Donnerstag, Februar 7, 2019 11:00 PM An: Bernd Eckenfels Cc: hotspot-dev developers Betreff: Re: RFR 8214719: Deprecate -Xverify:none option > On Feb 7, 2019, at 12:35 PM, Bernd Eckenfels wrote: > > Besides I would agree that with less and less sandbox Java applications and with a plan to downsize the security Manager having the non-verifyer optimization removed seems contraproductive (especially as Long as CDS is not mature). Out of curiosity, what makes you say that CDS is not mature? Cheers, Mikael From patricio.chilano.mateo at oracle.com Fri Feb 8 15:58:47 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 8 Feb 2019 10:58:47 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: Hi Robbin, Version v06_2 looks good to me. One minor comment: --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp @@ -314,9 +314,6 @@ ???? // Once we are blocked vm expects stack to be walkable ???? thread->frame_anchor()->make_walkable(thread); -??? thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); -??? InterfaceSupport::serialize_thread_state_with_handler(thread); - ???? thread->set_thread_state(_thread_blocked); Since we are not calling SS::block() anymore in the TBIVMWDC constructor we can remove setting the thread state to the temporary _thread_in_vm_trans and also the fence after that. Thanks, Patricio On 2/7/19 11:05 AM, Robbin Ehn wrote: > Hi all, here is the promised re-base (v06) on > 8210832: Remove sneaky locking in class Monitor. > > v06_1 is just a straight re-base. > > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ > Inc: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ > > Passes stress test and t1-5. > > But there is a 'better' way. > Before I added the more graceful "_vm_wait->wait();" semaphore in the > while > (_waiting_to_block > 0) { loop, it was a just a busy spin using the same > back-off as the rolling forward loop. It turns out that we mostly > never spin > here at all, when all java threads are stop the callbacks is often > already done. > So the addition of the semaphore have no impact on our benchmarks and > is mostly > unused. This is because most threads are in java which we need to > spin-wait > since they can elide into native without doing a callback. My proposed > re-base > removes the the callbacks completely and let the vm thread do all thread > accounting. All that the stopping threads needs to do is write state and > safepoint id, everything else is handle by the vm thread. We trade 2 > atomics + > a local store per thread against doing 2 stores per thread by the vm > thread. > This makes it possible for a thread in vm to transition into blocked > WITHOUT > safepoint poll. Just set thread_blocked and promise to do safepoint > poll when > leaving that state. > > v06_2 > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ > Inc against v05: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ > Inc against v06_1: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ > > v06_2 simplifies and removes ~200 LOC with same performance. > If there is a case with a thread in vm taking long time, it will already > screw-up latency and thus should be fixed regardless of v06_1 vs > v06_2. So I > see no reason why we should not push v06_2. > > Passes stress test and t1-5. > > Thanks, Robbin > > > On 1/15/19 11:39 AM, Robbin Ehn wrote: >> Hi all, please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >> >> Thanks to Dan for pre-reviewing a lot! >> >> Background: >> ZGC often does very short safepoint operations. For a perspective, in a >> specJBB2015 run, G1 can have young collection stops lasting about 170 >> ms. While >> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >> operation it is. The time it takes to stop and start the JavaThreads >> is relative >> very large to a ZGC safepoint. With an operation that just takes >> 0.2ms the >> overhead of stopping and starting JavaThreads is several times the >> operation. >> >> High-level functionality change: >> Serializing the starting over Threads_lock takes time. >> - Don't wait on Threads_lock use the WaitBarrier. >> Serializing the stopping over Safepoint_lock takes time. >> - Let threads stop in parallel, remove Safepoint_lock. >> >> Details: >> JavaThreads have 2 abstract logical states: unsafe or safe. >> - Safe means the JavaThread will not touch Java heap or VM internal >> structures >> ?? without doing a transition and block before doing so. >> ???????? - The safe states are: >> ???????????????? - When polls armed: _thread_in_native and >> _thread_blocked. >> ???????????????? - When Threads_lock is held: externally suspended >> flag is set. >> ???????? - VM Thread have polls armed and holds the Threads_lock >> during a >> ?????????? safepoint. >> - Unsafe means that either Java heap or VM internal structures can be >> accessed >> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >> ???????? - All combination that are not safe are unsafe. >> >> We cannot start a safepoint until all unsafe threads have >> transitioned to a safe >> state. To make them safe, we arm polls in compiled code and make sure >> any >> transition to another unsafe state will be blocked. JavaThreads which >> are unsafe >> with state _thread_in_Java may transition to _thread_in_native >> without being >> blocked, since it just became a safe thread and we can proceed. Any >> safe thread >> may try to transition at any time to an unsafe state, thus coming >> into the >> safepoint blocking code at any moment, e.g., after the safepoint is >> over, or >> even at the beginning of next safepoint. >> >> The VMThread cannot tolerate false positives from the JavaThread >> thread state >> because that would mean starting the safepoint without all >> JavaThreads being >> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >> never observe >> false positives from the safepoint blocking code, if we remove them, >> how do we >> handle false positives? >> >> By first publishing which barrier tag (safepoint counter) we will call >> WaitBarrier.wait() with as the threads safepoint id and then change >> the state to >> _thread_blocked, the VMThread can ignore JavaThreads by doing a >> stable load of >> the state. A stable load of the thread state is successful if the thread >> safepoint id is the same both before and after the load of the state and >> safepoint id is current or InactiveSafepointCounter. If the stable >> load fails, >> the thread is considered safepoint unsafe. It's no longer enough that >> thread is >> have state _thread_blocked it must also have correct safepoint id >> before and >> after we read the state. >> >> Performance: >> The result of faster safepoints is that the average CPU time for >> JavaThreads >> between safepoints is higher, thus increasing the allocation rate. >> The thread >> that stops first waits shorter time until it gets started. Even the >> thread that >> stops last also have shorter stop since we start them faster. If your >> application is using a concurrent GC it may need re-tunning since >> each java >> worker thread have an increased CPU time/allocation rate. Often this >> means max >> performance is achieved using slightly less java worker threads than >> before. >> Also the increase allocation rate means shorter time between GC >> safepoints. >> - If you are using a non-concurrent GC, you should see improved >> latency and >> ?? throughput. >> - After re-tunning with a concurrent GC throughput should be equal or >> better but >> ?? with better latency. But bear in mind this is a latency patch, not a >> ?? throughput one. >> With current code a java thread is not to guarantee to run between >> safepoint (in >> theory a java thread can be starved indefinitely), since the VM >> thread may >> re-grab the Threads_locks before it woke up from previous safepoint. >> If the >> GC/VM don't respect MMU (minimum mutator utilization) or if your >> machine is very >> over-provisioned this can happen. >> The current schema thus re-safepoint quickly if the java threads have >> not >> started yet at the cost of latency. Since the new code uses the >> WaitBarrier with >> the safepoint counter, all threads must roll forward to next >> safepoint by >> getting at least some CPU time between two safepoints. Meaning MMU >> violations >> are more obvious. >> >> Some examples on numbers: >> - On a 16 strand machine synchronization and >> un-synchronization/starting is at >> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >> ~100us and >> ?? starting ~400->~100us. >> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >> Linux). >> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >> ?? synchronization time on 16 strands and ~5% score increase. In this >> case the GC >> ?? op is 1ms, so we reduce the overhead of synchronization from 100% >> to 10%. >> - specJBB2015 ParGC ~9% increase in critical-jops. >> >> Thanks, Robbin From patricio.chilano.mateo at oracle.com Fri Feb 8 16:46:55 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 8 Feb 2019 11:46:55 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: <24d259f5-100e-d7ea-a30f-1b0694f36767@oracle.com> Correction about the fence, I think we actually need it to avoid the change of state to _thread_blocked to float above frame_anchor()->make_walkable. So it should be: --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp @@ -314,8 +314,7 @@ ???? // Once we are blocked vm expects stack to be walkable ???? thread->frame_anchor()->make_walkable(thread); -??? thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); -??? InterfaceSupport::serialize_thread_state_with_handler(thread); +??? OrderAccess::storestore(); ???? thread->set_thread_state(_thread_blocked); Otherwise if we keep "InterfaceSupport::serialize_thread_state_with_handler(thread);" maybe we should also change the comment "// Make sure new state is seen by VM thread". Thanks, Patricio On 2/8/19 10:58 AM, Patricio Chilano wrote: > Hi Robbin, > > Version v06_2 looks good to me. One minor comment: > > --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp > +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp > @@ -314,9 +314,6 @@ > ???? // Once we are blocked vm expects stack to be walkable > ???? thread->frame_anchor()->make_walkable(thread); > > -??? thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); > - InterfaceSupport::serialize_thread_state_with_handler(thread); > - > ???? thread->set_thread_state(_thread_blocked); > > Since we are not calling SS::block() anymore in the TBIVMWDC > constructor we can remove setting the thread state to the temporary > _thread_in_vm_trans and also the fence after that. > > > Thanks, > Patricio > > On 2/7/19 11:05 AM, Robbin Ehn wrote: >> Hi all, here is the promised re-base (v06) on >> 8210832: Remove sneaky locking in class Monitor. >> >> v06_1 is just a straight re-base. >> >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >> Inc: >> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >> >> Passes stress test and t1-5. >> >> But there is a 'better' way. >> Before I added the more graceful "_vm_wait->wait();" semaphore in the >> while >> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >> back-off as the rolling forward loop. It turns out that we mostly >> never spin >> here at all, when all java threads are stop the callbacks is often >> already done. >> So the addition of the semaphore have no impact on our benchmarks and >> is mostly >> unused. This is because most threads are in java which we need to >> spin-wait >> since they can elide into native without doing a callback. My >> proposed re-base >> removes the the callbacks completely and let the vm thread do all thread >> accounting. All that the stopping threads needs to do is write state and >> safepoint id, everything else is handle by the vm thread. We trade 2 >> atomics + >> a local store per thread against doing 2 stores per thread by the vm >> thread. >> This makes it possible for a thread in vm to transition into blocked >> WITHOUT >> safepoint poll. Just set thread_blocked and promise to do safepoint >> poll when >> leaving that state. >> >> v06_2 >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >> Inc against v05: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >> Inc against v06_1: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >> >> v06_2 simplifies and removes ~200 LOC with same performance. >> If there is a case with a thread in vm taking long time, it will already >> screw-up latency and thus should be fixed regardless of v06_1 vs >> v06_2. So I >> see no reason why we should not push v06_2. >> >> Passes stress test and t1-5. >> >> Thanks, Robbin >> >> >> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>> Hi all, please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>> >>> Thanks to Dan for pre-reviewing a lot! >>> >>> Background: >>> ZGC often does very short safepoint operations. For a perspective, in a >>> specJBB2015 run, G1 can have young collection stops lasting about >>> 170 ms. While >>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on >>> which >>> operation it is. The time it takes to stop and start the JavaThreads >>> is relative >>> very large to a ZGC safepoint. With an operation that just takes >>> 0.2ms the >>> overhead of stopping and starting JavaThreads is several times the >>> operation. >>> >>> High-level functionality change: >>> Serializing the starting over Threads_lock takes time. >>> - Don't wait on Threads_lock use the WaitBarrier. >>> Serializing the stopping over Safepoint_lock takes time. >>> - Let threads stop in parallel, remove Safepoint_lock. >>> >>> Details: >>> JavaThreads have 2 abstract logical states: unsafe or safe. >>> - Safe means the JavaThread will not touch Java heap or VM internal >>> structures >>> ?? without doing a transition and block before doing so. >>> ???????? - The safe states are: >>> ???????????????? - When polls armed: _thread_in_native and >>> _thread_blocked. >>> ???????????????? - When Threads_lock is held: externally suspended >>> flag is set. >>> ???????? - VM Thread have polls armed and holds the Threads_lock >>> during a >>> ?????????? safepoint. >>> - Unsafe means that either Java heap or VM internal structures can >>> be accessed >>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>> ???????? - All combination that are not safe are unsafe. >>> >>> We cannot start a safepoint until all unsafe threads have >>> transitioned to a safe >>> state. To make them safe, we arm polls in compiled code and make >>> sure any >>> transition to another unsafe state will be blocked. JavaThreads >>> which are unsafe >>> with state _thread_in_Java may transition to _thread_in_native >>> without being >>> blocked, since it just became a safe thread and we can proceed. Any >>> safe thread >>> may try to transition at any time to an unsafe state, thus coming >>> into the >>> safepoint blocking code at any moment, e.g., after the safepoint is >>> over, or >>> even at the beginning of next safepoint. >>> >>> The VMThread cannot tolerate false positives from the JavaThread >>> thread state >>> because that would mean starting the safepoint without all >>> JavaThreads being >>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >>> never observe >>> false positives from the safepoint blocking code, if we remove them, >>> how do we >>> handle false positives? >>> >>> By first publishing which barrier tag (safepoint counter) we will call >>> WaitBarrier.wait() with as the threads safepoint id and then change >>> the state to >>> _thread_blocked, the VMThread can ignore JavaThreads by doing a >>> stable load of >>> the state. A stable load of the thread state is successful if the >>> thread >>> safepoint id is the same both before and after the load of the state >>> and >>> safepoint id is current or InactiveSafepointCounter. If the stable >>> load fails, >>> the thread is considered safepoint unsafe. It's no longer enough >>> that thread is >>> have state _thread_blocked it must also have correct safepoint id >>> before and >>> after we read the state. >>> >>> Performance: >>> The result of faster safepoints is that the average CPU time for >>> JavaThreads >>> between safepoints is higher, thus increasing the allocation rate. >>> The thread >>> that stops first waits shorter time until it gets started. Even the >>> thread that >>> stops last also have shorter stop since we start them faster. If your >>> application is using a concurrent GC it may need re-tunning since >>> each java >>> worker thread have an increased CPU time/allocation rate. Often this >>> means max >>> performance is achieved using slightly less java worker threads than >>> before. >>> Also the increase allocation rate means shorter time between GC >>> safepoints. >>> - If you are using a non-concurrent GC, you should see improved >>> latency and >>> ?? throughput. >>> - After re-tunning with a concurrent GC throughput should be equal >>> or better but >>> ?? with better latency. But bear in mind this is a latency patch, not a >>> ?? throughput one. >>> With current code a java thread is not to guarantee to run between >>> safepoint (in >>> theory a java thread can be starved indefinitely), since the VM >>> thread may >>> re-grab the Threads_locks before it woke up from previous safepoint. >>> If the >>> GC/VM don't respect MMU (minimum mutator utilization) or if your >>> machine is very >>> over-provisioned this can happen. >>> The current schema thus re-safepoint quickly if the java threads >>> have not >>> started yet at the cost of latency. Since the new code uses the >>> WaitBarrier with >>> the safepoint counter, all threads must roll forward to next >>> safepoint by >>> getting at least some CPU time between two safepoints. Meaning MMU >>> violations >>> are more obvious. >>> >>> Some examples on numbers: >>> - On a 16 strand machine synchronization and >>> un-synchronization/starting is at >>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >>> ~100us and >>> ?? starting ~400->~100us. >>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >>> Linux). >>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>> ?? synchronization time on 16 strands and ~5% score increase. In >>> this case the GC >>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% >>> to 10%. >>> - specJBB2015 ParGC ~9% increase in critical-jops. >>> >>> Thanks, Robbin > From daniel.daugherty at oracle.com Fri Feb 8 19:33:32 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Feb 2019 14:33:32 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: On 2/7/19 11:05 AM, Robbin Ehn wrote: > Hi all, here is the promised re-base (v06) on > 8210832: Remove sneaky locking in class Monitor. > > v06_1 is just a straight re-base. > > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ > Inc: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ Something is wrong with this incremental webrev. I was expecting an incremental webrev relative to the v05 version, but that's not what I see in src/hotspot/share/runtime/safepoint.cpp. In that file I'm seeing changes relative to the baseline, e.g., deletion of the Safepoint_lock, etc. Dan > > Passes stress test and t1-5. > > But there is a 'better' way. > Before I added the more graceful "_vm_wait->wait();" semaphore in the > while > (_waiting_to_block > 0) { loop, it was a just a busy spin using the same > back-off as the rolling forward loop. It turns out that we mostly > never spin > here at all, when all java threads are stop the callbacks is often > already done. > So the addition of the semaphore have no impact on our benchmarks and > is mostly > unused. This is because most threads are in java which we need to > spin-wait > since they can elide into native without doing a callback. My proposed > re-base > removes the the callbacks completely and let the vm thread do all thread > accounting. All that the stopping threads needs to do is write state and > safepoint id, everything else is handle by the vm thread. We trade 2 > atomics + > a local store per thread against doing 2 stores per thread by the vm > thread. > This makes it possible for a thread in vm to transition into blocked > WITHOUT > safepoint poll. Just set thread_blocked and promise to do safepoint > poll when > leaving that state. > > v06_2 > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ > Inc against v05: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ > Inc against v06_1: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ > > v06_2 simplifies and removes ~200 LOC with same performance. > If there is a case with a thread in vm taking long time, it will already > screw-up latency and thus should be fixed regardless of v06_1 vs > v06_2. So I > see no reason why we should not push v06_2. > > Passes stress test and t1-5. > > Thanks, Robbin > > > On 1/15/19 11:39 AM, Robbin Ehn wrote: >> Hi all, please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >> >> Thanks to Dan for pre-reviewing a lot! >> >> Background: >> ZGC often does very short safepoint operations. For a perspective, in a >> specJBB2015 run, G1 can have young collection stops lasting about 170 >> ms. While >> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >> operation it is. The time it takes to stop and start the JavaThreads >> is relative >> very large to a ZGC safepoint. With an operation that just takes >> 0.2ms the >> overhead of stopping and starting JavaThreads is several times the >> operation. >> >> High-level functionality change: >> Serializing the starting over Threads_lock takes time. >> - Don't wait on Threads_lock use the WaitBarrier. >> Serializing the stopping over Safepoint_lock takes time. >> - Let threads stop in parallel, remove Safepoint_lock. >> >> Details: >> JavaThreads have 2 abstract logical states: unsafe or safe. >> - Safe means the JavaThread will not touch Java heap or VM internal >> structures >> ?? without doing a transition and block before doing so. >> ???????? - The safe states are: >> ???????????????? - When polls armed: _thread_in_native and >> _thread_blocked. >> ???????????????? - When Threads_lock is held: externally suspended >> flag is set. >> ???????? - VM Thread have polls armed and holds the Threads_lock >> during a >> ?????????? safepoint. >> - Unsafe means that either Java heap or VM internal structures can be >> accessed >> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >> ???????? - All combination that are not safe are unsafe. >> >> We cannot start a safepoint until all unsafe threads have >> transitioned to a safe >> state. To make them safe, we arm polls in compiled code and make sure >> any >> transition to another unsafe state will be blocked. JavaThreads which >> are unsafe >> with state _thread_in_Java may transition to _thread_in_native >> without being >> blocked, since it just became a safe thread and we can proceed. Any >> safe thread >> may try to transition at any time to an unsafe state, thus coming >> into the >> safepoint blocking code at any moment, e.g., after the safepoint is >> over, or >> even at the beginning of next safepoint. >> >> The VMThread cannot tolerate false positives from the JavaThread >> thread state >> because that would mean starting the safepoint without all >> JavaThreads being >> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >> never observe >> false positives from the safepoint blocking code, if we remove them, >> how do we >> handle false positives? >> >> By first publishing which barrier tag (safepoint counter) we will call >> WaitBarrier.wait() with as the threads safepoint id and then change >> the state to >> _thread_blocked, the VMThread can ignore JavaThreads by doing a >> stable load of >> the state. A stable load of the thread state is successful if the thread >> safepoint id is the same both before and after the load of the state and >> safepoint id is current or InactiveSafepointCounter. If the stable >> load fails, >> the thread is considered safepoint unsafe. It's no longer enough that >> thread is >> have state _thread_blocked it must also have correct safepoint id >> before and >> after we read the state. >> >> Performance: >> The result of faster safepoints is that the average CPU time for >> JavaThreads >> between safepoints is higher, thus increasing the allocation rate. >> The thread >> that stops first waits shorter time until it gets started. Even the >> thread that >> stops last also have shorter stop since we start them faster. If your >> application is using a concurrent GC it may need re-tunning since >> each java >> worker thread have an increased CPU time/allocation rate. Often this >> means max >> performance is achieved using slightly less java worker threads than >> before. >> Also the increase allocation rate means shorter time between GC >> safepoints. >> - If you are using a non-concurrent GC, you should see improved >> latency and >> ?? throughput. >> - After re-tunning with a concurrent GC throughput should be equal or >> better but >> ?? with better latency. But bear in mind this is a latency patch, not a >> ?? throughput one. >> With current code a java thread is not to guarantee to run between >> safepoint (in >> theory a java thread can be starved indefinitely), since the VM >> thread may >> re-grab the Threads_locks before it woke up from previous safepoint. >> If the >> GC/VM don't respect MMU (minimum mutator utilization) or if your >> machine is very >> over-provisioned this can happen. >> The current schema thus re-safepoint quickly if the java threads have >> not >> started yet at the cost of latency. Since the new code uses the >> WaitBarrier with >> the safepoint counter, all threads must roll forward to next >> safepoint by >> getting at least some CPU time between two safepoints. Meaning MMU >> violations >> are more obvious. >> >> Some examples on numbers: >> - On a 16 strand machine synchronization and >> un-synchronization/starting is at >> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >> ~100us and >> ?? starting ~400->~100us. >> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >> Linux). >> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >> ?? synchronization time on 16 strands and ~5% score increase. In this >> case the GC >> ?? op is 1ms, so we reduce the overhead of synchronization from 100% >> to 10%. >> - specJBB2015 ParGC ~9% increase in critical-jops. >> >> Thanks, Robbin From daniel.daugherty at oracle.com Fri Feb 8 20:01:28 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Feb 2019 15:01:28 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: On 2/8/19 2:33 PM, Daniel D. Daugherty wrote: > On 2/7/19 11:05 AM, Robbin Ehn wrote: >> Hi all, here is the promised re-base (v06) on >> 8210832: Remove sneaky locking in class Monitor. >> >> v06_1 is just a straight re-base. >> >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >> Inc: >> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ > > Something is wrong with this incremental webrev. I was expecting an > incremental webrev relative to the v05 version, but that's not > what I see in src/hotspot/share/runtime/safepoint.cpp. In that file > I'm seeing changes relative to the baseline, e.g., deletion of the > Safepoint_lock, etc. So I dropped back to the full patch for v05 and tried to compare that to the v06_1/full patch above using jfilemerge. That's not working for me either. Next I'm going to just look at the v06_1/full webrev and see if that makes sense. Dan > > Dan > > > >> >> Passes stress test and t1-5. >> >> But there is a 'better' way. >> Before I added the more graceful "_vm_wait->wait();" semaphore in the >> while >> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >> back-off as the rolling forward loop. It turns out that we mostly >> never spin >> here at all, when all java threads are stop the callbacks is often >> already done. >> So the addition of the semaphore have no impact on our benchmarks and >> is mostly >> unused. This is because most threads are in java which we need to >> spin-wait >> since they can elide into native without doing a callback. My >> proposed re-base >> removes the the callbacks completely and let the vm thread do all thread >> accounting. All that the stopping threads needs to do is write state and >> safepoint id, everything else is handle by the vm thread. We trade 2 >> atomics + >> a local store per thread against doing 2 stores per thread by the vm >> thread. >> This makes it possible for a thread in vm to transition into blocked >> WITHOUT >> safepoint poll. Just set thread_blocked and promise to do safepoint >> poll when >> leaving that state. >> >> v06_2 >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >> Inc against v05: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >> Inc against v06_1: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >> >> v06_2 simplifies and removes ~200 LOC with same performance. >> If there is a case with a thread in vm taking long time, it will already >> screw-up latency and thus should be fixed regardless of v06_1 vs >> v06_2. So I >> see no reason why we should not push v06_2. >> >> Passes stress test and t1-5. >> >> Thanks, Robbin >> >> >> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>> Hi all, please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>> >>> Thanks to Dan for pre-reviewing a lot! >>> >>> Background: >>> ZGC often does very short safepoint operations. For a perspective, in a >>> specJBB2015 run, G1 can have young collection stops lasting about >>> 170 ms. While >>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on >>> which >>> operation it is. The time it takes to stop and start the JavaThreads >>> is relative >>> very large to a ZGC safepoint. With an operation that just takes >>> 0.2ms the >>> overhead of stopping and starting JavaThreads is several times the >>> operation. >>> >>> High-level functionality change: >>> Serializing the starting over Threads_lock takes time. >>> - Don't wait on Threads_lock use the WaitBarrier. >>> Serializing the stopping over Safepoint_lock takes time. >>> - Let threads stop in parallel, remove Safepoint_lock. >>> >>> Details: >>> JavaThreads have 2 abstract logical states: unsafe or safe. >>> - Safe means the JavaThread will not touch Java heap or VM internal >>> structures >>> ?? without doing a transition and block before doing so. >>> ???????? - The safe states are: >>> ???????????????? - When polls armed: _thread_in_native and >>> _thread_blocked. >>> ???????????????? - When Threads_lock is held: externally suspended >>> flag is set. >>> ???????? - VM Thread have polls armed and holds the Threads_lock >>> during a >>> ?????????? safepoint. >>> - Unsafe means that either Java heap or VM internal structures can >>> be accessed >>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>> ???????? - All combination that are not safe are unsafe. >>> >>> We cannot start a safepoint until all unsafe threads have >>> transitioned to a safe >>> state. To make them safe, we arm polls in compiled code and make >>> sure any >>> transition to another unsafe state will be blocked. JavaThreads >>> which are unsafe >>> with state _thread_in_Java may transition to _thread_in_native >>> without being >>> blocked, since it just became a safe thread and we can proceed. Any >>> safe thread >>> may try to transition at any time to an unsafe state, thus coming >>> into the >>> safepoint blocking code at any moment, e.g., after the safepoint is >>> over, or >>> even at the beginning of next safepoint. >>> >>> The VMThread cannot tolerate false positives from the JavaThread >>> thread state >>> because that would mean starting the safepoint without all >>> JavaThreads being >>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >>> never observe >>> false positives from the safepoint blocking code, if we remove them, >>> how do we >>> handle false positives? >>> >>> By first publishing which barrier tag (safepoint counter) we will call >>> WaitBarrier.wait() with as the threads safepoint id and then change >>> the state to >>> _thread_blocked, the VMThread can ignore JavaThreads by doing a >>> stable load of >>> the state. A stable load of the thread state is successful if the >>> thread >>> safepoint id is the same both before and after the load of the state >>> and >>> safepoint id is current or InactiveSafepointCounter. If the stable >>> load fails, >>> the thread is considered safepoint unsafe. It's no longer enough >>> that thread is >>> have state _thread_blocked it must also have correct safepoint id >>> before and >>> after we read the state. >>> >>> Performance: >>> The result of faster safepoints is that the average CPU time for >>> JavaThreads >>> between safepoints is higher, thus increasing the allocation rate. >>> The thread >>> that stops first waits shorter time until it gets started. Even the >>> thread that >>> stops last also have shorter stop since we start them faster. If your >>> application is using a concurrent GC it may need re-tunning since >>> each java >>> worker thread have an increased CPU time/allocation rate. Often this >>> means max >>> performance is achieved using slightly less java worker threads than >>> before. >>> Also the increase allocation rate means shorter time between GC >>> safepoints. >>> - If you are using a non-concurrent GC, you should see improved >>> latency and >>> ?? throughput. >>> - After re-tunning with a concurrent GC throughput should be equal >>> or better but >>> ?? with better latency. But bear in mind this is a latency patch, not a >>> ?? throughput one. >>> With current code a java thread is not to guarantee to run between >>> safepoint (in >>> theory a java thread can be starved indefinitely), since the VM >>> thread may >>> re-grab the Threads_locks before it woke up from previous safepoint. >>> If the >>> GC/VM don't respect MMU (minimum mutator utilization) or if your >>> machine is very >>> over-provisioned this can happen. >>> The current schema thus re-safepoint quickly if the java threads >>> have not >>> started yet at the cost of latency. Since the new code uses the >>> WaitBarrier with >>> the safepoint counter, all threads must roll forward to next >>> safepoint by >>> getting at least some CPU time between two safepoints. Meaning MMU >>> violations >>> are more obvious. >>> >>> Some examples on numbers: >>> - On a 16 strand machine synchronization and >>> un-synchronization/starting is at >>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >>> ~100us and >>> ?? starting ~400->~100us. >>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >>> Linux). >>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>> ?? synchronization time on 16 strands and ~5% score increase. In >>> this case the GC >>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% >>> to 10%. >>> - specJBB2015 ParGC ~9% increase in critical-jops. >>> >>> Thanks, Robbin > From patricio.chilano.mateo at oracle.com Fri Feb 8 20:17:50 2019 From: patricio.chilano.mateo at oracle.com (Patricio Chilano) Date: Fri, 8 Feb 2019 15:17:50 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: <47fd4f59-ad08-add3-7b52-e9e6b93fe463@oracle.com> Hi Dan, On 2/8/19 3:01 PM, Daniel D. Daugherty wrote: > On 2/8/19 2:33 PM, Daniel D. Daugherty wrote: >> On 2/7/19 11:05 AM, Robbin Ehn wrote: >>> Hi all, here is the promised re-base (v06) on >>> 8210832: Remove sneaky locking in class Monitor. >>> >>> v06_1 is just a straight re-base. >>> >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >>> Inc: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >> >> Something is wrong with this incremental webrev. I was expecting an >> incremental webrev relative to the v05 version, but that's not >> what I see in src/hotspot/share/runtime/safepoint.cpp. In that file >> I'm seeing changes relative to the baseline, e.g., deletion of the >> Safepoint_lock, etc. > > So I dropped back to the full patch for v05 and tried to compare that > to the v06_1/full patch above using jfilemerge. That's not working for > me either. > > Next I'm going to just look at the v06_1/full webrev and see if that > makes sense. Incremental webrev for version v06_1 contains also the conflict resolutions after hg merge failed between 8210832 and this change. Yesterday I noticed that too with safepoint.hpp and asked Robbin. Hope that makes more sense. Patricio > Dan > > >> >> Dan >> >> >> >>> >>> Passes stress test and t1-5. >>> >>> But there is a 'better' way. >>> Before I added the more graceful "_vm_wait->wait();" semaphore in >>> the while >>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the >>> same >>> back-off as the rolling forward loop. It turns out that we mostly >>> never spin >>> here at all, when all java threads are stop the callbacks is often >>> already done. >>> So the addition of the semaphore have no impact on our benchmarks >>> and is mostly >>> unused. This is because most threads are in java which we need to >>> spin-wait >>> since they can elide into native without doing a callback. My >>> proposed re-base >>> removes the the callbacks completely and let the vm thread do all >>> thread >>> accounting. All that the stopping threads needs to do is write state >>> and >>> safepoint id, everything else is handle by the vm thread. We trade 2 >>> atomics + >>> a local store per thread against doing 2 stores per thread by the vm >>> thread. >>> This makes it possible for a thread in vm to transition into blocked >>> WITHOUT >>> safepoint poll. Just set thread_blocked and promise to do safepoint >>> poll when >>> leaving that state. >>> >>> v06_2 >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>> Inc against v05: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>> Inc against v06_1: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>> >>> v06_2 simplifies and removes ~200 LOC with same performance. >>> If there is a case with a thread in vm taking long time, it will >>> already >>> screw-up latency and thus should be fixed regardless of v06_1 vs >>> v06_2. So I >>> see no reason why we should not push v06_2. >>> >>> Passes stress test and t1-5. >>> >>> Thanks, Robbin >>> >>> >>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>> Hi all, please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>> >>>> Thanks to Dan for pre-reviewing a lot! >>>> >>>> Background: >>>> ZGC often does very short safepoint operations. For a perspective, >>>> in a >>>> specJBB2015 run, G1 can have young collection stops lasting about >>>> 170 ms. While >>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on >>>> which >>>> operation it is. The time it takes to stop and start the >>>> JavaThreads is relative >>>> very large to a ZGC safepoint. With an operation that just takes >>>> 0.2ms the >>>> overhead of stopping and starting JavaThreads is several times the >>>> operation. >>>> >>>> High-level functionality change: >>>> Serializing the starting over Threads_lock takes time. >>>> - Don't wait on Threads_lock use the WaitBarrier. >>>> Serializing the stopping over Safepoint_lock takes time. >>>> - Let threads stop in parallel, remove Safepoint_lock. >>>> >>>> Details: >>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>> - Safe means the JavaThread will not touch Java heap or VM internal >>>> structures >>>> ?? without doing a transition and block before doing so. >>>> ???????? - The safe states are: >>>> ???????????????? - When polls armed: _thread_in_native and >>>> _thread_blocked. >>>> ???????????????? - When Threads_lock is held: externally suspended >>>> flag is set. >>>> ???????? - VM Thread have polls armed and holds the Threads_lock >>>> during a >>>> ?????????? safepoint. >>>> - Unsafe means that either Java heap or VM internal structures can >>>> be accessed >>>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>> ???????? - All combination that are not safe are unsafe. >>>> >>>> We cannot start a safepoint until all unsafe threads have >>>> transitioned to a safe >>>> state. To make them safe, we arm polls in compiled code and make >>>> sure any >>>> transition to another unsafe state will be blocked. JavaThreads >>>> which are unsafe >>>> with state _thread_in_Java may transition to _thread_in_native >>>> without being >>>> blocked, since it just became a safe thread and we can proceed. Any >>>> safe thread >>>> may try to transition at any time to an unsafe state, thus coming >>>> into the >>>> safepoint blocking code at any moment, e.g., after the safepoint is >>>> over, or >>>> even at the beginning of next safepoint. >>>> >>>> The VMThread cannot tolerate false positives from the JavaThread >>>> thread state >>>> because that would mean starting the safepoint without all >>>> JavaThreads being >>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >>>> never observe >>>> false positives from the safepoint blocking code, if we remove >>>> them, how do we >>>> handle false positives? >>>> >>>> By first publishing which barrier tag (safepoint counter) we will call >>>> WaitBarrier.wait() with as the threads safepoint id and then change >>>> the state to >>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a >>>> stable load of >>>> the state. A stable load of the thread state is successful if the >>>> thread >>>> safepoint id is the same both before and after the load of the >>>> state and >>>> safepoint id is current or InactiveSafepointCounter. If the stable >>>> load fails, >>>> the thread is considered safepoint unsafe. It's no longer enough >>>> that thread is >>>> have state _thread_blocked it must also have correct safepoint id >>>> before and >>>> after we read the state. >>>> >>>> Performance: >>>> The result of faster safepoints is that the average CPU time for >>>> JavaThreads >>>> between safepoints is higher, thus increasing the allocation rate. >>>> The thread >>>> that stops first waits shorter time until it gets started. Even the >>>> thread that >>>> stops last also have shorter stop since we start them faster. If your >>>> application is using a concurrent GC it may need re-tunning since >>>> each java >>>> worker thread have an increased CPU time/allocation rate. Often >>>> this means max >>>> performance is achieved using slightly less java worker threads >>>> than before. >>>> Also the increase allocation rate means shorter time between GC >>>> safepoints. >>>> - If you are using a non-concurrent GC, you should see improved >>>> latency and >>>> ?? throughput. >>>> - After re-tunning with a concurrent GC throughput should be equal >>>> or better but >>>> ?? with better latency. But bear in mind this is a latency patch, >>>> not a >>>> ?? throughput one. >>>> With current code a java thread is not to guarantee to run between >>>> safepoint (in >>>> theory a java thread can be starved indefinitely), since the VM >>>> thread may >>>> re-grab the Threads_locks before it woke up from previous >>>> safepoint. If the >>>> GC/VM don't respect MMU (minimum mutator utilization) or if your >>>> machine is very >>>> over-provisioned this can happen. >>>> The current schema thus re-safepoint quickly if the java threads >>>> have not >>>> started yet at the cost of latency. Since the new code uses the >>>> WaitBarrier with >>>> the safepoint counter, all threads must roll forward to next >>>> safepoint by >>>> getting at least some CPU time between two safepoints. Meaning MMU >>>> violations >>>> are more obvious. >>>> >>>> Some examples on numbers: >>>> - On a 16 strand machine synchronization and >>>> un-synchronization/starting is at >>>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >>>> ~100us and >>>> ?? starting ~400->~100us. >>>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >>>> Linux). >>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>> ?? synchronization time on 16 strands and ~5% score increase. In >>>> this case the GC >>>> ?? op is 1ms, so we reduce the overhead of synchronization from >>>> 100% to 10%. >>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>> >>>> Thanks, Robbin >> > From daniel.daugherty at oracle.com Fri Feb 8 21:23:59 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Feb 2019 16:23:59 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: On 2/8/19 3:01 PM, Daniel D. Daugherty wrote: > On 2/8/19 2:33 PM, Daniel D. Daugherty wrote: >> On 2/7/19 11:05 AM, Robbin Ehn wrote: >>> Hi all, here is the promised re-base (v06) on >>> 8210832: Remove sneaky locking in class Monitor. >>> >>> v06_1 is just a straight re-base. >>> >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ src/hotspot/share/code/dependencyContext.hpp ??? No comments. src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp ??? No comments. src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp ??? No comments. src/hotspot/share/runtime/handshake.cpp ??? No comments. src/hotspot/share/runtime/mutex.cpp ??? No comments. src/hotspot/share/runtime/mutex.hpp ??? No comments. src/hotspot/share/runtime/mutexLocker.cpp ??? No comments. src/hotspot/share/runtime/mutexLocker.hpp ??? No comments. src/hotspot/share/runtime/safepoint.cpp ??? L846: ? assert(state ==? _thread_in_vm_trans, "bad"); ??????? nit - please delete extra space after '==' ??? old L880: ????? if (thread->safepoint_state()->type() == ThreadSafepointState::_call_back && ??? old L881: ????????? block_in_safepoint_check) { ??? new L944: ????? if (thread->safepoint_state()->type() == ThreadSafepointState::_call_back ??? new L945: ????????? && !block_in_safepoint_check) { ??????? Why did the seond expression get inverted? ??????? "block_in_safepoint_check" => "!block_in_safepoint_check" ??????? old L881 was not in v05 so it must have come from Patricio's ??????? recent changes here. Is this a merge error? src/hotspot/share/runtime/safepoint.hpp ??? No comments. src/hotspot/share/runtime/safepointMechanism.cpp ??? No comments. src/hotspot/share/runtime/safepointMechanism.inline.hpp ??? No comments. src/hotspot/share/runtime/thread.hpp ??? No comments. src/hotspot/share/runtime/vmThread.cpp ??? No comments. src/hotspot/share/services/runtimeService.cpp ??? No comments. src/hotspot/share/services/runtimeService.hpp ??? No comments. test/hotspot/jtreg/runtime/logging/SafepointTest.java ??? No comments. I double checked my previous recent reviews and I think everything is still resolved and in good shape. As usual for this project, safepoint.cpp is a nightmare to review, but I did try to sanity check with respect to all the code motion. Thumbs up. Dan >>> Inc: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >> >> Something is wrong with this incremental webrev. I was expecting an >> incremental webrev relative to the v05 version, but that's not >> what I see in src/hotspot/share/runtime/safepoint.cpp. In that file >> I'm seeing changes relative to the baseline, e.g., deletion of the >> Safepoint_lock, etc. > > So I dropped back to the full patch for v05 and tried to compare that > to the v06_1/full patch above using jfilemerge. That's not working for > me either. > > Next I'm going to just look at the v06_1/full webrev and see if that > makes sense. > > Dan > > >> >> Dan >> >> >> >>> >>> Passes stress test and t1-5. >>> >>> But there is a 'better' way. >>> Before I added the more graceful "_vm_wait->wait();" semaphore in >>> the while >>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the >>> same >>> back-off as the rolling forward loop. It turns out that we mostly >>> never spin >>> here at all, when all java threads are stop the callbacks is often >>> already done. >>> So the addition of the semaphore have no impact on our benchmarks >>> and is mostly >>> unused. This is because most threads are in java which we need to >>> spin-wait >>> since they can elide into native without doing a callback. My >>> proposed re-base >>> removes the the callbacks completely and let the vm thread do all >>> thread >>> accounting. All that the stopping threads needs to do is write state >>> and >>> safepoint id, everything else is handle by the vm thread. We trade 2 >>> atomics + >>> a local store per thread against doing 2 stores per thread by the vm >>> thread. >>> This makes it possible for a thread in vm to transition into blocked >>> WITHOUT >>> safepoint poll. Just set thread_blocked and promise to do safepoint >>> poll when >>> leaving that state. >>> >>> v06_2 >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>> Inc against v05: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>> Inc against v06_1: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>> >>> v06_2 simplifies and removes ~200 LOC with same performance. >>> If there is a case with a thread in vm taking long time, it will >>> already >>> screw-up latency and thus should be fixed regardless of v06_1 vs >>> v06_2. So I >>> see no reason why we should not push v06_2. >>> >>> Passes stress test and t1-5. >>> >>> Thanks, Robbin >>> >>> >>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>> Hi all, please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>> >>>> Thanks to Dan for pre-reviewing a lot! >>>> >>>> Background: >>>> ZGC often does very short safepoint operations. For a perspective, >>>> in a >>>> specJBB2015 run, G1 can have young collection stops lasting about >>>> 170 ms. While >>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on >>>> which >>>> operation it is. The time it takes to stop and start the >>>> JavaThreads is relative >>>> very large to a ZGC safepoint. With an operation that just takes >>>> 0.2ms the >>>> overhead of stopping and starting JavaThreads is several times the >>>> operation. >>>> >>>> High-level functionality change: >>>> Serializing the starting over Threads_lock takes time. >>>> - Don't wait on Threads_lock use the WaitBarrier. >>>> Serializing the stopping over Safepoint_lock takes time. >>>> - Let threads stop in parallel, remove Safepoint_lock. >>>> >>>> Details: >>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>> - Safe means the JavaThread will not touch Java heap or VM internal >>>> structures >>>> ?? without doing a transition and block before doing so. >>>> ???????? - The safe states are: >>>> ???????????????? - When polls armed: _thread_in_native and >>>> _thread_blocked. >>>> ???????????????? - When Threads_lock is held: externally suspended >>>> flag is set. >>>> ???????? - VM Thread have polls armed and holds the Threads_lock >>>> during a >>>> ?????????? safepoint. >>>> - Unsafe means that either Java heap or VM internal structures can >>>> be accessed >>>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>> ???????? - All combination that are not safe are unsafe. >>>> >>>> We cannot start a safepoint until all unsafe threads have >>>> transitioned to a safe >>>> state. To make them safe, we arm polls in compiled code and make >>>> sure any >>>> transition to another unsafe state will be blocked. JavaThreads >>>> which are unsafe >>>> with state _thread_in_Java may transition to _thread_in_native >>>> without being >>>> blocked, since it just became a safe thread and we can proceed. Any >>>> safe thread >>>> may try to transition at any time to an unsafe state, thus coming >>>> into the >>>> safepoint blocking code at any moment, e.g., after the safepoint is >>>> over, or >>>> even at the beginning of next safepoint. >>>> >>>> The VMThread cannot tolerate false positives from the JavaThread >>>> thread state >>>> because that would mean starting the safepoint without all >>>> JavaThreads being >>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >>>> never observe >>>> false positives from the safepoint blocking code, if we remove >>>> them, how do we >>>> handle false positives? >>>> >>>> By first publishing which barrier tag (safepoint counter) we will call >>>> WaitBarrier.wait() with as the threads safepoint id and then change >>>> the state to >>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a >>>> stable load of >>>> the state. A stable load of the thread state is successful if the >>>> thread >>>> safepoint id is the same both before and after the load of the >>>> state and >>>> safepoint id is current or InactiveSafepointCounter. If the stable >>>> load fails, >>>> the thread is considered safepoint unsafe. It's no longer enough >>>> that thread is >>>> have state _thread_blocked it must also have correct safepoint id >>>> before and >>>> after we read the state. >>>> >>>> Performance: >>>> The result of faster safepoints is that the average CPU time for >>>> JavaThreads >>>> between safepoints is higher, thus increasing the allocation rate. >>>> The thread >>>> that stops first waits shorter time until it gets started. Even the >>>> thread that >>>> stops last also have shorter stop since we start them faster. If your >>>> application is using a concurrent GC it may need re-tunning since >>>> each java >>>> worker thread have an increased CPU time/allocation rate. Often >>>> this means max >>>> performance is achieved using slightly less java worker threads >>>> than before. >>>> Also the increase allocation rate means shorter time between GC >>>> safepoints. >>>> - If you are using a non-concurrent GC, you should see improved >>>> latency and >>>> ?? throughput. >>>> - After re-tunning with a concurrent GC throughput should be equal >>>> or better but >>>> ?? with better latency. But bear in mind this is a latency patch, >>>> not a >>>> ?? throughput one. >>>> With current code a java thread is not to guarantee to run between >>>> safepoint (in >>>> theory a java thread can be starved indefinitely), since the VM >>>> thread may >>>> re-grab the Threads_locks before it woke up from previous >>>> safepoint. If the >>>> GC/VM don't respect MMU (minimum mutator utilization) or if your >>>> machine is very >>>> over-provisioned this can happen. >>>> The current schema thus re-safepoint quickly if the java threads >>>> have not >>>> started yet at the cost of latency. Since the new code uses the >>>> WaitBarrier with >>>> the safepoint counter, all threads must roll forward to next >>>> safepoint by >>>> getting at least some CPU time between two safepoints. Meaning MMU >>>> violations >>>> are more obvious. >>>> >>>> Some examples on numbers: >>>> - On a 16 strand machine synchronization and >>>> un-synchronization/starting is at >>>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >>>> ~100us and >>>> ?? starting ~400->~100us. >>>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >>>> Linux). >>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>> ?? synchronization time on 16 strands and ~5% score increase. In >>>> this case the GC >>>> ?? op is 1ms, so we reduce the overhead of synchronization from >>>> 100% to 10%. >>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>> >>>> Thanks, Robbin >> > From daniel.daugherty at oracle.com Fri Feb 8 21:27:50 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Feb 2019 16:27:50 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: <47fd4f59-ad08-add3-7b52-e9e6b93fe463@oracle.com> References: <47fd4f59-ad08-add3-7b52-e9e6b93fe463@oracle.com> Message-ID: On 2/8/19 3:17 PM, Patricio Chilano wrote: > Hi Dan, > > On 2/8/19 3:01 PM, Daniel D. Daugherty wrote: >> On 2/8/19 2:33 PM, Daniel D. Daugherty wrote: >>> On 2/7/19 11:05 AM, Robbin Ehn wrote: >>>> Hi all, here is the promised re-base (v06) on >>>> 8210832: Remove sneaky locking in class Monitor. >>>> >>>> v06_1 is just a straight re-base. >>>> >>>> Full: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >>>> Inc: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >>> >>> Something is wrong with this incremental webrev. I was expecting an >>> incremental webrev relative to the v05 version, but that's not >>> what I see in src/hotspot/share/runtime/safepoint.cpp. In that file >>> I'm seeing changes relative to the baseline, e.g., deletion of the >>> Safepoint_lock, etc. >> >> So I dropped back to the full patch for v05 and tried to compare that >> to the v06_1/full patch above using jfilemerge. That's not working for >> me either. >> >> Next I'm going to just look at the v06_1/full webrev and see if that >> makes sense. > Incremental webrev for version v06_1 contains also the conflict > resolutions after hg merge failed between 8210832 and this change. > Yesterday I noticed that too with safepoint.hpp and asked Robbin. Hope > that makes more sense. I read that yesterday I think... It makes more sense, but I still found it too difficult/jarring to review the 'inc' webrev... Dan > > > Patricio >> Dan >> >> >>> >>> Dan >>> >>> >>> >>>> >>>> Passes stress test and t1-5. >>>> >>>> But there is a 'better' way. >>>> Before I added the more graceful "_vm_wait->wait();" semaphore in >>>> the while >>>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the >>>> same >>>> back-off as the rolling forward loop. It turns out that we mostly >>>> never spin >>>> here at all, when all java threads are stop the callbacks is often >>>> already done. >>>> So the addition of the semaphore have no impact on our benchmarks >>>> and is mostly >>>> unused. This is because most threads are in java which we need to >>>> spin-wait >>>> since they can elide into native without doing a callback. My >>>> proposed re-base >>>> removes the the callbacks completely and let the vm thread do all >>>> thread >>>> accounting. All that the stopping threads needs to do is write >>>> state and >>>> safepoint id, everything else is handle by the vm thread. We trade >>>> 2 atomics + >>>> a local store per thread against doing 2 stores per thread by the >>>> vm thread. >>>> This makes it possible for a thread in vm to transition into >>>> blocked WITHOUT >>>> safepoint poll. Just set thread_blocked and promise to do safepoint >>>> poll when >>>> leaving that state. >>>> >>>> v06_2 >>>> Full: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>>> Inc against v05: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>>> Inc against v06_1: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>>> >>>> v06_2 simplifies and removes ~200 LOC with same performance. >>>> If there is a case with a thread in vm taking long time, it will >>>> already >>>> screw-up latency and thus should be fixed regardless of v06_1 vs >>>> v06_2. So I >>>> see no reason why we should not push v06_2. >>>> >>>> Passes stress test and t1-5. >>>> >>>> Thanks, Robbin >>>> >>>> >>>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>>> Hi all, please review. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>>> >>>>> Thanks to Dan for pre-reviewing a lot! >>>>> >>>>> Background: >>>>> ZGC often does very short safepoint operations. For a perspective, >>>>> in a >>>>> specJBB2015 run, G1 can have young collection stops lasting about >>>>> 170 ms. While >>>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on >>>>> which >>>>> operation it is. The time it takes to stop and start the >>>>> JavaThreads is relative >>>>> very large to a ZGC safepoint. With an operation that just takes >>>>> 0.2ms the >>>>> overhead of stopping and starting JavaThreads is several times the >>>>> operation. >>>>> >>>>> High-level functionality change: >>>>> Serializing the starting over Threads_lock takes time. >>>>> - Don't wait on Threads_lock use the WaitBarrier. >>>>> Serializing the stopping over Safepoint_lock takes time. >>>>> - Let threads stop in parallel, remove Safepoint_lock. >>>>> >>>>> Details: >>>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>>> - Safe means the JavaThread will not touch Java heap or VM >>>>> internal structures >>>>> ?? without doing a transition and block before doing so. >>>>> ???????? - The safe states are: >>>>> ???????????????? - When polls armed: _thread_in_native and >>>>> _thread_blocked. >>>>> ???????????????? - When Threads_lock is held: externally suspended >>>>> flag is set. >>>>> ???????? - VM Thread have polls armed and holds the Threads_lock >>>>> during a >>>>> ?????????? safepoint. >>>>> - Unsafe means that either Java heap or VM internal structures can >>>>> be accessed >>>>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>>> ???????? - All combination that are not safe are unsafe. >>>>> >>>>> We cannot start a safepoint until all unsafe threads have >>>>> transitioned to a safe >>>>> state. To make them safe, we arm polls in compiled code and make >>>>> sure any >>>>> transition to another unsafe state will be blocked. JavaThreads >>>>> which are unsafe >>>>> with state _thread_in_Java may transition to _thread_in_native >>>>> without being >>>>> blocked, since it just became a safe thread and we can proceed. >>>>> Any safe thread >>>>> may try to transition at any time to an unsafe state, thus coming >>>>> into the >>>>> safepoint blocking code at any moment, e.g., after the safepoint >>>>> is over, or >>>>> even at the beginning of next safepoint. >>>>> >>>>> The VMThread cannot tolerate false positives from the JavaThread >>>>> thread state >>>>> because that would mean starting the safepoint without all >>>>> JavaThreads being >>>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >>>>> never observe >>>>> false positives from the safepoint blocking code, if we remove >>>>> them, how do we >>>>> handle false positives? >>>>> >>>>> By first publishing which barrier tag (safepoint counter) we will >>>>> call >>>>> WaitBarrier.wait() with as the threads safepoint id and then >>>>> change the state to >>>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a >>>>> stable load of >>>>> the state. A stable load of the thread state is successful if the >>>>> thread >>>>> safepoint id is the same both before and after the load of the >>>>> state and >>>>> safepoint id is current or InactiveSafepointCounter. If the stable >>>>> load fails, >>>>> the thread is considered safepoint unsafe. It's no longer enough >>>>> that thread is >>>>> have state _thread_blocked it must also have correct safepoint id >>>>> before and >>>>> after we read the state. >>>>> >>>>> Performance: >>>>> The result of faster safepoints is that the average CPU time for >>>>> JavaThreads >>>>> between safepoints is higher, thus increasing the allocation rate. >>>>> The thread >>>>> that stops first waits shorter time until it gets started. Even >>>>> the thread that >>>>> stops last also have shorter stop since we start them faster. If your >>>>> application is using a concurrent GC it may need re-tunning since >>>>> each java >>>>> worker thread have an increased CPU time/allocation rate. Often >>>>> this means max >>>>> performance is achieved using slightly less java worker threads >>>>> than before. >>>>> Also the increase allocation rate means shorter time between GC >>>>> safepoints. >>>>> - If you are using a non-concurrent GC, you should see improved >>>>> latency and >>>>> ?? throughput. >>>>> - After re-tunning with a concurrent GC throughput should be equal >>>>> or better but >>>>> ?? with better latency. But bear in mind this is a latency patch, >>>>> not a >>>>> ?? throughput one. >>>>> With current code a java thread is not to guarantee to run between >>>>> safepoint (in >>>>> theory a java thread can be starved indefinitely), since the VM >>>>> thread may >>>>> re-grab the Threads_locks before it woke up from previous >>>>> safepoint. If the >>>>> GC/VM don't respect MMU (minimum mutator utilization) or if your >>>>> machine is very >>>>> over-provisioned this can happen. >>>>> The current schema thus re-safepoint quickly if the java threads >>>>> have not >>>>> started yet at the cost of latency. Since the new code uses the >>>>> WaitBarrier with >>>>> the safepoint counter, all threads must roll forward to next >>>>> safepoint by >>>>> getting at least some CPU time between two safepoints. Meaning MMU >>>>> violations >>>>> are more obvious. >>>>> >>>>> Some examples on numbers: >>>>> - On a 16 strand machine synchronization and >>>>> un-synchronization/starting is at >>>>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >>>>> ~100us and >>>>> ?? starting ~400->~100us. >>>>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier >>>>> on Linux). >>>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>>> ?? synchronization time on 16 strands and ~5% score increase. In >>>>> this case the GC >>>>> ?? op is 1ms, so we reduce the overhead of synchronization from >>>>> 100% to 10%. >>>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>>> >>>>> Thanks, Robbin >>> >> > From daniel.daugherty at oracle.com Fri Feb 8 22:37:17 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Feb 2019 17:37:17 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: Robbin, Because this is a completely different way of solving this problem, I don't think I can review this incrementally. That means another crawl through review and might even mean another round of whiteboard diagrams... A proper review will obviously take me longer than I planned, but I wanted you know that I'm starting to look at it from the beginning... :-) Dan On 2/7/19 11:05 AM, Robbin Ehn wrote: > But there is a 'better' way. > Before I added the more graceful "_vm_wait->wait();" semaphore in the > while > (_waiting_to_block > 0) { loop, it was a just a busy spin using the same > back-off as the rolling forward loop. It turns out that we mostly > never spin > here at all, when all java threads are stop the callbacks is often > already done. > So the addition of the semaphore have no impact on our benchmarks and > is mostly > unused. This is because most threads are in java which we need to > spin-wait > since they can elide into native without doing a callback. My proposed > re-base > removes the the callbacks completely and let the vm thread do all thread > accounting. All that the stopping threads needs to do is write state and > safepoint id, everything else is handle by the vm thread. We trade 2 > atomics + > a local store per thread against doing 2 stores per thread by the vm > thread. > This makes it possible for a thread in vm to transition into blocked > WITHOUT > safepoint poll. Just set thread_blocked and promise to do safepoint > poll when > leaving that state. > > v06_2 > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ > Inc against v05: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ > Inc against v06_1: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ > > v06_2 simplifies and removes ~200 LOC with same performance. > If there is a case with a thread in vm taking long time, it will already > screw-up latency and thus should be fixed regardless of v06_1 vs > v06_2. So I > see no reason why we should not push v06_2. > > Passes stress test and t1-5. > > Thanks, Robbin From karen.kinnear at oracle.com Fri Feb 8 22:52:10 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 8 Feb 2019 17:52:10 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: <78AEA4C5-1D68-465B-94F6-3AFE01B77029@oracle.com> I am doing the same - so not done reviewing yet ... Thought I would send a few minor comments - this is on the v06_02 (in case you are looking at line numbers) - because I would very much like this to be the way going forward if it passes reviews. 1. safepoint.cpp I thought with the JFR change you could remove the try_stable_load_state with InactiveSafepointCounter? When would you be in this code and not with a valid safepoint_count? 2. _waiting_to_block and _current_jni_active_count are no longer volatile - assumed only read/modified by VMThread - could you add assertions in the accessors that this is the VMThread? 3. safepoint.cpp line 413: "Keep event from now." -> what does this comment mean? line 815: "safepoint callback" -> can you update the comment since we removed the "callback" mechanism - I do realize that we still have the block_if_requested. 4. Do you have stress tests with high thread counts? Does the updated mechanism for _thread_in_vm work as well there? They all complete and no latency issues? 5. Do you test with ThreadLocalHandshakes off and on? Future Cleanup Wishlist: 1. TBIVM: - clean up code that is trying to do an explicit safepoint_poll, at that point the TBIVM could also skip the safepoint check in the constructor ? 2. when do we check safepoint_safe_with and native is not walkable (or !has_last_Java_frame ?) why is this not an assertion? When do we transition to native without make_walkable? 3. ThreadInVMfromUnknown - what if not in _thread_in_native? Then we don't transition to _thread_in_vm and we are not in the state we think we are - when does this happen and what state are we left in? > On Feb 8, 2019, at 5:37 PM, Daniel D. Daugherty wrote: > > Robbin, > > Because this is a completely different way of solving this problem, I don't > think I can review this incrementally. That means another crawl through > review and might even mean another round of whiteboard diagrams... > > A proper review will obviously take me longer than I planned, but I wanted > you know that I'm starting to look at it from the beginning... :-) > > Dan > > > On 2/7/19 11:05 AM, Robbin Ehn wrote: >> But there is a 'better' way. >> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >> back-off as the rolling forward loop. It turns out that we mostly never spin >> here at all, when all java threads are stop the callbacks is often already done. >> So the addition of the semaphore have no impact on our benchmarks and is mostly >> unused. This is because most threads are in java which we need to spin-wait >> since they can elide into native without doing a callback. My proposed re-base >> removes the the callbacks completely and let the vm thread do all thread >> accounting. All that the stopping threads needs to do is write state and >> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >> a local store per thread against doing 2 stores per thread by the vm thread. >> This makes it possible for a thread in vm to transition into blocked WITHOUT >> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >> leaving that state. >> >> v06_2 >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >> Inc against v05: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >> Inc against v06_1: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >> >> v06_2 simplifies and removes ~200 LOC with same performance. >> If there is a case with a thread in vm taking long time, it will already >> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >> see no reason why we should not push v06_2. >> >> Passes stress test and t1-5. >> >> Thanks, Robbin > From david.holmes at oracle.com Fri Feb 8 23:35:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Feb 2019 09:35:35 +1000 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: On 8/02/2019 2:05 am, Robbin Ehn wrote: > Hi all, here is the promised re-base (v06) on > 8210832: Remove sneaky locking in class Monitor. > > v06_1 is just a straight re-base. > > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ > Inc: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ > > Passes stress test and t1-5. > > But there is a 'better' way. That raises a red flag for me straight away. I'm always very suspicious of "better ways" that suddenly appear after many weeks of testing and examination of the previously proposed way. As Dan has said this is no longer an incremental webrev review, but needs much deeper analysis again. David ----- > Before I added the more graceful "_vm_wait->wait();" semaphore in the while > (_waiting_to_block > 0) { loop, it was a just a busy spin using the same > back-off as the rolling forward loop. It turns out that we mostly never > spin > here at all, when all java threads are stop the callbacks is often > already done. > So the addition of the semaphore have no impact on our benchmarks and is > mostly > unused. This is because most threads are in java which we need to spin-wait > since they can elide into native without doing a callback. My proposed > re-base > removes the the callbacks completely and let the vm thread do all thread > accounting. All that the stopping threads needs to do is write state and > safepoint id, everything else is handle by the vm thread. We trade 2 > atomics + > a local store per thread against doing 2 stores per thread by the vm > thread. > This makes it possible for a thread in vm to transition into blocked > WITHOUT > safepoint poll. Just set thread_blocked and promise to do safepoint poll > when > leaving that state. > > v06_2 > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ > Inc against v05: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ > Inc against v06_1: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ > > v06_2 simplifies and removes ~200 LOC with same performance. > If there is a case with a thread in vm taking long time, it will already > screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. > So I > see no reason why we should not push v06_2. > > Passes stress test and t1-5. > > Thanks, Robbin > > > On 1/15/19 11:39 AM, Robbin Ehn wrote: >> Hi all, please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >> >> Thanks to Dan for pre-reviewing a lot! >> >> Background: >> ZGC often does very short safepoint operations. For a perspective, in a >> specJBB2015 run, G1 can have young collection stops lasting about 170 >> ms. While >> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >> operation it is. The time it takes to stop and start the JavaThreads >> is relative >> very large to a ZGC safepoint. With an operation that just takes 0.2ms >> the >> overhead of stopping and starting JavaThreads is several times the >> operation. >> >> High-level functionality change: >> Serializing the starting over Threads_lock takes time. >> - Don't wait on Threads_lock use the WaitBarrier. >> Serializing the stopping over Safepoint_lock takes time. >> - Let threads stop in parallel, remove Safepoint_lock. >> >> Details: >> JavaThreads have 2 abstract logical states: unsafe or safe. >> - Safe means the JavaThread will not touch Java heap or VM internal >> structures >> ?? without doing a transition and block before doing so. >> ???????? - The safe states are: >> ???????????????? - When polls armed: _thread_in_native and >> _thread_blocked. >> ???????????????? - When Threads_lock is held: externally suspended >> flag is set. >> ???????? - VM Thread have polls armed and holds the Threads_lock during a >> ?????????? safepoint. >> - Unsafe means that either Java heap or VM internal structures can be >> accessed >> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >> ???????? - All combination that are not safe are unsafe. >> >> We cannot start a safepoint until all unsafe threads have transitioned >> to a safe >> state. To make them safe, we arm polls in compiled code and make sure any >> transition to another unsafe state will be blocked. JavaThreads which >> are unsafe >> with state _thread_in_Java may transition to _thread_in_native without >> being >> blocked, since it just became a safe thread and we can proceed. Any >> safe thread >> may try to transition at any time to an unsafe state, thus coming into >> the >> safepoint blocking code at any moment, e.g., after the safepoint is >> over, or >> even at the beginning of next safepoint. >> >> The VMThread cannot tolerate false positives from the JavaThread >> thread state >> because that would mean starting the safepoint without all JavaThreads >> being >> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >> never observe >> false positives from the safepoint blocking code, if we remove them, >> how do we >> handle false positives? >> >> By first publishing which barrier tag (safepoint counter) we will call >> WaitBarrier.wait() with as the threads safepoint id and then change >> the state to >> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable >> load of >> the state. A stable load of the thread state is successful if the thread >> safepoint id is the same both before and after the load of the state and >> safepoint id is current or InactiveSafepointCounter. If the stable >> load fails, >> the thread is considered safepoint unsafe. It's no longer enough that >> thread is >> have state _thread_blocked it must also have correct safepoint id >> before and >> after we read the state. >> >> Performance: >> The result of faster safepoints is that the average CPU time for >> JavaThreads >> between safepoints is higher, thus increasing the allocation rate. The >> thread >> that stops first waits shorter time until it gets started. Even the >> thread that >> stops last also have shorter stop since we start them faster. If your >> application is using a concurrent GC it may need re-tunning since each >> java >> worker thread have an increased CPU time/allocation rate. Often this >> means max >> performance is achieved using slightly less java worker threads than >> before. >> Also the increase allocation rate means shorter time between GC >> safepoints. >> - If you are using a non-concurrent GC, you should see improved >> latency and >> ?? throughput. >> - After re-tunning with a concurrent GC throughput should be equal or >> better but >> ?? with better latency. But bear in mind this is a latency patch, not a >> ?? throughput one. >> With current code a java thread is not to guarantee to run between >> safepoint (in >> theory a java thread can be starved indefinitely), since the VM thread >> may >> re-grab the Threads_locks before it woke up from previous safepoint. >> If the >> GC/VM don't respect MMU (minimum mutator utilization) or if your >> machine is very >> over-provisioned this can happen. >> The current schema thus re-safepoint quickly if the java threads have not >> started yet at the cost of latency. Since the new code uses the >> WaitBarrier with >> the safepoint counter, all threads must roll forward to next safepoint by >> getting at least some CPU time between two safepoints. Meaning MMU >> violations >> are more obvious. >> >> Some examples on numbers: >> - On a 16 strand machine synchronization and >> un-synchronization/starting is at >> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >> ~100us and >> ?? starting ~400->~100us. >> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >> Linux). >> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >> ?? synchronization time on 16 strands and ~5% score increase. In this >> case the GC >> ?? op is 1ms, so we reduce the overhead of synchronization from 100% >> to 10%. >> - specJBB2015 ParGC ~9% increase in critical-jops. >> >> Thanks, Robbin From daniel.daugherty at oracle.com Sat Feb 9 02:42:04 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Feb 2019 21:42:04 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: On 2/7/19 11:05 AM, Robbin Ehn wrote: > But there is a 'better' way. > Before I added the more graceful "_vm_wait->wait();" semaphore in the > while > (_waiting_to_block > 0) { loop, it was a just a busy spin using the same > back-off as the rolling forward loop. It turns out that we mostly > never spin > here at all, when all java threads are stop the callbacks is often > already done. > So the addition of the semaphore have no impact on our benchmarks and > is mostly > unused. This is because most threads are in java which we need to > spin-wait > since they can elide into native without doing a callback. My proposed > re-base > removes the the callbacks completely and let the vm thread do all thread > accounting. All that the stopping threads needs to do is write state and > safepoint id, everything else is handle by the vm thread. We trade 2 > atomics + > a local store per thread against doing 2 stores per thread by the vm > thread. > This makes it possible for a thread in vm to transition into blocked > WITHOUT > safepoint poll. Just set thread_blocked and promise to do safepoint > poll when > leaving that state. > > v06_2 > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ This webrev's patch file is again a couple of patches together which makes searches of the patch for patterns problematic. I still managed to find an errant use of _call_back in a comment, but it wasn't easy. > Inc against v05: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ > Inc against v06_1: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ > > v06_2 simplifies and removes ~200 LOC with same performance. > If there is a case with a thread in vm taking long time, it will already > screw-up latency and thus should be fixed regardless of v06_1 vs > v06_2. So I > see no reason why we should not push v06_2. > > Passes stress test and t1-5. > > Thanks, Robbin src/hotspot/share/code/dependencyContext.hpp ??? No comments. src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp ??? No comments. src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp ??? No comments. src/hotspot/share/runtime/handshake.cpp ??? No comments. src/hotspot/share/runtime/interfaceSupport.inline.hpp ??? L317: thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); ??? L318: InterfaceSupport::serialize_thread_state_with_handler(thread); ??? L319: ??? old L320: SafepointMechanism::callback_if_safepoint(thread); ??? L320: ??? thread->set_thread_state(_thread_blocked); ??????? I'm having trouble with dropping callback_if_safepoint() here, ??????? but I can't put my finger on it yet. We're taking out these ??????? lines of code: ??????? L66: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { ??????? L73: ??? if (global_poll()) { ??????? L74: ????? SafepointSynchronize::block(thread, false); ??????? which my brain first read as taking out blocking for a safepoint, ??????? but then I remembered the 'false' parameter means we don't actually ??????? block for the safepoint. Okay, I'm glad that parameter is now gone ??????? from block(). So now it's much clearer that we are not blocking for ??????? a safepoint in the ThreadBlockInVMWithDeadlockCheck ctr. This is ??????? new behavior with Patricio's remove sneaky locking code and is not ??????? new with faster safepoints. src/hotspot/share/runtime/mutex.cpp ??? No comments. src/hotspot/share/runtime/mutex.hpp ??? No comments. src/hotspot/share/runtime/mutexLocker.cpp ??? No comments. src/hotspot/share/runtime/mutexLocker.hpp ??? No comments. src/hotspot/share/runtime/safepointMechanism.cpp ??? No comments. src/hotspot/share/runtime/safepointMechanism.hpp ??? No comments. src/hotspot/share/runtime/safepointMechanism.inline.hpp ??? No comments. src/hotspot/share/runtime/thread.hpp ??? No comments. src/hotspot/share/runtime/vmThread.cpp ??? No comments. src/hotspot/share/services/runtimeService.cpp ??? No comments. src/hotspot/share/services/runtimeService.hpp ??? No comments. test/hotspot/jtreg/runtime/logging/SafepointTest.java ??? No comments. src/hotspot/share/runtime/safepoint.hpp ??? L115: ? // Back off strategy when synchronizing a safepoint: ??? L116: ? static void back_off(); ??????? This function doesn't exist. src/hotspot/share/runtime/safepoint.cpp ??? Is this the code you intended to put in a back_off() function? ??? L273: ??? if (still_running > 0) { ??? L274: ????? // iterations will be 2 the first time we enter this spin back-off. ??? L275: ????? // naked_short_nanosleep takes tenths of micros which means that ??? L276: ????? // number of nanoseconds is irrelevant if it's below that. We do ??? L277: ????? // 20 1 ns sleeps with a total cost of ~1 ms, then we do 1 ms sleeps. ??? L278: ????? jlong sleep_ns = 1; ??? L279: ????? if (iterations > 21) { ??? L280: ??????? sleep_ns = NANOUNITS / MILLIUNITS;? // 1 ms ??? L281: ????? } ??? L282: ????? os::naked_short_nanosleep(sleep_ns); ??? L283: ??? } ??? Refactoring it in back_off() would clean things up a bit. ??? L1082: ? // Check state.? block() will set thread state to thread_in_vm which will ??? L1083: ? // cause the safepoint state _type to become _call_back. ??? L1084: ? assert(!SafepointMechanism::uses_global_page_poll() || !_safepoint_safe, ??? L1085: ???????? "polling page exception on thread safepoint safe"); ??????? This comment is now stale, but I'm not sure how it should be ??????? rewritten. The original comment doesn't really match the ??????? original assert() so I wonder if it went stale before this ??????? fix... Perhaps the comment should be: ???????????? // If we're using a global poll, then the thread should not be ???????????? // marked as safepoint safe yet. ??? There are pluses and minuses to the JavaThreads no longer calling back: ??? pluses: ????? - It was a bit confusing when a JavaThread could call back for itself ??????? or the VMThread could call back for a JavaThread in other cases. ????? - Now, only the VMThread handles setting _safepoint_safe which is the ??????? replacement for call back. So you want some asserts in there? ??? minuses: ????? - It feels like we've lost some debugging state with the removal of ??????? call back, but maybe that's not right. I guess we couldn't distinguish ??????? _who_ called back before (JavaThread for self or VMThread). I'm not entirely convinced that we have all of our bases covered for a thread blocking at a safepoint, but we have that worry with Patricio's removal of sneaky locking and we're going to shake that out with some targeted stress testing. Robbin, you mentioned stress test above. What kind of stress testing did you run and for how long? I think I'm good with where v06_2 is going. Of course, I'll mull on it over the weekend and I may have more comments next week. Dan From ioi.lam at oracle.com Sat Feb 9 08:42:09 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Sat, 9 Feb 2019 00:42:09 -0800 Subject: C++ delete operator undefined behavior Message-ID: <4d342877-b963-c9d0-a1d9-839e97ffd44e@oracle.com> I am getting a "ud2" instruction on the Mac for a 'delete' expression. According to this page, it's clang flagging an undefined behavior: https://stackoverflow.com/questions/21529308/why-does-clang-generate-ud2-opcode-on-osx My code looks like this: class MetaspaceClosure { ? class Ref : public ResourceObj { ? ... ? }; ? void push_impl(Ref* ref) { ??? if (_nest_level < MAX_NEST_LEVEL) { ????? do_push(ref); ????? delete ref; ??? } else { ????? ref->set_next(_pending_refs); ????? _pending_refs = ref; ??? } ? } }; and clang generates this code libjvm.dylib`MetaspaceClosure::push_impl: ??? 0x10316db9c <+0>:? pushq? %rbp ??? 0x10316db9d <+1>:? movq?? %rsp, %rbp ??? 0x10316dba0 <+4>:? pushq? %rbx ??? 0x10316dba1 <+5>:? pushq? %rax ??? 0x10316dba2 <+6>:? movq?? %rsi, %rbx ??? 0x10316dba5 <+9>:? cmpl?? $0x4, 0x10(%rdi) ??? 0x10316dba9 <+13>: jg???? 0x10316dbba ??? 0x10316dbab <+15>: movq?? %rbx, %rsi ??? 0x10316dbae <+18>: callq? 0x10316dbce? ; do_push() ??? 0x10316dbb3 <+23>: testq? %rbx, %rbx ??? 0x10316dbb6 <+26>: je???? 0x10316dbc6 ->? 0x10316dbb8 <+28>: ud2 <<<<<<<<<<<<<<<<<<<<<<< HERE ??? 0x10316dbba <+30>: movq?? 0x8(%rdi), %rax ??? 0x10316dbbe <+34>: movq?? %rax, 0x20(%rbx) ??? 0x10316dbc2 <+38>: movq?? %rbx, 0x8(%rdi) ??? 0x10316dbc6 <+42>: addq?? $0x8, %rsp ??? 0x10316dbca <+46>: popq?? %rbx ??? 0x10316dbcb <+47>: popq?? %rbp ??? 0x10316dbcc <+48>: retq ??? 0x10316dbcd <+49>: nop Shouldn't the 'delete' expression be translated to ResourceObj::operator delete()? And I couldn't find any warning messages given by clang .... I rewrote the Ref class to inherit from CHeapObj instead, and it magically worked. However, but there's other use of 'delete' on ResourceObj (such as ResourceHashtable) that seems to work just fine. Am I missing something? Thanks - Ioi From david.holmes at oracle.com Sat Feb 9 12:36:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Feb 2019 22:36:12 +1000 Subject: C++ delete operator undefined behavior In-Reply-To: <4d342877-b963-c9d0-a1d9-839e97ffd44e@oracle.com> References: <4d342877-b963-c9d0-a1d9-839e97ffd44e@oracle.com> Message-ID: <255f582b-e41c-3569-8417-4b66c6a916c3@oracle.com> Hi Ioi, On 9/02/2019 6:42 pm, Ioi Lam wrote: > I am getting a "ud2" instruction on the Mac for a 'delete' expression. > According to this page, it's clang flagging an undefined behavior: > > https://stackoverflow.com/questions/21529308/why-does-clang-generate-ud2-opcode-on-osx > > > My code looks like this: > > class MetaspaceClosure { > ? class Ref : public ResourceObj { > ? ... > ? }; > > > ? void push_impl(Ref* ref) { > ??? if (_nest_level < MAX_NEST_LEVEL) { > ????? do_push(ref); > ????? delete ref; > ??? } else { > ????? ref->set_next(_pending_refs); > ????? _pending_refs = ref; > ??? } > ? } > }; > > and clang generates this code > > libjvm.dylib`MetaspaceClosure::push_impl: > ??? 0x10316db9c <+0>:? pushq? %rbp > ??? 0x10316db9d <+1>:? movq?? %rsp, %rbp > ??? 0x10316dba0 <+4>:? pushq? %rbx > ??? 0x10316dba1 <+5>:? pushq? %rax > ??? 0x10316dba2 <+6>:? movq?? %rsi, %rbx > ??? 0x10316dba5 <+9>:? cmpl?? $0x4, 0x10(%rdi) > ??? 0x10316dba9 <+13>: jg???? 0x10316dbba > ??? 0x10316dbab <+15>: movq?? %rbx, %rsi > ??? 0x10316dbae <+18>: callq? 0x10316dbce? ; do_push() > ??? 0x10316dbb3 <+23>: testq? %rbx, %rbx > ??? 0x10316dbb6 <+26>: je???? 0x10316dbc6 > ->? 0x10316dbb8 <+28>: ud2 <<<<<<<<<<<<<<<<<<<<<<< HERE > ??? 0x10316dbba <+30>: movq?? 0x8(%rdi), %rax > ??? 0x10316dbbe <+34>: movq?? %rax, 0x20(%rbx) > ??? 0x10316dbc2 <+38>: movq?? %rbx, 0x8(%rdi) > ??? 0x10316dbc6 <+42>: addq?? $0x8, %rsp > ??? 0x10316dbca <+46>: popq?? %rbx > ??? 0x10316dbcb <+47>: popq?? %rbp > ??? 0x10316dbcc <+48>: retq > ??? 0x10316dbcd <+49>: nop > > Shouldn't the 'delete' expression be translated to ResourceObj::operator > delete()? Are Ref's allocated on the C_heap? That's the only kind of resourceObj you can delete: void ResourceObj::operator delete(void* p) { assert(((ResourceObj *)p)->allocated_on_C_heap(), "delete only allowed for C_HEAP objects"); DEBUG_ONLY(((ResourceObj *)p)->_allocation_t[0] = (uintptr_t)badHeapOopVal;) FreeHeap(p); } David ----- > And I couldn't find any warning messages given by clang .... > > I rewrote the Ref class to inherit from CHeapObj instead, > and it magically worked. > > However, but there's other use of 'delete' on ResourceObj (such as > ResourceHashtable) that seems to work just fine. Am I missing something? > > Thanks > > - Ioi > > > From ioi.lam at oracle.com Sat Feb 9 14:24:37 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Sat, 9 Feb 2019 06:24:37 -0800 Subject: C++ delete operator undefined behavior In-Reply-To: <255f582b-e41c-3569-8417-4b66c6a916c3@oracle.com> References: <4d342877-b963-c9d0-a1d9-839e97ffd44e@oracle.com> <255f582b-e41c-3569-8417-4b66c6a916c3@oracle.com> Message-ID: <684a22f3-5d25-8b93-1866-66b00c793573@oracle.com> On 2/9/19 4:36 AM, David Holmes wrote: > Hi Ioi, > > On 9/02/2019 6:42 pm, Ioi Lam wrote: >> I am getting a "ud2" instruction on the Mac for a 'delete' >> expression. According to this page, it's clang flagging an undefined >> behavior: >> >> https://stackoverflow.com/questions/21529308/why-does-clang-generate-ud2-opcode-on-osx >> >> >> My code looks like this: >> >> class MetaspaceClosure { >> ?? class Ref : public ResourceObj { >> ?? ... >> ?? }; >> >> >> ?? void push_impl(Ref* ref) { >> ???? if (_nest_level < MAX_NEST_LEVEL) { >> ?????? do_push(ref); >> ?????? delete ref; >> ???? } else { >> ?????? ref->set_next(_pending_refs); >> ?????? _pending_refs = ref; >> ???? } >> ?? } >> }; >> >> and clang generates this code >> >> libjvm.dylib`MetaspaceClosure::push_impl: >> ???? 0x10316db9c <+0>:? pushq? %rbp >> ???? 0x10316db9d <+1>:? movq?? %rsp, %rbp >> ???? 0x10316dba0 <+4>:? pushq? %rbx >> ???? 0x10316dba1 <+5>:? pushq? %rax >> ???? 0x10316dba2 <+6>:? movq?? %rsi, %rbx >> ???? 0x10316dba5 <+9>:? cmpl?? $0x4, 0x10(%rdi) >> ???? 0x10316dba9 <+13>: jg???? 0x10316dbba >> ???? 0x10316dbab <+15>: movq?? %rbx, %rsi >> ???? 0x10316dbae <+18>: callq? 0x10316dbce? ; do_push() >> ???? 0x10316dbb3 <+23>: testq? %rbx, %rbx >> ???? 0x10316dbb6 <+26>: je???? 0x10316dbc6 >> ->? 0x10316dbb8 <+28>: ud2 <<<<<<<<<<<<<<<<<<<<<<< HERE >> ???? 0x10316dbba <+30>: movq?? 0x8(%rdi), %rax >> ???? 0x10316dbbe <+34>: movq?? %rax, 0x20(%rbx) >> ???? 0x10316dbc2 <+38>: movq?? %rbx, 0x8(%rdi) >> ???? 0x10316dbc6 <+42>: addq?? $0x8, %rsp >> ???? 0x10316dbca <+46>: popq?? %rbx >> ???? 0x10316dbcb <+47>: popq?? %rbp >> ???? 0x10316dbcc <+48>: retq >> ???? 0x10316dbcd <+49>: nop >> >> Shouldn't the 'delete' expression be translated to >> ResourceObj::operator delete()? > > Are Ref's allocated on the C_heap? That's the only kind of resourceObj > you can delete: > > void ResourceObj::operator delete(void* p) { > ? assert(((ResourceObj *)p)->allocated_on_C_heap(), > ???????? "delete only allowed for C_HEAP objects"); > ? DEBUG_ONLY(((ResourceObj *)p)->_allocation_t[0] = > (uintptr_t)badHeapOopVal;) > ? FreeHeap(p); > } > I allocate them using Ref *r = new (C_HEAP, mtInternal)Ref(....); However, whether I do that or not isn't something that clang can deduce statically to mark my 'delete' as having undefined behavior. Thanks - Ioi > David > ----- > >> And I couldn't find any warning messages given by clang .... >> >> I rewrote the Ref class to inherit from CHeapObj instead, >> and it magically worked. >> >> However, but there's other use of 'delete' on ResourceObj (such as >> ResourceHashtable) that seems to work just fine. Am I missing something? >> >> Thanks >> >> - Ioi >> >> >> From kim.barrett at oracle.com Sat Feb 9 18:16:16 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 9 Feb 2019 13:16:16 -0500 Subject: C++ delete operator undefined behavior In-Reply-To: <4d342877-b963-c9d0-a1d9-839e97ffd44e@oracle.com> References: <4d342877-b963-c9d0-a1d9-839e97ffd44e@oracle.com> Message-ID: > On Feb 9, 2019, at 3:42 AM, Ioi Lam wrote: > > I am getting a "ud2" instruction on the Mac for a 'delete' expression. According to this page, it's clang flagging an undefined behavior: > > https://stackoverflow.com/questions/21529308/why-does-clang-generate-ud2-opcode-on-osx > > My code looks like this: > > class MetaspaceClosure { > class Ref : public ResourceObj { > ... > }; You have changed Ref to derived from ResourceObj; in current mainline it has no baseclass. Ref is abstract, but in mainline doesn?t have a virtual destructor (which is a bug; it probably should also be non-copyable). delete through a pointer to a base class (which Ref* certainly is, since Ref is abstract) that doesn?t have a virtual destructor is guaranteed slicing, e.g. UB. So there you go. Add the missing (empty) public virtual destructor for Ref (and for extra credit, poison copy and assign). There are some gcc/clang warning options that we could be using that would report mistakes like this, but the last time I tried poking at that it seemed like a substantial tar baby. But maybe somebody should try again and really follow through. From ioi.lam at oracle.com Sat Feb 9 18:36:41 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Sat, 9 Feb 2019 10:36:41 -0800 Subject: C++ delete operator undefined behavior In-Reply-To: References: <4d342877-b963-c9d0-a1d9-839e97ffd44e@oracle.com> Message-ID: On 2/9/19 10:16 AM, Kim Barrett wrote: >> On Feb 9, 2019, at 3:42 AM, Ioi Lam wrote: >> >> I am getting a "ud2" instruction on the Mac for a 'delete' expression. According to this page, it's clang flagging an undefined behavior: >> >> https://stackoverflow.com/questions/21529308/why-does-clang-generate-ud2-opcode-on-osx >> >> My code looks like this: >> >> class MetaspaceClosure { >> class Ref : public ResourceObj { >> ... >> }; > You have changed Ref to derived from ResourceObj; in current mainline it has > no baseclass. Ref is abstract, but in mainline doesn?t have a virtual destructor > (which is a bug; it probably should also be non-copyable). delete through a > pointer to a base class (which Ref* certainly is, since Ref is abstract) that > doesn?t have a virtual destructor is guaranteed slicing, e.g. UB. So there you > go. Add the missing (empty) public virtual destructor for Ref (and for extra > credit, poison copy and assign). Hi Kim, Thanks for the explanation. It starts to make sense now :-) I am not familiar with "poisoning". Are there any examples in the hotspot code? Also, why would clang stop putting in the 'ud2' instruction after I switched to subclassing from CHeapObj? Thanks - Ioi > There are some gcc/clang warning options that we could be using that would > report mistakes like this, but the last time I tried poking at that it seemed like > a substantial tar baby. But maybe somebody should try again and really follow > through. > From robbin.ehn at oracle.com Sat Feb 9 19:03:05 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Sat, 9 Feb 2019 20:03:05 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: <627c1355-3274-934c-1b53-22d98ef811c3@oracle.com> Hi David, >> But there is a 'better' way. > > That raises a red flag for me straight away. I'm always very suspicious of "better ways" that suddenly appear after many > weeks of testing and examination of the previously proposed way. I was planning to do this later as an incremental, so it's not something new to me. But when SS:blocked got more complicated with three totally different cases, callback, callback and block, and just block, reducing this to just the block case was so compelling that I couldn't resist sending out such a version :) I posted both v01 and v02 because I wanted you to have the option to say v01. And sorry for the noise in the incremental webrev, I had to manually merge a lot of lines due to conflicts. I didn't keep track if they would diff from v05 or not, so the inc contains the resolution of the conflicts. Thanks, Robbin > > As Dan has said this is no longer an incremental webrev review, but needs much deeper analysis again. > > David > ----- > >> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >> back-off as the rolling forward loop. It turns out that we mostly never spin >> here at all, when all java threads are stop the callbacks is often already done. >> So the addition of the semaphore have no impact on our benchmarks and is mostly >> unused. This is because most threads are in java which we need to spin-wait >> since they can elide into native without doing a callback. My proposed re-base >> removes the the callbacks completely and let the vm thread do all thread >> accounting. All that the stopping threads needs to do is write state and >> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >> a local store per thread against doing 2 stores per thread by the vm thread. >> This makes it possible for a thread in vm to transition into blocked WITHOUT >> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >> leaving that state. >> >> v06_2 >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >> Inc against v05: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >> Inc against v06_1: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >> >> v06_2 simplifies and removes ~200 LOC with same performance. >> If there is a case with a thread in vm taking long time, it will already >> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >> see no reason why we should not push v06_2. >> >> Passes stress test and t1-5. >> >> Thanks, Robbin >> >> >> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>> Hi all, please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>> >>> Thanks to Dan for pre-reviewing a lot! >>> >>> Background: >>> ZGC often does very short safepoint operations. For a perspective, in a >>> specJBB2015 run, G1 can have young collection stops lasting about 170 ms. While >>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >>> operation it is. The time it takes to stop and start the JavaThreads is relative >>> very large to a ZGC safepoint. With an operation that just takes 0.2ms the >>> overhead of stopping and starting JavaThreads is several times the operation. >>> >>> High-level functionality change: >>> Serializing the starting over Threads_lock takes time. >>> - Don't wait on Threads_lock use the WaitBarrier. >>> Serializing the stopping over Safepoint_lock takes time. >>> - Let threads stop in parallel, remove Safepoint_lock. >>> >>> Details: >>> JavaThreads have 2 abstract logical states: unsafe or safe. >>> - Safe means the JavaThread will not touch Java heap or VM internal structures >>> ?? without doing a transition and block before doing so. >>> ???????? - The safe states are: >>> ???????????????? - When polls armed: _thread_in_native and _thread_blocked. >>> ???????????????? - When Threads_lock is held: externally suspended flag is set. >>> ???????? - VM Thread have polls armed and holds the Threads_lock during a >>> ?????????? safepoint. >>> - Unsafe means that either Java heap or VM internal structures can be accessed >>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>> ???????? - All combination that are not safe are unsafe. >>> >>> We cannot start a safepoint until all unsafe threads have transitioned to a safe >>> state. To make them safe, we arm polls in compiled code and make sure any >>> transition to another unsafe state will be blocked. JavaThreads which are unsafe >>> with state _thread_in_Java may transition to _thread_in_native without being >>> blocked, since it just became a safe thread and we can proceed. Any safe thread >>> may try to transition at any time to an unsafe state, thus coming into the >>> safepoint blocking code at any moment, e.g., after the safepoint is over, or >>> even at the beginning of next safepoint. >>> >>> The VMThread cannot tolerate false positives from the JavaThread thread state >>> because that would mean starting the safepoint without all JavaThreads being >>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we never observe >>> false positives from the safepoint blocking code, if we remove them, how do we >>> handle false positives? >>> >>> By first publishing which barrier tag (safepoint counter) we will call >>> WaitBarrier.wait() with as the threads safepoint id and then change the state to >>> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of >>> the state. A stable load of the thread state is successful if the thread >>> safepoint id is the same both before and after the load of the state and >>> safepoint id is current or InactiveSafepointCounter. If the stable load fails, >>> the thread is considered safepoint unsafe. It's no longer enough that thread is >>> have state _thread_blocked it must also have correct safepoint id before and >>> after we read the state. >>> >>> Performance: >>> The result of faster safepoints is that the average CPU time for JavaThreads >>> between safepoints is higher, thus increasing the allocation rate. The thread >>> that stops first waits shorter time until it gets started. Even the thread that >>> stops last also have shorter stop since we start them faster. If your >>> application is using a concurrent GC it may need re-tunning since each java >>> worker thread have an increased CPU time/allocation rate. Often this means max >>> performance is achieved using slightly less java worker threads than before. >>> Also the increase allocation rate means shorter time between GC safepoints. >>> - If you are using a non-concurrent GC, you should see improved latency and >>> ?? throughput. >>> - After re-tunning with a concurrent GC throughput should be equal or better but >>> ?? with better latency. But bear in mind this is a latency patch, not a >>> ?? throughput one. >>> With current code a java thread is not to guarantee to run between safepoint (in >>> theory a java thread can be starved indefinitely), since the VM thread may >>> re-grab the Threads_locks before it woke up from previous safepoint. If the >>> GC/VM don't respect MMU (minimum mutator utilization) or if your machine is very >>> over-provisioned this can happen. >>> The current schema thus re-safepoint quickly if the java threads have not >>> started yet at the cost of latency. Since the new code uses the WaitBarrier with >>> the safepoint counter, all threads must roll forward to next safepoint by >>> getting at least some CPU time between two safepoints. Meaning MMU violations >>> are more obvious. >>> >>> Some examples on numbers: >>> - On a 16 strand machine synchronization and un-synchronization/starting is at >>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and >>> ?? starting ~400->~100us. >>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). >>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>> ?? synchronization time on 16 strands and ~5% score increase. In this case the GC >>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. >>> - specJBB2015 ParGC ~9% increase in critical-jops. >>> >>> Thanks, Robbin From kim.barrett at oracle.com Sun Feb 10 04:19:08 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 9 Feb 2019 23:19:08 -0500 Subject: C++ delete operator undefined behavior In-Reply-To: References: <4d342877-b963-c9d0-a1d9-839e97ffd44e@oracle.com> Message-ID: <02BC868F-7202-4904-BD41-DA62873A0635@oracle.com> > On Feb 9, 2019, at 1:36 PM, Ioi Lam wrote: > > > On 2/9/19 10:16 AM, Kim Barrett wrote: >>> On Feb 9, 2019, at 3:42 AM, Ioi Lam wrote: >>> >>> I am getting a "ud2" instruction on the Mac for a 'delete' expression. According to this page, it's clang flagging an undefined behavior: >>> >>> https://stackoverflow.com/questions/21529308/why-does-clang-generate-ud2-opcode-on-osx >>> >>> My code looks like this: >>> >>> class MetaspaceClosure { >>> class Ref : public ResourceObj { >>> ... >>> }; >> You have changed Ref to derived from ResourceObj; in current mainline it has >> no baseclass. Ref is abstract, but in mainline doesn?t have a virtual destructor >> (which is a bug; it probably should also be non-copyable). delete through a >> pointer to a base class (which Ref* certainly is, since Ref is abstract) that >> doesn?t have a virtual destructor is guaranteed slicing, e.g. UB. So there you >> go. Add the missing (empty) public virtual destructor for Ref (and for extra >> credit, poison copy and assign). > > Hi Kim, > > Thanks for the explanation. It starts to make sense now :-) > > I am not familiar with "poisoning". Are there any examples in the hotspot code? One of the ways to make a class "non-copyable" in C++98 is to declare its copy constructor and assignment operator private, and not provide a definition for either. That way, external attempts to invoke them will fail at cmpiletime because they are inaccessible (because they are private), and internal or friend attempts will (usually) fail at linktime because they aren't defined. That is, those operations are "poisoned"; attempts to call them will error (hopefully before runtime). So in the case of Ref, just add in the private part of the class // Noncopyable. Ref(const Ref&); Ref& operator=(const Ref&); An existing (recent) example is TaskTerminator (in gc/shared/taskqueue.hpp). In C++11, giving them deleted definitions (either public or private) is better. Ref(const Ref&) = delete; Ref& operator=(const Ref&) = delete; We should consider having a macro to make this simpler and more obvious, e.g. something like #define DECLARE_NONCOPYABLE(Name) \ Name(const Name&); Name& operator=(const Name&); which could be updated someday to delete the definitions. > Also, why would clang stop putting in the 'ud2' instruction after I switched to subclassing from CHeapObj? No immediately obvious (to me) reason. One difference between the two cases is that ResourceObj has a (debug-only) user-defined destructor, whereas in the CHeapObj case Ref would have a trivial destructor. But that doesn't change the fact that deleting through Ref* is slicing off the derived class's (unknown) destructor. So, no, I don't know why there is a difference. It may be that clang is being conservative (or buggy) about when to make that transformation. From david.holmes at oracle.com Mon Feb 11 01:24:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 11 Feb 2019 11:24:25 +1000 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: Hi Robbin, Some comments below but I just noticed there seems to be a major problem with your webrevs/patches. If look at: http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/webrev/open.changeset It shows in safepoint.cpp: +void SafepointSynchronize::increment_jni_active_count() { + Atomic::add(1, &_current_jni_active_count); +} but if I look at the safepoint.cpp raw file: http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/webrev/raw_files/new/src/hotspot/share/runtime/safepoint.cpp it shows the correct: void SafepointSynchronize::increment_jni_active_count() { ++_current_jni_active_count; } This makes it impossible to use the changeset to search through to check out how things are being used. In particular in this case there doesn't seem to be a need for the SafepointSynchronize::increment_jni_active_count() function because its only used by the VMThread now from within the other safepoint code. More below ... On 8/02/2019 2:05 am, Robbin Ehn wrote: > Hi all, here is the promised re-base (v06) on > 8210832: Remove sneaky locking in class Monitor. > > v06_1 is just a straight re-base. > > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ > Inc: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ > > Passes stress test and t1-5. > > But there is a 'better' way. > Before I added the more graceful "_vm_wait->wait();" semaphore in the while > (_waiting_to_block > 0) { loop, it was a just a busy spin using the same I think I've lost track of the changes here. Initially we waited on the _safepoint_lock; then in preview_13 we switched to polling with backoff. Not sure when _vm_wait->wait was introduced but we're now returning to polling with backoff. Is that right? Once the VMThread polls until all threads are known to be safepoint-safe we eliminate a whole category of race conditions with the thread-state changes that allows us to simplify those thread-state changes. > back-off as the rolling forward loop. It turns out that we mostly never > spin > here at all, when all java threads are stop the callbacks is often > already done. > So the addition of the semaphore have no impact on our benchmarks and is > mostly > unused. This is because most threads are in java which we need to spin-wait > since they can elide into native without doing a callback. My proposed > re-base > removes the the callbacks completely and let the vm thread do all thread > accounting. All that the stopping threads needs to do is write state and > safepoint id, everything else is handle by the vm thread. We trade 2 > atomics + > a local store per thread against doing 2 stores per thread by the vm > thread. > This makes it possible for a thread in vm to transition into blocked > WITHOUT > safepoint poll. Just set thread_blocked and promise to do safepoint poll > when > leaving that state. Right - but you've only implemented that for the new ThreadBlockInVMWithDeadlockCheck, though the same argument applies to the regular TBIVM. We can/should re-examine TBIVM logic, and see if we can simplify and combine with new ThreadBlockInVMWithDeadlockCheck. Future RFE. Aside: from a safepoint perspective I really don't see any difference between going out to "native" and going out to a (potentially) "blocking" library call. There are both safepoint-safe and should have the same requirements as you exit and enter the VM. > v06_2 > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ > Inc against v05: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ > Inc against v06_1: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ > > v06_2 simplifies and removes ~200 LOC with same performance. > If there is a case with a thread in vm taking long time, it will already > screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. > So I > see no reason why we should not push v06_2. src/hotspot/share/runtime/interfaceSupport.inline.hpp 317 thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); Should use _thread_in_vm_trans 326 _thread->set_thread_state((JavaThreadState)(_thread_blocked + 1)); Should use _thread_blocked_trans That said, I'm unclear what role the trans states now play here. Originally the VMThread had to spin when it saw a trans state because the final state would determine how the VMThread needed to respond next. But with the VMThread always spinning I don't see that we necessarily need the additional complexity. Anyway that too could be looked at later. I'd like to take one more pass through the full changeset once it has been generated correctly. Thanks, David > Passes stress test and t1-5. > > Thanks, Robbin From stefan.karlsson at oracle.com Mon Feb 11 08:39:54 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 09:39:54 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles Message-ID: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> Hi all, Please review this patch to fix the resolving of oops inside the (VM) OopHandles. https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218734 Before this patch the OopHandle::_obj was assumed to be located at offset 0, and the SA resolved OopHandle (Klass::_java_mirror and ClassLoaderData::_class_loader) without the required load barrier for ZGC. I've added a new class VMOopHandle (The SA already has a OopHandle), which handles the resolving (load or load + barrier). The OopHandle type is grouped under the Oops section in vmStructs.cpp. It's not an oop, so I added a newline to separate it out from the rest. Any suggestion of a better location in that file? Tested with the jtreg tests in serviceability/sa + patches to make ZGC usable with the SA's hprof dumping. Thanks, StefanK From robbin.ehn at oracle.com Mon Feb 11 09:02:04 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 11 Feb 2019 10:02:04 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: Hi David, On 2/11/19 2:24 AM, David Holmes wrote: > This makes it impossible to use the changeset to search through to check out how > things are being used. In particular in this case there doesn't seem to be a > need for the SafepointSynchronize::increment_jni_active_count() function because > its only used by the VMThread now from within the other safepoint code. > We sorted this out in other channel, it's a webrev bug (or miss-feature). > More below ... >> But there is a 'better' way. >> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same > > I think I've lost track of the changes here. Initially we waited on the > _safepoint_lock; then in preview_13 we switched to polling with backoff. Not > sure when _vm_wait->wait was introduced but we're now returning to polling with > backoff. Is that right? Yes. > > Once the VMThread polls until all threads are known to be safepoint-safe we > eliminate a whole category of race conditions with the thread-state changes that > allows us to simplify those thread-state changes. Yes. > >> back-off as the rolling forward loop. It turns out that we mostly never spin >> here at all, when all java threads are stop the callbacks is often already done. >> So the addition of the semaphore have no impact on our benchmarks and is mostly >> unused. This is because most threads are in java which we need to spin-wait >> since they can elide into native without doing a callback. My proposed re-base >> removes the the callbacks completely and let the vm thread do all thread >> accounting. All that the stopping threads needs to do is write state and >> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >> a local store per thread against doing 2 stores per thread by the vm thread. >> This makes it possible for a thread in vm to transition into blocked WITHOUT >> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >> leaving that state. > > Right - but you've only implemented that for the new > ThreadBlockInVMWithDeadlockCheck, though the same argument applies to the > regular TBIVM. We can/should re-examine TBIVM logic, and see if we can simplify > and combine with new ThreadBlockInVMWithDeadlockCheck. Future RFE. Yes! > > Aside: from a safepoint perspective I really don't see any difference between > going out to "native" and going out to a (potentially) "blocking" library call. > There are both safepoint-safe and should have the same requirements as you exit > and enter the VM. Yes. > >> v06_2 >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >> Inc against v05: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >> Inc against v06_1: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >> >> v06_2 simplifies and removes ~200 LOC with same performance. >> If there is a case with a thread in vm taking long time, it will already >> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >> see no reason why we should not push v06_2. > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > > 317???? thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); > > Should use _thread_in_vm_trans > > 326???? _thread->set_thread_state((JavaThreadState)(_thread_blocked + 1)); > > Should use _thread_blocked_trans Yes. > > That said, I'm unclear what role the trans states now play here. Originally the > VMThread had to spin when it saw a trans state because the final state would > determine how the VMThread needed to respond next. But with the VMThread always > spinning I don't see that we necessarily need the additional complexity. Anyway > that too could be looked at later. Yes. Part of the bigger plan is to simplify the states. If we ignore the trace_flag (suspend/resume, async exception,..) we could now just have two states, safe and unsafe and you only need to safepoint poll when going to a safe state. > > I'd like to take one more pass through the full changeset once it has been > generated correctly. Thanks, Robbin > > Thanks, > David > >> Passes stress test and t1-5. >> >> Thanks, Robbin From robbin.ehn at oracle.com Mon Feb 11 09:29:17 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 11 Feb 2019 10:29:17 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: <24625727-ba6c-5f77-a820-cd73cd4b780c@oracle.com> Hi Dan, > > This webrev's patch file is again a couple of patches together which > makes searches of the patch for patterns problematic. I still managed > to find an errant use of _call_back in a comment, but it wasn't easy. > There is a bug webrev that makes it do on changeset per commit and put all those into open.changeset. I have baseline, v01 and v02 applied it does this, since I need to be able to change both v01 and v02. If you apply the open.changeset it will become a flat diff. I'll try to work around this bug for next update. > src/hotspot/share/runtime/interfaceSupport.inline.hpp > ??? L317: thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); > ??? L318: InterfaceSupport::serialize_thread_state_with_handler(thread); > ??? L319: > ??? old L320: SafepointMechanism::callback_if_safepoint(thread); > ??? L320: ??? thread->set_thread_state(_thread_blocked); > ??????? I'm having trouble with dropping callback_if_safepoint() here, > ??????? but I can't put my finger on it yet. We're taking out these > ??????? lines of code: > > ??????? L66: ? if (!uses_thread_local_poll() || local_poll_armed(thread)) { > ??????? L73: ??? if (global_poll()) { > ??????? L74: ????? SafepointSynchronize::block(thread, false); > > ??????? which my brain first read as taking out blocking for a safepoint, > ??????? but then I remembered the 'false' parameter means we don't actually > ??????? block for the safepoint. Okay, I'm glad that parameter is now gone > ??????? from block(). So now it's much clearer that we are not blocking for > ??????? a safepoint in the ThreadBlockInVMWithDeadlockCheck ctr. This is > ??????? new behavior with Patricio's remove sneaky locking code and is not > ??????? new with faster safepoints. Yea. > > src/hotspot/share/runtime/safepoint.hpp > ??? L115: ? // Back off strategy when synchronizing a safepoint: > ??? L116: ? static void back_off(); > ??????? This function doesn't exist. Thanks, removed. > > src/hotspot/share/runtime/safepoint.cpp > ??? Is this the code you intended to put in a back_off() function? > > ??? L273: ??? if (still_running > 0) { > ??? L274: ????? // iterations will be 2 the first time we enter this spin > back-off. > ??? L275: ????? // naked_short_nanosleep takes tenths of micros which means that > ??? L276: ????? // number of nanoseconds is irrelevant if it's below that. We do > ??? L277: ????? // 20 1 ns sleeps with a total cost of ~1 ms, then we do 1 ms > sleeps. > ??? L278: ????? jlong sleep_ns = 1; > ??? L279: ????? if (iterations > 21) { > ??? L280: ??????? sleep_ns = NANOUNITS / MILLIUNITS;? // 1 ms > ??? L281: ????? } > ??? L282: ????? os::naked_short_nanosleep(sleep_ns); > ??? L283: ??? } > > ??? Refactoring it in back_off() would clean things up a bit. In earlier versions it was platform specific, but now it's not. Sure, added static void back_off(int iterations) as a static C function above. > > > ??? L1082: ? // Check state.? block() will set thread state to thread_in_vm > which will > ??? L1083: ? // cause the safepoint state _type to become _call_back. > ??? L1084: ? assert(!SafepointMechanism::uses_global_page_poll() || > !_safepoint_safe, > ??? L1085: ???????? "polling page exception on thread safepoint safe"); > ??????? This comment is now stale, but I'm not sure how it should be > ??????? rewritten. The original comment doesn't really match the > ??????? original assert() so I wonder if it went stale before this > ??????? fix... Perhaps the comment should be: > > ???????????? // If we're using a global poll, then the thread should not be > ???????????? // marked as safepoint safe yet. Yes, thanks. > > ??? There are pluses and minuses to the JavaThreads no longer calling back: > > ??? pluses: > ????? - It was a bit confusing when a JavaThread could call back for itself > ??????? or the VMThread could call back for a JavaThread in other cases. > ????? - Now, only the VMThread handles setting _safepoint_safe which is the > ??????? replacement for call back. So you want some asserts in there? > ??? minuses: > ????? - It feels like we've lost some debugging state with the removal of > ??????? call back, but maybe that's not right. I guess we couldn't distinguish > ??????? _who_ called back before (JavaThread for self or VMThread). Added assert for _safepoint_safe. > > I'm not entirely convinced that we have all of our bases covered for a > thread blocking at a safepoint, but we have that worry with Patricio's > removal of sneaky locking and we're going to shake that out with some > targeted stress testing. > > Robbin, you mentioned stress test above. What kind of stress testing did > you run and for how long? Multiple instances of UnexpectedDeoptimizationTest combined with instances of handshakes tests, an hour. That combination caught the bug with just looking at global and not checking local poll armed first in sneaky locking. So it have pretty good coverage. I'll start do more stress test on next revision. > > I think I'm good with where v06_2 is going. Of course, I'll mull on it > over the weekend and I may have more comments next week. Great, thanks, Robbin > > Dan > From robbin.ehn at oracle.com Mon Feb 11 10:15:47 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 11 Feb 2019 11:15:47 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: <78AEA4C5-1D68-465B-94F6-3AFE01B77029@oracle.com> References: <78AEA4C5-1D68-465B-94F6-3AFE01B77029@oracle.com> Message-ID: <9b327425-452d-aa92-1e4d-38b157a08359@oracle.com> Hi Karen, On 2/8/19 11:52 PM, Karen Kinnear wrote: > 1. safepoint.cpp > I thought with the JFR change you could remove the try_stable_load_state with > InactiveSafepointCounter? When would you be in this code and not with a valid > safepoint_count? During a handshake, which calls handshake_safe(...). > > 2. _waiting_to_block and _current_jni_active_count are no longer volatile - > assumed only read/modified by VMThread - could you add assertions in the > accessors that this is the VMThread? Sure. > > 3. safepoint.cpp line 413: "Keep event from now." -> what does this comment mean? > ?? line 815: "safepoint callback" -> can you update the comment since we > removed the "callback" mechanism - I do realize that we still have the > block_if_requested. Yes. > > 4. Do you have stress tests with high thread counts? Does the updated mechanism > for _thread_in_vm work as well there? They all complete and no latency issues? I have seen any problems, we know that it probably exists. Such as the initialization of C2 compiler use todo a 7ms operation in VM. The VM thread would in that case start sleeping 1 ms at the time. So the outlier would potential be 8 ms instead of 7ms. But as I said, we which fix 7ms anyways :) > > 5. Do you test with ThreadLocalHandshakes off and on? Yes. > > Future Cleanup Wishlist: > 1. TBIVM: > ?? - clean up code that is trying to do an explicit safepoint_poll, > ?? at that point the TBIVM could also skip the safepoint check in the constructor ? Yes, but in some-places it is a bit miss-used to do a safepoint poll. We should go over those places and change to block_if_request. And then remove the front-edge safepoint poll. > 2. when do we check safepoint_safe_with and native is not walkable (or > !has_last_Java_frame ?) > ?? why is this not an assertion? When do we transition to native without > make_walkable? JNI critical methods. > 3. ThreadInVMfromUnknown - what if not in _thread_in_native? Then we don't > transition to _thread_in_vm and we are not in the state we think we are - when > does this happen and what state are we left in? > This is a old transition, i have not changed it. I believe the compiler have code path which is both executed with state in vm and state in native. If they are already in vm it does nothing. Thanks, Robbin > >> On Feb 8, 2019, at 5:37 PM, Daniel D. Daugherty > > wrote: >> >> Robbin, >> >> Because this is a completely different way of solving this problem, I don't >> think I can review this incrementally. That means another crawl through >> review and might even mean another round of whiteboard diagrams... >> >> A proper review will obviously take me longer than I planned, but I wanted >> you know that I'm starting to look at it from the beginning... :-) >> >> Dan >> >> >> On 2/7/19 11:05 AM, Robbin Ehn wrote: >>> But there is a 'better' way. >>> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >>> back-off as the rolling forward loop. It turns out that we mostly never spin >>> here at all, when all java threads are stop the callbacks is often already done. >>> So the addition of the semaphore have no impact on our benchmarks and is mostly >>> unused. This is because most threads are in java which we need to spin-wait >>> since they can elide into native without doing a callback. My proposed re-base >>> removes the the callbacks completely and let the vm thread do all thread >>> accounting. All that the stopping threads needs to do is write state and >>> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >>> a local store per thread against doing 2 stores per thread by the vm thread. >>> This makes it possible for a thread in vm to transition into blocked WITHOUT >>> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >>> leaving that state. >>> >>> v06_2 >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>> Inc against v05: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>> Inc against v06_1: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>> >>> v06_2 simplifies and removes ~200 LOC with same performance. >>> If there is a case with a thread in vm taking long time, it will already >>> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >>> see no reason why we should not push v06_2. >>> >>> Passes stress test and t1-5. >>> >>> Thanks, Robbin >> > From robbin.ehn at oracle.com Mon Feb 11 11:34:03 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 11 Feb 2019 12:34:03 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: <9f364d4e-6685-adb5-2cf7-f1a79b87d160@oracle.com> Hi Dan, > src/hotspot/share/runtime/safepoint.cpp > ??? L846: ? assert(state ==? _thread_in_vm_trans, "bad"); > ??????? nit - please delete extra space after '==' Fixed. > > ??? old L880: ????? if (thread->safepoint_state()->type() == > ThreadSafepointState::_call_back && > ??? old L881: ????????? block_in_safepoint_check) { > ??? new L944: ????? if (thread->safepoint_state()->type() == > ThreadSafepointState::_call_back > ??? new L945: ????????? && !block_in_safepoint_check) { > ??????? Why did the seond expression get inverted? > > ??????? "block_in_safepoint_check" => "!block_in_safepoint_check" > > ??????? old L881 was not in v05 so it must have come from Patricio's > ??????? recent changes here. Is this a merge error? Yes, a lot of conflicts. Fixed. > I double checked my previous recent reviews and I think everything is > still resolved and in good shape. As usual for this project, safepoint.cpp > is a nightmare to review, but I did try to sanity check with respect to > all the code motion. Thanks, I'll do some more testing on this also. /Robbin > > Thumbs up. > > Dan > > > > >>>> Inc: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >>> >>> Something is wrong with this incremental webrev. I was expecting an >>> incremental webrev relative to the v05 version, but that's not >>> what I see in src/hotspot/share/runtime/safepoint.cpp. In that file >>> I'm seeing changes relative to the baseline, e.g., deletion of the >>> Safepoint_lock, etc. >> >> So I dropped back to the full patch for v05 and tried to compare that >> to the v06_1/full patch above using jfilemerge. That's not working for >> me either. >> >> Next I'm going to just look at the v06_1/full webrev and see if that >> makes sense. >> >> Dan >> >> >>> >>> Dan >>> >>> >>> >>>> >>>> Passes stress test and t1-5. >>>> >>>> But there is a 'better' way. >>>> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >>>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >>>> back-off as the rolling forward loop. It turns out that we mostly never spin >>>> here at all, when all java threads are stop the callbacks is often already >>>> done. >>>> So the addition of the semaphore have no impact on our benchmarks and is mostly >>>> unused. This is because most threads are in java which we need to spin-wait >>>> since they can elide into native without doing a callback. My proposed re-base >>>> removes the the callbacks completely and let the vm thread do all thread >>>> accounting. All that the stopping threads needs to do is write state and >>>> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >>>> a local store per thread against doing 2 stores per thread by the vm thread. >>>> This makes it possible for a thread in vm to transition into blocked WITHOUT >>>> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >>>> leaving that state. >>>> >>>> v06_2 >>>> Full: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>>> Inc against v05: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>>> Inc against v06_1: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>>> >>>> v06_2 simplifies and removes ~200 LOC with same performance. >>>> If there is a case with a thread in vm taking long time, it will already >>>> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >>>> see no reason why we should not push v06_2. >>>> >>>> Passes stress test and t1-5. >>>> >>>> Thanks, Robbin >>>> >>>> >>>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>>> Hi all, please review. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>>> >>>>> Thanks to Dan for pre-reviewing a lot! >>>>> >>>>> Background: >>>>> ZGC often does very short safepoint operations. For a perspective, in a >>>>> specJBB2015 run, G1 can have young collection stops lasting about 170 ms. >>>>> While >>>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >>>>> operation it is. The time it takes to stop and start the JavaThreads is >>>>> relative >>>>> very large to a ZGC safepoint. With an operation that just takes 0.2ms the >>>>> overhead of stopping and starting JavaThreads is several times the operation. >>>>> >>>>> High-level functionality change: >>>>> Serializing the starting over Threads_lock takes time. >>>>> - Don't wait on Threads_lock use the WaitBarrier. >>>>> Serializing the stopping over Safepoint_lock takes time. >>>>> - Let threads stop in parallel, remove Safepoint_lock. >>>>> >>>>> Details: >>>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>>> - Safe means the JavaThread will not touch Java heap or VM internal structures >>>>> ?? without doing a transition and block before doing so. >>>>> ???????? - The safe states are: >>>>> ???????????????? - When polls armed: _thread_in_native and _thread_blocked. >>>>> ???????????????? - When Threads_lock is held: externally suspended flag is >>>>> set. >>>>> ???????? - VM Thread have polls armed and holds the Threads_lock during a >>>>> ?????????? safepoint. >>>>> - Unsafe means that either Java heap or VM internal structures can be accessed >>>>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>>> ???????? - All combination that are not safe are unsafe. >>>>> >>>>> We cannot start a safepoint until all unsafe threads have transitioned to a >>>>> safe >>>>> state. To make them safe, we arm polls in compiled code and make sure any >>>>> transition to another unsafe state will be blocked. JavaThreads which are >>>>> unsafe >>>>> with state _thread_in_Java may transition to _thread_in_native without being >>>>> blocked, since it just became a safe thread and we can proceed. Any safe >>>>> thread >>>>> may try to transition at any time to an unsafe state, thus coming into the >>>>> safepoint blocking code at any moment, e.g., after the safepoint is over, or >>>>> even at the beginning of next safepoint. >>>>> >>>>> The VMThread cannot tolerate false positives from the JavaThread thread state >>>>> because that would mean starting the safepoint without all JavaThreads being >>>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we never >>>>> observe >>>>> false positives from the safepoint blocking code, if we remove them, how do we >>>>> handle false positives? >>>>> >>>>> By first publishing which barrier tag (safepoint counter) we will call >>>>> WaitBarrier.wait() with as the threads safepoint id and then change the >>>>> state to >>>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of >>>>> the state. A stable load of the thread state is successful if the thread >>>>> safepoint id is the same both before and after the load of the state and >>>>> safepoint id is current or InactiveSafepointCounter. If the stable load fails, >>>>> the thread is considered safepoint unsafe. It's no longer enough that >>>>> thread is >>>>> have state _thread_blocked it must also have correct safepoint id before and >>>>> after we read the state. >>>>> >>>>> Performance: >>>>> The result of faster safepoints is that the average CPU time for JavaThreads >>>>> between safepoints is higher, thus increasing the allocation rate. The thread >>>>> that stops first waits shorter time until it gets started. Even the thread >>>>> that >>>>> stops last also have shorter stop since we start them faster. If your >>>>> application is using a concurrent GC it may need re-tunning since each java >>>>> worker thread have an increased CPU time/allocation rate. Often this means max >>>>> performance is achieved using slightly less java worker threads than before. >>>>> Also the increase allocation rate means shorter time between GC safepoints. >>>>> - If you are using a non-concurrent GC, you should see improved latency and >>>>> ?? throughput. >>>>> - After re-tunning with a concurrent GC throughput should be equal or >>>>> better but >>>>> ?? with better latency. But bear in mind this is a latency patch, not a >>>>> ?? throughput one. >>>>> With current code a java thread is not to guarantee to run between >>>>> safepoint (in >>>>> theory a java thread can be starved indefinitely), since the VM thread may >>>>> re-grab the Threads_locks before it woke up from previous safepoint. If the >>>>> GC/VM don't respect MMU (minimum mutator utilization) or if your machine is >>>>> very >>>>> over-provisioned this can happen. >>>>> The current schema thus re-safepoint quickly if the java threads have not >>>>> started yet at the cost of latency. Since the new code uses the WaitBarrier >>>>> with >>>>> the safepoint counter, all threads must roll forward to next safepoint by >>>>> getting at least some CPU time between two safepoints. Meaning MMU violations >>>>> are more obvious. >>>>> >>>>> Some examples on numbers: >>>>> - On a 16 strand machine synchronization and un-synchronization/starting is at >>>>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and >>>>> ?? starting ~400->~100us. >>>>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). >>>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>>> ?? synchronization time on 16 strands and ~5% score increase. In this case >>>>> the GC >>>>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. >>>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>>> >>>>> Thanks, Robbin >>> >> > From robbin.ehn at oracle.com Mon Feb 11 13:13:06 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 11 Feb 2019 14:13:06 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: <24d259f5-100e-d7ea-a30f-1b0694f36767@oracle.com> References: <24d259f5-100e-d7ea-a30f-1b0694f36767@oracle.com> Message-ID: <0a97367c-7bdf-e615-5f5e-0abd659c91c7@oracle.com> Hi Patricio, Fixed and added a comment. Thanks, Robbin On 2/8/19 5:46 PM, Patricio Chilano wrote: > Correction about the fence, I think we actually need it to avoid the change of > state to _thread_blocked to float above frame_anchor()->make_walkable. So it > should be: > > --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp > +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp > @@ -314,8 +314,7 @@ > ???? // Once we are blocked vm expects stack to be walkable > ???? thread->frame_anchor()->make_walkable(thread); > > -??? thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); > -??? InterfaceSupport::serialize_thread_state_with_handler(thread); > +??? OrderAccess::storestore(); > > ???? thread->set_thread_state(_thread_blocked); > > > Otherwise if we keep > "InterfaceSupport::serialize_thread_state_with_handler(thread);" maybe we should > also change the comment "// Make sure new state is seen by VM thread". > > > Thanks, > Patricio > > On 2/8/19 10:58 AM, Patricio Chilano wrote: >> Hi Robbin, >> >> Version v06_2 looks good to me. One minor comment: >> >> --- a/src/hotspot/share/runtime/interfaceSupport.inline.hpp >> +++ b/src/hotspot/share/runtime/interfaceSupport.inline.hpp >> @@ -314,9 +314,6 @@ >> ???? // Once we are blocked vm expects stack to be walkable >> ???? thread->frame_anchor()->make_walkable(thread); >> >> -??? thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); >> - InterfaceSupport::serialize_thread_state_with_handler(thread); >> - >> ???? thread->set_thread_state(_thread_blocked); >> >> Since we are not calling SS::block() anymore in the TBIVMWDC constructor we >> can remove setting the thread state to the temporary _thread_in_vm_trans and >> also the fence after that. >> >> >> Thanks, >> Patricio >> >> On 2/7/19 11:05 AM, Robbin Ehn wrote: >>> Hi all, here is the promised re-base (v06) on >>> 8210832: Remove sneaky locking in class Monitor. >>> >>> v06_1 is just a straight re-base. >>> >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >>> Inc: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >>> >>> Passes stress test and t1-5. >>> >>> But there is a 'better' way. >>> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >>> back-off as the rolling forward loop. It turns out that we mostly never spin >>> here at all, when all java threads are stop the callbacks is often already done. >>> So the addition of the semaphore have no impact on our benchmarks and is mostly >>> unused. This is because most threads are in java which we need to spin-wait >>> since they can elide into native without doing a callback. My proposed re-base >>> removes the the callbacks completely and let the vm thread do all thread >>> accounting. All that the stopping threads needs to do is write state and >>> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >>> a local store per thread against doing 2 stores per thread by the vm thread. >>> This makes it possible for a thread in vm to transition into blocked WITHOUT >>> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >>> leaving that state. >>> >>> v06_2 >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>> Inc against v05: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>> Inc against v06_1: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>> >>> v06_2 simplifies and removes ~200 LOC with same performance. >>> If there is a case with a thread in vm taking long time, it will already >>> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >>> see no reason why we should not push v06_2. >>> >>> Passes stress test and t1-5. >>> >>> Thanks, Robbin >>> >>> >>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>> Hi all, please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>> >>>> Thanks to Dan for pre-reviewing a lot! >>>> >>>> Background: >>>> ZGC often does very short safepoint operations. For a perspective, in a >>>> specJBB2015 run, G1 can have young collection stops lasting about 170 ms. While >>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >>>> operation it is. The time it takes to stop and start the JavaThreads is >>>> relative >>>> very large to a ZGC safepoint. With an operation that just takes 0.2ms the >>>> overhead of stopping and starting JavaThreads is several times the operation. >>>> >>>> High-level functionality change: >>>> Serializing the starting over Threads_lock takes time. >>>> - Don't wait on Threads_lock use the WaitBarrier. >>>> Serializing the stopping over Safepoint_lock takes time. >>>> - Let threads stop in parallel, remove Safepoint_lock. >>>> >>>> Details: >>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>> - Safe means the JavaThread will not touch Java heap or VM internal structures >>>> ?? without doing a transition and block before doing so. >>>> ???????? - The safe states are: >>>> ???????????????? - When polls armed: _thread_in_native and _thread_blocked. >>>> ???????????????? - When Threads_lock is held: externally suspended flag is set. >>>> ???????? - VM Thread have polls armed and holds the Threads_lock during a >>>> ?????????? safepoint. >>>> - Unsafe means that either Java heap or VM internal structures can be accessed >>>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>> ???????? - All combination that are not safe are unsafe. >>>> >>>> We cannot start a safepoint until all unsafe threads have transitioned to a >>>> safe >>>> state. To make them safe, we arm polls in compiled code and make sure any >>>> transition to another unsafe state will be blocked. JavaThreads which are >>>> unsafe >>>> with state _thread_in_Java may transition to _thread_in_native without being >>>> blocked, since it just became a safe thread and we can proceed. Any safe thread >>>> may try to transition at any time to an unsafe state, thus coming into the >>>> safepoint blocking code at any moment, e.g., after the safepoint is over, or >>>> even at the beginning of next safepoint. >>>> >>>> The VMThread cannot tolerate false positives from the JavaThread thread state >>>> because that would mean starting the safepoint without all JavaThreads being >>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we never >>>> observe >>>> false positives from the safepoint blocking code, if we remove them, how do we >>>> handle false positives? >>>> >>>> By first publishing which barrier tag (safepoint counter) we will call >>>> WaitBarrier.wait() with as the threads safepoint id and then change the >>>> state to >>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of >>>> the state. A stable load of the thread state is successful if the thread >>>> safepoint id is the same both before and after the load of the state and >>>> safepoint id is current or InactiveSafepointCounter. If the stable load fails, >>>> the thread is considered safepoint unsafe. It's no longer enough that thread is >>>> have state _thread_blocked it must also have correct safepoint id before and >>>> after we read the state. >>>> >>>> Performance: >>>> The result of faster safepoints is that the average CPU time for JavaThreads >>>> between safepoints is higher, thus increasing the allocation rate. The thread >>>> that stops first waits shorter time until it gets started. Even the thread that >>>> stops last also have shorter stop since we start them faster. If your >>>> application is using a concurrent GC it may need re-tunning since each java >>>> worker thread have an increased CPU time/allocation rate. Often this means max >>>> performance is achieved using slightly less java worker threads than before. >>>> Also the increase allocation rate means shorter time between GC safepoints. >>>> - If you are using a non-concurrent GC, you should see improved latency and >>>> ?? throughput. >>>> - After re-tunning with a concurrent GC throughput should be equal or better >>>> but >>>> ?? with better latency. But bear in mind this is a latency patch, not a >>>> ?? throughput one. >>>> With current code a java thread is not to guarantee to run between safepoint >>>> (in >>>> theory a java thread can be starved indefinitely), since the VM thread may >>>> re-grab the Threads_locks before it woke up from previous safepoint. If the >>>> GC/VM don't respect MMU (minimum mutator utilization) or if your machine is >>>> very >>>> over-provisioned this can happen. >>>> The current schema thus re-safepoint quickly if the java threads have not >>>> started yet at the cost of latency. Since the new code uses the WaitBarrier >>>> with >>>> the safepoint counter, all threads must roll forward to next safepoint by >>>> getting at least some CPU time between two safepoints. Meaning MMU violations >>>> are more obvious. >>>> >>>> Some examples on numbers: >>>> - On a 16 strand machine synchronization and un-synchronization/starting is at >>>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and >>>> ?? starting ~400->~100us. >>>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). >>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>> ?? synchronization time on 16 strands and ~5% score increase. In this case >>>> the GC >>>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. >>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>> >>>> Thanks, Robbin >> > From lois.foltan at oracle.com Mon Feb 11 19:16:05 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 11 Feb 2019 14:16:05 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: <55957964-5eab-6467-6ea9-bfd1bf6e33e0@oracle.com> References: <55957964-5eab-6467-6ea9-bfd1bf6e33e0@oracle.com> Message-ID: <8b074f18-078f-99d1-906d-cae57cc87ef5@oracle.com> On 2/6/2019 3:34 PM, Lois Foltan wrote: > > On 2/5/2019 6:01 PM, coleen.phillimore at oracle.com wrote: >> >> Hi Lois,? I like that there are no longer two resolved references for >> indy instructions, especially if it wasn't used. > > Thanks Coleen for the review!? More below. > >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/interpreter/linkResolver.cpp.udiff.html >> >> >> I can't find a call where set_handle() passes false for the >> _has_local_sig field. > > There is no call to set_handle() that passes false for the > _has_local_sig field.? It is set to false initially in > CallInfo::set_common.? I considered not passing the "has_local_sig" > parameter to set_handle and just always set CallInfo::_has_local_sig > to true within that method but I am assuming John wanted to allow for > the possibility that it could be set to false in the future. > >> >> Can you rename CallInfo::_has_local_signature, since it's not that >> much longer and reads better? >> >> + const bool has_local_sig = call_info.has_local_signature(); >> + assert(has_local_sig, "MHs and indy are always sig-poly"); > > I'm confused.? The field currently within CallInfo is named > CallInfo::_has_local_sig.? Are you referring to the method > CallInfo::has_local_signature()?? Do you want that shortened? > >> >> So why do you need this field if it's always true?? Was hoping for a >> cpCache bit back :) Hi Coleen, I looked over your review comments again and you are correct concerning the need for CallInfo::_has_local_sig.? It is always set to true for MHs and indy and thus really is not necessary for setting the local variable "has_local_sig" within the method ConstantPoolCacheEntry::set_method_handle_common().? I have removed CallInfo::_has_local_sig. ConstantPoolCacheEntry::has_local_signature_shift is still necessary, however. Updated webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.3/webrev/ Thanks for your review and help with this! Lois > > It's not always true. > >> >> Perhaps there's a future use? >> >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/oops/cpCache.hpp.udiff.html >> >> >> + has_local_signature_shift = 25, // (M) does the call site have a >> per-site signature (sig-poly methods)? >> >> >> Can you make this an "S" vs. "M" and change the coment in the top of >> cpCache.hpp: >> >> // _flags???? [tos|0|F=0|M|A|I|f|0|vf|indy_rf|000|00000|psize] (for >> method entries) >> // bit length [ 4 |1| 1 |1|1|1|1|1|1 |-4--|--8--|--8--] > > Done, changed the "M" to "S" in both places.? The comment in the top > of cpCache.hpp does not refer to the method_type in any form, so > unclear as to how you want me to change it?? I am assuming you want me > to remove the "method_type info (t_section) from this comment? > > // _flags?? = method type info (t section), > //??????????? virtual final bit (vfinal), > > >> >> And a line under this: >> >> // A????? = call site has an appendix argument (loaded from resolved >> references) > > Not sure what you mean by this? > > Thanks, > Lois > >> >> Although I don't like this comment because it gets out of date. >> >> Thanks, >> Coleen >> >> On 2/4/19 7:32 AM, Lois Foltan wrote: >>> Please review this change that removes the unused method_type field >>> associated with the appendix field of an indy or method handle >>> call.? This is the first of a series of changes working towards >>> JDK-8210685: Bootstrap method consolidation. >>> >>> open webrev at: >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ >>> bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 >>> co-contributors: Lois Foltan & John Rose >>> >>> Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 (linux >>> only), JCK vm & lang (linux only) >>> >>> Thanks, >>> Lois >> > From coleen.phillimore at oracle.com Mon Feb 11 19:58:44 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 11 Feb 2019 14:58:44 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: <8b074f18-078f-99d1-906d-cae57cc87ef5@oracle.com> References: <55957964-5eab-6467-6ea9-bfd1bf6e33e0@oracle.com> <8b074f18-078f-99d1-906d-cae57cc87ef5@oracle.com> Message-ID: <9f3e1ee6-d133-1601-3849-5cef40541e59@oracle.com> On 2/11/19 2:16 PM, Lois Foltan wrote: > > > On 2/6/2019 3:34 PM, Lois Foltan wrote: >> >> On 2/5/2019 6:01 PM, coleen.phillimore at oracle.com wrote: >>> >>> Hi Lois,? I like that there are no longer two resolved references >>> for indy instructions, especially if it wasn't used. >> >> Thanks Coleen for the review!? More below. >> >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/interpreter/linkResolver.cpp.udiff.html >>> >>> >>> I can't find a call where set_handle() passes false for the >>> _has_local_sig field. >> >> There is no call to set_handle() that passes false for the >> _has_local_sig field.? It is set to false initially in >> CallInfo::set_common.? I considered not passing the "has_local_sig" >> parameter to set_handle and just always set CallInfo::_has_local_sig >> to true within that method but I am assuming John wanted to allow for >> the possibility that it could be set to false in the future. >> >>> >>> Can you rename CallInfo::_has_local_signature, since it's not that >>> much longer and reads better? >>> >>> + const bool has_local_sig = call_info.has_local_signature(); >>> + assert(has_local_sig, "MHs and indy are always sig-poly"); >> >> I'm confused.? The field currently within CallInfo is named >> CallInfo::_has_local_sig.? Are you referring to the method >> CallInfo::has_local_signature()?? Do you want that shortened? >> >>> >>> So why do you need this field if it's always true?? Was hoping for a >>> cpCache bit back :) > > Hi Coleen, > > I looked over your review comments again and you are correct > concerning the need for CallInfo::_has_local_sig.? It is always set to > true for MHs and indy and thus really is not necessary for setting the > local variable "has_local_sig" within the method > ConstantPoolCacheEntry::set_method_handle_common().? I have removed > CallInfo::_has_local_sig. > ConstantPoolCacheEntry::has_local_signature_shift is still necessary, > however. > > Updated webrev at: > http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.3/webrev/ This looks great! Thanks! Coleen > > Thanks for your review and help with this! > Lois > >> >> It's not always true. >> >>> >>> Perhaps there's a future use? >>> >>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/oops/cpCache.hpp.udiff.html >>> >>> >>> + has_local_signature_shift = 25, // (M) does the call site have a >>> per-site signature (sig-poly methods)? >>> >>> >>> Can you make this an "S" vs. "M" and change the coment in the top of >>> cpCache.hpp: >>> >>> // _flags???? [tos|0|F=0|M|A|I|f|0|vf|indy_rf|000|00000|psize] (for >>> method entries) >>> // bit length [ 4 |1| 1 |1|1|1|1|1|1 |-4--|--8--|--8--] >> >> Done, changed the "M" to "S" in both places.? The comment in the top >> of cpCache.hpp does not refer to the method_type in any form, so >> unclear as to how you want me to change it?? I am assuming you want >> me to remove the "method_type info (t_section) from this comment? >> >> // _flags?? = method type info (t section), >> //??????????? virtual final bit (vfinal), >> >> >>> >>> And a line under this: >>> >>> // A????? = call site has an appendix argument (loaded from resolved >>> references) >> >> Not sure what you mean by this? >> >> Thanks, >> Lois >> >>> >>> Although I don't like this comment because it gets out of date. >>> >>> Thanks, >>> Coleen >>> >>> On 2/4/19 7:32 AM, Lois Foltan wrote: >>>> Please review this change that removes the unused method_type field >>>> associated with the appendix field of an indy or method handle >>>> call.? This is the first of a series of changes working towards >>>> JDK-8210685: Bootstrap method consolidation. >>>> >>>> open webrev at: >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ >>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 >>>> co-contributors: Lois Foltan & John Rose >>>> >>>> Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 >>>> (linux only), JCK vm & lang (linux only) >>>> >>>> Thanks, >>>> Lois >>> >> > From robbin.ehn at oracle.com Mon Feb 11 20:14:17 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 11 Feb 2019 21:14:17 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> Hi all, Updated of v2: Full: http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/full/ (open.changeset still two patches, e.g. if you look at interfaceSupport.inline.hpp it's patched twice) Inc: http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/inc/ Passes several hours more stress testing and t1-5, KS 24H stress still running. I did update alternative one also with Dan's feedback, and it also still passes stress tests and t1-5. I'll leave that unpublished since we are focusing on this version where we can get some simplifications. Thanks, Robbin On 2019-02-07 17:05, Robbin Ehn wrote: > Hi all, here is the promised re-base (v06) on > 8210832: Remove sneaky locking in class Monitor. > > v06_1 is just a straight re-base. > > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ > Inc: > http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ > > Passes stress test and t1-5. > > But there is a 'better' way. > Before I added the more graceful "_vm_wait->wait();" semaphore in the while > (_waiting_to_block > 0) { loop, it was a just a busy spin using the same > back-off as the rolling forward loop. It turns out that we mostly never spin > here at all, when all java threads are stop the callbacks is often already done. > So the addition of the semaphore have no impact on our benchmarks and is mostly > unused. This is because most threads are in java which we need to spin-wait > since they can elide into native without doing a callback. My proposed re-base > removes the the callbacks completely and let the vm thread do all thread > accounting. All that the stopping threads needs to do is write state and > safepoint id, everything else is handle by the vm thread. We trade 2 atomics + > a local store per thread against doing 2 stores per thread by the vm thread. > This makes it possible for a thread in vm to transition into blocked WITHOUT > safepoint poll. Just set thread_blocked and promise to do safepoint poll when > leaving that state. > > v06_2 > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ > Inc against v05: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ > Inc against v06_1: > http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ > > v06_2 simplifies and removes ~200 LOC with same performance. > If there is a case with a thread in vm taking long time, it will already > screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I > see no reason why we should not push v06_2. > > Passes stress test and t1-5. > > Thanks, Robbin > > > On 1/15/19 11:39 AM, Robbin Ehn wrote: >> Hi all, please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >> >> Thanks to Dan for pre-reviewing a lot! >> >> Background: >> ZGC often does very short safepoint operations. For a perspective, in a >> specJBB2015 run, G1 can have young collection stops lasting about 170 ms. While >> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >> operation it is. The time it takes to stop and start the JavaThreads is relative >> very large to a ZGC safepoint. With an operation that just takes 0.2ms the >> overhead of stopping and starting JavaThreads is several times the operation. >> >> High-level functionality change: >> Serializing the starting over Threads_lock takes time. >> - Don't wait on Threads_lock use the WaitBarrier. >> Serializing the stopping over Safepoint_lock takes time. >> - Let threads stop in parallel, remove Safepoint_lock. >> >> Details: >> JavaThreads have 2 abstract logical states: unsafe or safe. >> - Safe means the JavaThread will not touch Java heap or VM internal structures >> ?? without doing a transition and block before doing so. >> ???????? - The safe states are: >> ???????????????? - When polls armed: _thread_in_native and _thread_blocked. >> ???????????????? - When Threads_lock is held: externally suspended flag is set. >> ???????? - VM Thread have polls armed and holds the Threads_lock during a >> ?????????? safepoint. >> - Unsafe means that either Java heap or VM internal structures can be accessed >> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >> ???????? - All combination that are not safe are unsafe. >> >> We cannot start a safepoint until all unsafe threads have transitioned to a safe >> state. To make them safe, we arm polls in compiled code and make sure any >> transition to another unsafe state will be blocked. JavaThreads which are unsafe >> with state _thread_in_Java may transition to _thread_in_native without being >> blocked, since it just became a safe thread and we can proceed. Any safe thread >> may try to transition at any time to an unsafe state, thus coming into the >> safepoint blocking code at any moment, e.g., after the safepoint is over, or >> even at the beginning of next safepoint. >> >> The VMThread cannot tolerate false positives from the JavaThread thread state >> because that would mean starting the safepoint without all JavaThreads being >> safe. The two locks (Threads_lock and Safepoint_lock) make sure we never observe >> false positives from the safepoint blocking code, if we remove them, how do we >> handle false positives? >> >> By first publishing which barrier tag (safepoint counter) we will call >> WaitBarrier.wait() with as the threads safepoint id and then change the state to >> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of >> the state. A stable load of the thread state is successful if the thread >> safepoint id is the same both before and after the load of the state and >> safepoint id is current or InactiveSafepointCounter. If the stable load fails, >> the thread is considered safepoint unsafe. It's no longer enough that thread is >> have state _thread_blocked it must also have correct safepoint id before and >> after we read the state. >> >> Performance: >> The result of faster safepoints is that the average CPU time for JavaThreads >> between safepoints is higher, thus increasing the allocation rate. The thread >> that stops first waits shorter time until it gets started. Even the thread that >> stops last also have shorter stop since we start them faster. If your >> application is using a concurrent GC it may need re-tunning since each java >> worker thread have an increased CPU time/allocation rate. Often this means max >> performance is achieved using slightly less java worker threads than before. >> Also the increase allocation rate means shorter time between GC safepoints. >> - If you are using a non-concurrent GC, you should see improved latency and >> ?? throughput. >> - After re-tunning with a concurrent GC throughput should be equal or better but >> ?? with better latency. But bear in mind this is a latency patch, not a >> ?? throughput one. >> With current code a java thread is not to guarantee to run between safepoint (in >> theory a java thread can be starved indefinitely), since the VM thread may >> re-grab the Threads_locks before it woke up from previous safepoint. If the >> GC/VM don't respect MMU (minimum mutator utilization) or if your machine is very >> over-provisioned this can happen. >> The current schema thus re-safepoint quickly if the java threads have not >> started yet at the cost of latency. Since the new code uses the WaitBarrier with >> the safepoint counter, all threads must roll forward to next safepoint by >> getting at least some CPU time between two safepoints. Meaning MMU violations >> are more obvious. >> >> Some examples on numbers: >> - On a 16 strand machine synchronization and un-synchronization/starting is at >> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and >> ?? starting ~400->~100us. >> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). >> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >> ?? synchronization time on 16 strands and ~5% score increase. In this case the GC >> ?? op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. >> - specJBB2015 ParGC ~9% increase in critical-jops. >> >> Thanks, Robbin From david.holmes at oracle.com Mon Feb 11 21:24:45 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2019 07:24:45 +1000 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: Message-ID: <41cc2d64-538d-65ab-5777-968594b08800@oracle.com> On 11/02/2019 7:02 pm, Robbin Ehn wrote: > Hi David, > > On 2/11/19 2:24 AM, David Holmes wrote: >> This makes it impossible to use the changeset to search through to >> check out how things are being used. In particular in this case there >> doesn't seem to be a need for the >> SafepointSynchronize::increment_jni_active_count() function because >> its only used by the VMThread now from within the other safepoint code. >> > > We sorted this out in other channel, it's a webrev bug (or miss-feature). Okay. I applied your patch and regenerated a clean webrev here in case anyone else would like to see it: http://cr.openjdk.java.net/~dholmes/8203469/webrev.v06_2/ I'll take another look through this morning. David ----- >> More below ... >>> But there is a 'better' way. >>> Before I added the more graceful "_vm_wait->wait();" semaphore in the >>> while >>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >> >> I think I've lost track of the changes here. Initially we waited on >> the _safepoint_lock; then in preview_13 we switched to polling with >> backoff. Not sure when _vm_wait->wait was introduced but we're now >> returning to polling with backoff. Is that right? > > Yes. > >> >> Once the VMThread polls until all threads are known to be >> safepoint-safe we eliminate a whole category of race conditions with >> the thread-state changes that allows us to simplify those thread-state >> changes. > > Yes. > >> >>> back-off as the rolling forward loop. It turns out that we mostly >>> never spin >>> here at all, when all java threads are stop the callbacks is often >>> already done. >>> So the addition of the semaphore have no impact on our benchmarks and >>> is mostly >>> unused. This is because most threads are in java which we need to >>> spin-wait >>> since they can elide into native without doing a callback. My >>> proposed re-base >>> removes the the callbacks completely and let the vm thread do all thread >>> accounting. All that the stopping threads needs to do is write state and >>> safepoint id, everything else is handle by the vm thread. We trade 2 >>> atomics + >>> a local store per thread against doing 2 stores per thread by the vm >>> thread. >>> This makes it possible for a thread in vm to transition into blocked >>> WITHOUT >>> safepoint poll. Just set thread_blocked and promise to do safepoint >>> poll when >>> leaving that state. >> >> Right - but you've only implemented that for the new >> ThreadBlockInVMWithDeadlockCheck, though the same argument applies to >> the regular TBIVM. We can/should re-examine TBIVM logic, and see if we >> can simplify and combine with new ThreadBlockInVMWithDeadlockCheck. >> Future RFE. > > Yes! > >> >> Aside: from a safepoint perspective I really don't see any difference >> between going out to "native" and going out to a (potentially) >> "blocking" library call. There are both safepoint-safe and should have >> the same requirements as you exit and enter the VM. > > Yes. > >> >>> v06_2 >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>> Inc against v05: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>> Inc against v06_1: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>> >>> v06_2 simplifies and removes ~200 LOC with same performance. >>> If there is a case with a thread in vm taking long time, it will already >>> screw-up latency and thus should be fixed regardless of v06_1 vs >>> v06_2. So I >>> see no reason why we should not push v06_2. >> >> src/hotspot/share/runtime/interfaceSupport.inline.hpp >> >> 317???? thread->set_thread_state((JavaThreadState)(_thread_in_vm + 1)); >> >> Should use _thread_in_vm_trans >> >> 326???? _thread->set_thread_state((JavaThreadState)(_thread_blocked + >> 1)); >> >> Should use _thread_blocked_trans > > Yes. > >> >> That said, I'm unclear what role the trans states now play here. >> Originally the VMThread had to spin when it saw a trans state because >> the final state would determine how the VMThread needed to respond >> next. But with the VMThread always spinning I don't see that we >> necessarily need the additional complexity. Anyway that too could be >> looked at later. > > Yes. Part of the bigger plan is to simplify the states. > If we ignore the trace_flag (suspend/resume, async exception,..) we > could now just have two states, safe and unsafe and you only need to > safepoint poll when going to a safe state. > >> >> I'd like to take one more pass through the full changeset once it has >> been generated correctly. > > Thanks, Robbin > >> >> Thanks, >> David >> >>> Passes stress test and t1-5. >>> >>> Thanks, Robbin From david.holmes at oracle.com Mon Feb 11 21:28:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2019 07:28:50 +1000 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> References: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> Message-ID: <78b0d148-e1fc-7700-c25f-836d5bb38465@oracle.com> On 12/02/2019 6:14 am, Robbin Ehn wrote: > Hi all, > > Updated of v2: > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/full/ > (open.changeset still two patches, e.g. if you look at > interfaceSupport.inline.hpp it's patched twice) Simplified version: http://cr.openjdk.java.net/~dholmes/8203469/webrev.v06_2_u1/ David ----- > Inc: > http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/inc/ > > Passes several hours more stress testing and t1-5, KS 24H stress still > running. > > I did update alternative one also with Dan's feedback, and it also still > passes stress tests and t1-5. > I'll leave that unpublished since we are focusing on this version where > we can get some simplifications. > > Thanks, Robbin > > On 2019-02-07 17:05, Robbin Ehn wrote: >> Hi all, here is the promised re-base (v06) on >> 8210832: Remove sneaky locking in class Monitor. >> >> v06_1 is just a straight re-base. >> >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >> Inc: >> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >> >> Passes stress test and t1-5. >> >> But there is a 'better' way. >> Before I added the more graceful "_vm_wait->wait();" semaphore in the >> while >> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >> back-off as the rolling forward loop. It turns out that we mostly >> never spin >> here at all, when all java threads are stop the callbacks is often >> already done. >> So the addition of the semaphore have no impact on our benchmarks and >> is mostly >> unused. This is because most threads are in java which we need to >> spin-wait >> since they can elide into native without doing a callback. My proposed >> re-base >> removes the the callbacks completely and let the vm thread do all thread >> accounting. All that the stopping threads needs to do is write state and >> safepoint id, everything else is handle by the vm thread. We trade 2 >> atomics + >> a local store per thread against doing 2 stores per thread by the vm >> thread. >> This makes it possible for a thread in vm to transition into blocked >> WITHOUT >> safepoint poll. Just set thread_blocked and promise to do safepoint >> poll when >> leaving that state. >> >> v06_2 >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >> Inc against v05: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >> Inc against v06_1: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >> >> v06_2 simplifies and removes ~200 LOC with same performance. >> If there is a case with a thread in vm taking long time, it will already >> screw-up latency and thus should be fixed regardless of v06_1 vs >> v06_2. So I >> see no reason why we should not push v06_2. >> >> Passes stress test and t1-5. >> >> Thanks, Robbin >> >> >> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>> Hi all, please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>> >>> Thanks to Dan for pre-reviewing a lot! >>> >>> Background: >>> ZGC often does very short safepoint operations. For a perspective, in a >>> specJBB2015 run, G1 can have young collection stops lasting about 170 >>> ms. While >>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >>> operation it is. The time it takes to stop and start the JavaThreads >>> is relative >>> very large to a ZGC safepoint. With an operation that just takes >>> 0.2ms the >>> overhead of stopping and starting JavaThreads is several times the >>> operation. >>> >>> High-level functionality change: >>> Serializing the starting over Threads_lock takes time. >>> - Don't wait on Threads_lock use the WaitBarrier. >>> Serializing the stopping over Safepoint_lock takes time. >>> - Let threads stop in parallel, remove Safepoint_lock. >>> >>> Details: >>> JavaThreads have 2 abstract logical states: unsafe or safe. >>> - Safe means the JavaThread will not touch Java heap or VM internal >>> structures >>> ?? without doing a transition and block before doing so. >>> ???????? - The safe states are: >>> ???????????????? - When polls armed: _thread_in_native and >>> _thread_blocked. >>> ???????????????? - When Threads_lock is held: externally suspended >>> flag is set. >>> ???????? - VM Thread have polls armed and holds the Threads_lock >>> during a >>> ?????????? safepoint. >>> - Unsafe means that either Java heap or VM internal structures can be >>> accessed >>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>> ???????? - All combination that are not safe are unsafe. >>> >>> We cannot start a safepoint until all unsafe threads have >>> transitioned to a safe >>> state. To make them safe, we arm polls in compiled code and make sure >>> any >>> transition to another unsafe state will be blocked. JavaThreads which >>> are unsafe >>> with state _thread_in_Java may transition to _thread_in_native >>> without being >>> blocked, since it just became a safe thread and we can proceed. Any >>> safe thread >>> may try to transition at any time to an unsafe state, thus coming >>> into the >>> safepoint blocking code at any moment, e.g., after the safepoint is >>> over, or >>> even at the beginning of next safepoint. >>> >>> The VMThread cannot tolerate false positives from the JavaThread >>> thread state >>> because that would mean starting the safepoint without all >>> JavaThreads being >>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >>> never observe >>> false positives from the safepoint blocking code, if we remove them, >>> how do we >>> handle false positives? >>> >>> By first publishing which barrier tag (safepoint counter) we will call >>> WaitBarrier.wait() with as the threads safepoint id and then change >>> the state to >>> _thread_blocked, the VMThread can ignore JavaThreads by doing a >>> stable load of >>> the state. A stable load of the thread state is successful if the thread >>> safepoint id is the same both before and after the load of the state and >>> safepoint id is current or InactiveSafepointCounter. If the stable >>> load fails, >>> the thread is considered safepoint unsafe. It's no longer enough that >>> thread is >>> have state _thread_blocked it must also have correct safepoint id >>> before and >>> after we read the state. >>> >>> Performance: >>> The result of faster safepoints is that the average CPU time for >>> JavaThreads >>> between safepoints is higher, thus increasing the allocation rate. >>> The thread >>> that stops first waits shorter time until it gets started. Even the >>> thread that >>> stops last also have shorter stop since we start them faster. If your >>> application is using a concurrent GC it may need re-tunning since >>> each java >>> worker thread have an increased CPU time/allocation rate. Often this >>> means max >>> performance is achieved using slightly less java worker threads than >>> before. >>> Also the increase allocation rate means shorter time between GC >>> safepoints. >>> - If you are using a non-concurrent GC, you should see improved >>> latency and >>> ?? throughput. >>> - After re-tunning with a concurrent GC throughput should be equal or >>> better but >>> ?? with better latency. But bear in mind this is a latency patch, not a >>> ?? throughput one. >>> With current code a java thread is not to guarantee to run between >>> safepoint (in >>> theory a java thread can be starved indefinitely), since the VM >>> thread may >>> re-grab the Threads_locks before it woke up from previous safepoint. >>> If the >>> GC/VM don't respect MMU (minimum mutator utilization) or if your >>> machine is very >>> over-provisioned this can happen. >>> The current schema thus re-safepoint quickly if the java threads have >>> not >>> started yet at the cost of latency. Since the new code uses the >>> WaitBarrier with >>> the safepoint counter, all threads must roll forward to next >>> safepoint by >>> getting at least some CPU time between two safepoints. Meaning MMU >>> violations >>> are more obvious. >>> >>> Some examples on numbers: >>> - On a 16 strand machine synchronization and >>> un-synchronization/starting is at >>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >>> ~100us and >>> ?? starting ~400->~100us. >>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >>> Linux). >>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>> ?? synchronization time on 16 strands and ~5% score increase. In this >>> case the GC >>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% >>> to 10%. >>> - specJBB2015 ParGC ~9% increase in critical-jops. >>> >>> Thanks, Robbin From lois.foltan at oracle.com Mon Feb 11 22:47:39 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 11 Feb 2019 17:47:39 -0500 Subject: JDK-8217998: Remove method_type field associated with the appendix field of an indy or method handle call In-Reply-To: <9f3e1ee6-d133-1601-3849-5cef40541e59@oracle.com> References: <55957964-5eab-6467-6ea9-bfd1bf6e33e0@oracle.com> <8b074f18-078f-99d1-906d-cae57cc87ef5@oracle.com> <9f3e1ee6-d133-1601-3849-5cef40541e59@oracle.com> Message-ID: <22a567d5-d085-29f9-0980-fd2eaa5142e0@oracle.com> On 2/11/2019 2:58 PM, coleen.phillimore at oracle.com wrote: > > > On 2/11/19 2:16 PM, Lois Foltan wrote: >> >> >> On 2/6/2019 3:34 PM, Lois Foltan wrote: >>> >>> On 2/5/2019 6:01 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> Hi Lois,? I like that there are no longer two resolved references >>>> for indy instructions, especially if it wasn't used. >>> >>> Thanks Coleen for the review!? More below. >>> >>>> >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/interpreter/linkResolver.cpp.udiff.html >>>> >>>> >>>> I can't find a call where set_handle() passes false for the >>>> _has_local_sig field. >>> >>> There is no call to set_handle() that passes false for the >>> _has_local_sig field.? It is set to false initially in >>> CallInfo::set_common.? I considered not passing the "has_local_sig" >>> parameter to set_handle and just always set CallInfo::_has_local_sig >>> to true within that method but I am assuming John wanted to allow >>> for the possibility that it could be set to false in the future. >>> >>>> >>>> Can you rename CallInfo::_has_local_signature, since it's not that >>>> much longer and reads better? >>>> >>>> + const bool has_local_sig = call_info.has_local_signature(); >>>> + assert(has_local_sig, "MHs and indy are always sig-poly"); >>> >>> I'm confused.? The field currently within CallInfo is named >>> CallInfo::_has_local_sig.? Are you referring to the method >>> CallInfo::has_local_signature()?? Do you want that shortened? >>> >>>> >>>> So why do you need this field if it's always true?? Was hoping for >>>> a cpCache bit back :) >> >> Hi Coleen, >> >> I looked over your review comments again and you are correct >> concerning the need for CallInfo::_has_local_sig.? It is always set >> to true for MHs and indy and thus really is not necessary for setting >> the local variable "has_local_sig" within the method >> ConstantPoolCacheEntry::set_method_handle_common().? I have removed >> CallInfo::_has_local_sig. >> ConstantPoolCacheEntry::has_local_signature_shift is still necessary, >> however. >> >> Updated webrev at: >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.3/webrev/ > > This looks great! > Thanks! > Coleen Thanks Coleen for another review of it! Lois > >> >> Thanks for your review and help with this! >> Lois >> >>> >>> It's not always true. >>> >>>> >>>> Perhaps there's a future use? >>>> >>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.2/webrev/src/hotspot/share/oops/cpCache.hpp.udiff.html >>>> >>>> >>>> + has_local_signature_shift = 25, // (M) does the call site have a >>>> per-site signature (sig-poly methods)? >>>> >>>> >>>> Can you make this an "S" vs. "M" and change the coment in the top >>>> of cpCache.hpp: >>>> >>>> // _flags [tos|0|F=0|M|A|I|f|0|vf|indy_rf|000|00000|psize] (for >>>> method entries) >>>> // bit length [ 4 |1| 1 |1|1|1|1|1|1 |-4--|--8--|--8--] >>> >>> Done, changed the "M" to "S" in both places.? The comment in the top >>> of cpCache.hpp does not refer to the method_type in any form, so >>> unclear as to how you want me to change it?? I am assuming you want >>> me to remove the "method_type info (t_section) from this comment? >>> >>> // _flags?? = method type info (t section), >>> //??????????? virtual final bit (vfinal), >>> >>> >>>> >>>> And a line under this: >>>> >>>> // A????? = call site has an appendix argument (loaded from >>>> resolved references) >>> >>> Not sure what you mean by this? >>> >>> Thanks, >>> Lois >>> >>>> >>>> Although I don't like this comment because it gets out of date. >>>> >>>> Thanks, >>>> Coleen >>>> >>>> On 2/4/19 7:32 AM, Lois Foltan wrote: >>>>> Please review this change that removes the unused method_type >>>>> field associated with the appendix field of an indy or method >>>>> handle call.? This is the first of a series of changes working >>>>> towards JDK-8210685: Bootstrap method consolidation. >>>>> >>>>> open webrev at: >>>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8217998.1/webrev/ >>>>> bug link: https://bugs.openjdk.java.net/browse/JDK-8217998 >>>>> co-contributors: Lois Foltan & John Rose >>>>> >>>>> Testing: hs-tier1-4 & jdk-tier1-3 (all platforms), hs-tier5-8 >>>>> (linux only), JCK vm & lang (linux only) >>>>> >>>>> Thanks, >>>>> Lois >>>> >>> >> > From matthias.baesken at sap.com Tue Feb 12 09:17:15 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 12 Feb 2019 09:17:15 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Message-ID: Hi Ioi / Kim I created https://bugs.openjdk.java.net/browse/JDK-8218811 8218811: replace open by os::open in hotspot coding > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > For functions which should never be called outside the implementation of the os replacement, we can use (for example) > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > __attribute__((__deprecated__("use os::vsnprintf"))); > > and in the definition of os::vsnprintf, locally disable the deprecation warning with the appropriate diagnostic #pragma. Should I add something like this for open to compilerWarnings.hpp ? I think if yes, I better restrict this for now to gcc . Best regards, Matthias > > Message: 4 > Date: Thu, 7 Feb 2019 12:40:00 -0500 > From: Kim Barrett > To: Ioi Lam > Cc: hotspot-dev developers > Subject: Re: open-calls in hotspot code instead of os::open ? > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > Content-Type: text/plain; charset=us-ascii > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam wrote: > > > > I think this should be fixed. > > +1 > > > BTW, is there a way to forbid all the calls to ::open()? > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > From david.holmes at oracle.com Tue Feb 12 12:38:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2019 22:38:22 +1000 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: <78b0d148-e1fc-7700-c25f-836d5bb38465@oracle.com> References: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> <78b0d148-e1fc-7700-c25f-836d5bb38465@oracle.com> Message-ID: Hi Robbin, I've gone through v06_2_u1 one more time and overall I think things generally look good. One or two nits on naming but nothing worth haggling over :) Thanks, David On 12/02/2019 7:28 am, David Holmes wrote: > On 12/02/2019 6:14 am, Robbin Ehn wrote: >> Hi all, >> >> Updated of v2: >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/full/ >> (open.changeset still two patches, e.g. if you look at >> interfaceSupport.inline.hpp it's patched twice) > > Simplified version: > > http://cr.openjdk.java.net/~dholmes/8203469/webrev.v06_2_u1/ > > David > ----- > >> Inc: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/inc/ >> >> Passes several hours more stress testing and t1-5, KS 24H stress still >> running. >> >> I did update alternative one also with Dan's feedback, and it also >> still passes stress tests and t1-5. >> I'll leave that unpublished since we are focusing on this version >> where we can get some simplifications. >> >> Thanks, Robbin >> >> On 2019-02-07 17:05, Robbin Ehn wrote: >>> Hi all, here is the promised re-base (v06) on >>> 8210832: Remove sneaky locking in class Monitor. >>> >>> v06_1 is just a straight re-base. >>> >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >>> Inc: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >>> >>> Passes stress test and t1-5. >>> >>> But there is a 'better' way. >>> Before I added the more graceful "_vm_wait->wait();" semaphore in the >>> while >>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >>> back-off as the rolling forward loop. It turns out that we mostly >>> never spin >>> here at all, when all java threads are stop the callbacks is often >>> already done. >>> So the addition of the semaphore have no impact on our benchmarks and >>> is mostly >>> unused. This is because most threads are in java which we need to >>> spin-wait >>> since they can elide into native without doing a callback. My >>> proposed re-base >>> removes the the callbacks completely and let the vm thread do all thread >>> accounting. All that the stopping threads needs to do is write state and >>> safepoint id, everything else is handle by the vm thread. We trade 2 >>> atomics + >>> a local store per thread against doing 2 stores per thread by the vm >>> thread. >>> This makes it possible for a thread in vm to transition into blocked >>> WITHOUT >>> safepoint poll. Just set thread_blocked and promise to do safepoint >>> poll when >>> leaving that state. >>> >>> v06_2 >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>> Inc against v05: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>> Inc against v06_1: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>> >>> v06_2 simplifies and removes ~200 LOC with same performance. >>> If there is a case with a thread in vm taking long time, it will already >>> screw-up latency and thus should be fixed regardless of v06_1 vs >>> v06_2. So I >>> see no reason why we should not push v06_2. >>> >>> Passes stress test and t1-5. >>> >>> Thanks, Robbin >>> >>> >>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>> Hi all, please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>> >>>> Thanks to Dan for pre-reviewing a lot! >>>> >>>> Background: >>>> ZGC often does very short safepoint operations. For a perspective, in a >>>> specJBB2015 run, G1 can have young collection stops lasting about >>>> 170 ms. While >>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on >>>> which >>>> operation it is. The time it takes to stop and start the JavaThreads >>>> is relative >>>> very large to a ZGC safepoint. With an operation that just takes >>>> 0.2ms the >>>> overhead of stopping and starting JavaThreads is several times the >>>> operation. >>>> >>>> High-level functionality change: >>>> Serializing the starting over Threads_lock takes time. >>>> - Don't wait on Threads_lock use the WaitBarrier. >>>> Serializing the stopping over Safepoint_lock takes time. >>>> - Let threads stop in parallel, remove Safepoint_lock. >>>> >>>> Details: >>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>> - Safe means the JavaThread will not touch Java heap or VM internal >>>> structures >>>> ?? without doing a transition and block before doing so. >>>> ???????? - The safe states are: >>>> ???????????????? - When polls armed: _thread_in_native and >>>> _thread_blocked. >>>> ???????????????? - When Threads_lock is held: externally suspended >>>> flag is set. >>>> ???????? - VM Thread have polls armed and holds the Threads_lock >>>> during a >>>> ?????????? safepoint. >>>> - Unsafe means that either Java heap or VM internal structures can >>>> be accessed >>>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>> ???????? - All combination that are not safe are unsafe. >>>> >>>> We cannot start a safepoint until all unsafe threads have >>>> transitioned to a safe >>>> state. To make them safe, we arm polls in compiled code and make >>>> sure any >>>> transition to another unsafe state will be blocked. JavaThreads >>>> which are unsafe >>>> with state _thread_in_Java may transition to _thread_in_native >>>> without being >>>> blocked, since it just became a safe thread and we can proceed. Any >>>> safe thread >>>> may try to transition at any time to an unsafe state, thus coming >>>> into the >>>> safepoint blocking code at any moment, e.g., after the safepoint is >>>> over, or >>>> even at the beginning of next safepoint. >>>> >>>> The VMThread cannot tolerate false positives from the JavaThread >>>> thread state >>>> because that would mean starting the safepoint without all >>>> JavaThreads being >>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >>>> never observe >>>> false positives from the safepoint blocking code, if we remove them, >>>> how do we >>>> handle false positives? >>>> >>>> By first publishing which barrier tag (safepoint counter) we will call >>>> WaitBarrier.wait() with as the threads safepoint id and then change >>>> the state to >>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a >>>> stable load of >>>> the state. A stable load of the thread state is successful if the >>>> thread >>>> safepoint id is the same both before and after the load of the state >>>> and >>>> safepoint id is current or InactiveSafepointCounter. If the stable >>>> load fails, >>>> the thread is considered safepoint unsafe. It's no longer enough >>>> that thread is >>>> have state _thread_blocked it must also have correct safepoint id >>>> before and >>>> after we read the state. >>>> >>>> Performance: >>>> The result of faster safepoints is that the average CPU time for >>>> JavaThreads >>>> between safepoints is higher, thus increasing the allocation rate. >>>> The thread >>>> that stops first waits shorter time until it gets started. Even the >>>> thread that >>>> stops last also have shorter stop since we start them faster. If your >>>> application is using a concurrent GC it may need re-tunning since >>>> each java >>>> worker thread have an increased CPU time/allocation rate. Often this >>>> means max >>>> performance is achieved using slightly less java worker threads than >>>> before. >>>> Also the increase allocation rate means shorter time between GC >>>> safepoints. >>>> - If you are using a non-concurrent GC, you should see improved >>>> latency and >>>> ?? throughput. >>>> - After re-tunning with a concurrent GC throughput should be equal >>>> or better but >>>> ?? with better latency. But bear in mind this is a latency patch, not a >>>> ?? throughput one. >>>> With current code a java thread is not to guarantee to run between >>>> safepoint (in >>>> theory a java thread can be starved indefinitely), since the VM >>>> thread may >>>> re-grab the Threads_locks before it woke up from previous safepoint. >>>> If the >>>> GC/VM don't respect MMU (minimum mutator utilization) or if your >>>> machine is very >>>> over-provisioned this can happen. >>>> The current schema thus re-safepoint quickly if the java threads >>>> have not >>>> started yet at the cost of latency. Since the new code uses the >>>> WaitBarrier with >>>> the safepoint counter, all threads must roll forward to next >>>> safepoint by >>>> getting at least some CPU time between two safepoints. Meaning MMU >>>> violations >>>> are more obvious. >>>> >>>> Some examples on numbers: >>>> - On a 16 strand machine synchronization and >>>> un-synchronization/starting is at >>>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >>>> ~100us and >>>> ?? starting ~400->~100us. >>>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >>>> Linux). >>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>> ?? synchronization time on 16 strands and ~5% score increase. In >>>> this case the GC >>>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% >>>> to 10%. >>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>> >>>> Thanks, Robbin From robbin.ehn at oracle.com Tue Feb 12 12:39:21 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 12 Feb 2019 13:39:21 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> <78b0d148-e1fc-7700-c25f-836d5bb38465@oracle.com> Message-ID: <3a02757f-4388-1352-0e3a-2cff07dca98d@oracle.com> Hi David, On 2/12/19 1:38 PM, David Holmes wrote: > Hi Robbin, > > I've gone through v06_2_u1 one more time and overall I think things generally > look good. > > One or two nits on naming but nothing worth haggling over :) Thank you! /Robbin > > Thanks, > David > > On 12/02/2019 7:28 am, David Holmes wrote: >> On 12/02/2019 6:14 am, Robbin Ehn wrote: >>> Hi all, >>> >>> Updated of v2: >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/full/ >>> (open.changeset still two patches, e.g. if you look at >>> interfaceSupport.inline.hpp it's patched twice) >> >> Simplified version: >> >> http://cr.openjdk.java.net/~dholmes/8203469/webrev.v06_2_u1/ >> >> David >> ----- >> >>> Inc: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/inc/ >>> >>> Passes several hours more stress testing and t1-5, KS 24H stress still running. >>> >>> I did update alternative one also with Dan's feedback, and it also still >>> passes stress tests and t1-5. >>> I'll leave that unpublished since we are focusing on this version where we >>> can get some simplifications. >>> >>> Thanks, Robbin >>> >>> On 2019-02-07 17:05, Robbin Ehn wrote: >>>> Hi all, here is the promised re-base (v06) on >>>> 8210832: Remove sneaky locking in class Monitor. >>>> >>>> v06_1 is just a straight re-base. >>>> >>>> Full: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >>>> Inc: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >>>> >>>> Passes stress test and t1-5. >>>> >>>> But there is a 'better' way. >>>> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >>>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >>>> back-off as the rolling forward loop. It turns out that we mostly never spin >>>> here at all, when all java threads are stop the callbacks is often already >>>> done. >>>> So the addition of the semaphore have no impact on our benchmarks and is mostly >>>> unused. This is because most threads are in java which we need to spin-wait >>>> since they can elide into native without doing a callback. My proposed re-base >>>> removes the the callbacks completely and let the vm thread do all thread >>>> accounting. All that the stopping threads needs to do is write state and >>>> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >>>> a local store per thread against doing 2 stores per thread by the vm thread. >>>> This makes it possible for a thread in vm to transition into blocked WITHOUT >>>> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >>>> leaving that state. >>>> >>>> v06_2 >>>> Full: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>>> Inc against v05: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>>> Inc against v06_1: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>>> >>>> v06_2 simplifies and removes ~200 LOC with same performance. >>>> If there is a case with a thread in vm taking long time, it will already >>>> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >>>> see no reason why we should not push v06_2. >>>> >>>> Passes stress test and t1-5. >>>> >>>> Thanks, Robbin >>>> >>>> >>>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>>> Hi all, please review. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>>> >>>>> Thanks to Dan for pre-reviewing a lot! >>>>> >>>>> Background: >>>>> ZGC often does very short safepoint operations. For a perspective, in a >>>>> specJBB2015 run, G1 can have young collection stops lasting about 170 ms. >>>>> While >>>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >>>>> operation it is. The time it takes to stop and start the JavaThreads is >>>>> relative >>>>> very large to a ZGC safepoint. With an operation that just takes 0.2ms the >>>>> overhead of stopping and starting JavaThreads is several times the operation. >>>>> >>>>> High-level functionality change: >>>>> Serializing the starting over Threads_lock takes time. >>>>> - Don't wait on Threads_lock use the WaitBarrier. >>>>> Serializing the stopping over Safepoint_lock takes time. >>>>> - Let threads stop in parallel, remove Safepoint_lock. >>>>> >>>>> Details: >>>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>>> - Safe means the JavaThread will not touch Java heap or VM internal structures >>>>> ?? without doing a transition and block before doing so. >>>>> ???????? - The safe states are: >>>>> ???????????????? - When polls armed: _thread_in_native and _thread_blocked. >>>>> ???????????????? - When Threads_lock is held: externally suspended flag is >>>>> set. >>>>> ???????? - VM Thread have polls armed and holds the Threads_lock during a >>>>> ?????????? safepoint. >>>>> - Unsafe means that either Java heap or VM internal structures can be accessed >>>>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>>> ???????? - All combination that are not safe are unsafe. >>>>> >>>>> We cannot start a safepoint until all unsafe threads have transitioned to a >>>>> safe >>>>> state. To make them safe, we arm polls in compiled code and make sure any >>>>> transition to another unsafe state will be blocked. JavaThreads which are >>>>> unsafe >>>>> with state _thread_in_Java may transition to _thread_in_native without being >>>>> blocked, since it just became a safe thread and we can proceed. Any safe >>>>> thread >>>>> may try to transition at any time to an unsafe state, thus coming into the >>>>> safepoint blocking code at any moment, e.g., after the safepoint is over, or >>>>> even at the beginning of next safepoint. >>>>> >>>>> The VMThread cannot tolerate false positives from the JavaThread thread state >>>>> because that would mean starting the safepoint without all JavaThreads being >>>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we never >>>>> observe >>>>> false positives from the safepoint blocking code, if we remove them, how do we >>>>> handle false positives? >>>>> >>>>> By first publishing which barrier tag (safepoint counter) we will call >>>>> WaitBarrier.wait() with as the threads safepoint id and then change the >>>>> state to >>>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of >>>>> the state. A stable load of the thread state is successful if the thread >>>>> safepoint id is the same both before and after the load of the state and >>>>> safepoint id is current or InactiveSafepointCounter. If the stable load fails, >>>>> the thread is considered safepoint unsafe. It's no longer enough that >>>>> thread is >>>>> have state _thread_blocked it must also have correct safepoint id before and >>>>> after we read the state. >>>>> >>>>> Performance: >>>>> The result of faster safepoints is that the average CPU time for JavaThreads >>>>> between safepoints is higher, thus increasing the allocation rate. The thread >>>>> that stops first waits shorter time until it gets started. Even the thread >>>>> that >>>>> stops last also have shorter stop since we start them faster. If your >>>>> application is using a concurrent GC it may need re-tunning since each java >>>>> worker thread have an increased CPU time/allocation rate. Often this means max >>>>> performance is achieved using slightly less java worker threads than before. >>>>> Also the increase allocation rate means shorter time between GC safepoints. >>>>> - If you are using a non-concurrent GC, you should see improved latency and >>>>> ?? throughput. >>>>> - After re-tunning with a concurrent GC throughput should be equal or >>>>> better but >>>>> ?? with better latency. But bear in mind this is a latency patch, not a >>>>> ?? throughput one. >>>>> With current code a java thread is not to guarantee to run between >>>>> safepoint (in >>>>> theory a java thread can be starved indefinitely), since the VM thread may >>>>> re-grab the Threads_locks before it woke up from previous safepoint. If the >>>>> GC/VM don't respect MMU (minimum mutator utilization) or if your machine is >>>>> very >>>>> over-provisioned this can happen. >>>>> The current schema thus re-safepoint quickly if the java threads have not >>>>> started yet at the cost of latency. Since the new code uses the WaitBarrier >>>>> with >>>>> the safepoint counter, all threads must roll forward to next safepoint by >>>>> getting at least some CPU time between two safepoints. Meaning MMU violations >>>>> are more obvious. >>>>> >>>>> Some examples on numbers: >>>>> - On a 16 strand machine synchronization and un-synchronization/starting is at >>>>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and >>>>> ?? starting ~400->~100us. >>>>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). >>>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>>> ?? synchronization time on 16 strands and ~5% score increase. In this case >>>>> the GC >>>>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. >>>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>>> >>>>> Thanks, Robbin From matthias.baesken at sap.com Tue Feb 12 16:18:49 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 12 Feb 2019 16:18:49 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: Hello, here is a first webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ https://bugs.openjdk.java.net/browse/JDK-8218811 The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 12. Februar 2019 10:17 > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > Subject: 8218811: replace open by os::open in hotspot coding - was : open- > calls in hotspot code instead of os::open ? > > Hi Ioi / Kim I created > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > 8218811: replace open by os::open in hotspot coding > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > For functions which should never be called outside the implementation of > the os replacement, we can use (for example) > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > and in the definition of os::vsnprintf, locally disable the deprecation > warning with the appropriate diagnostic #pragma. > > Should I add something like this for open to compilerWarnings.hpp ? > I think if yes, I better restrict this for now to gcc . > > > Best regards, Matthias > > > > > Message: 4 > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > From: Kim Barrett > > To: Ioi Lam > > Cc: hotspot-dev developers > > Subject: Re: open-calls in hotspot code instead of os::open ? > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > Content-Type: text/plain; charset=us-ascii > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam wrote: > > > > > > I think this should be fixed. > > > > +1 > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > From ioi.lam at oracle.com Tue Feb 12 16:23:57 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 12 Feb 2019 08:23:57 -0800 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: <612caa13-3968-af31-17d3-eb58a0346e7f@oracle.com> Hi Baesken, This looks good to me. I'll let Kim answer about the gcc warning part. Thanks - Ioi On 2/12/19 8:18 AM, Baesken, Matthias wrote: > Hello, here is a first webrev + bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , > Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? > > Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? > > > Best regards, Matthias > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Dienstag, 12. Februar 2019 10:17 >> To: hotspot-dev at openjdk.java.net; 'Kim Barrett' >> Subject: 8218811: replace open by os::open in hotspot coding - was : open- >> calls in hotspot code instead of os::open ? >> >> Hi Ioi / Kim I created >> >> https://bugs.openjdk.java.net/browse/JDK-8218811 >> >> 8218811: replace open by os::open in hotspot coding >> >>> Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 >>> >> Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 >> >> >>> For functions which should never be called outside the implementation of >> the os replacement, we can use (for example) >>> extern "C" int vsnprintf(char*, size_t, const char*, va_list) >>> __attribute__((__deprecated__("use os::vsnprintf"))); >>> >>> and in the definition of os::vsnprintf, locally disable the deprecation >> warning with the appropriate diagnostic #pragma. >> >> Should I add something like this for open to compilerWarnings.hpp ? >> I think if yes, I better restrict this for now to gcc . >> >> >> Best regards, Matthias >> >>> Message: 4 >>> Date: Thu, 7 Feb 2019 12:40:00 -0500 >>> From: Kim Barrett >>> To: Ioi Lam >>> Cc: hotspot-dev developers >>> Subject: Re: open-calls in hotspot code instead of os::open ? >>> Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> >>> Content-Type: text/plain; charset=us-ascii >>> >>>> On Feb 6, 2019, at 9:08 AM, Ioi Lam wrote: >>>> >>>> I think this should be fixed. >>> +1 >>> >>>> BTW, is there a way to forbid all the calls to ::open()? >>> Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 >>> >>> From kim.barrett at oracle.com Tue Feb 12 22:06:49 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 12 Feb 2019 17:06:49 -0500 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: <78374C6F-F25F-44AA-9502-02E3F0AD54AA@oracle.com> > On Feb 12, 2019, at 11:18 AM, Baesken, Matthias wrote: > > Hello, here is a first webrev + bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , > Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? I suggest not doing this ad hoc small piece of JDK-8214976, and instead wait for that RFE to be addressed. (Yeah, I know, it's presently unassigned. This has been coming up repeatedly recently though, and I'm hopeful that it will get worked on soonish.) > Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? Don?t know. ------------------------------------------------------------------------------ I was going to comment on some of the calls to os::open, but instead ended up filing a couple more RFEs: https://bugs.openjdk.java.net/browse/JDK-8218856 Improve os::open mode handling https://bugs.openjdk.java.net/browse/JDK-8218857 Confusing overloads for os::open ------------------------------------------------------------------------------ src/hotspot/os/linux/os_linux.cpp Why is this avoiding os::open? ------------------------------------------------------------------------------ src/hotspot/os/linux/perfMemory_linux.cpp 101 result);; Pre-existing extra semi-colon. ------------------------------------------------------------------------------ src/hotspot/os/linux/perfMemory_linux.cpp 100 RESTARTABLE(os::open(destfile, O_CREAT|O_WRONLY|O_TRUNC, S_IREAD|S_IWRITE), S_IREAD and S_IWRITE? According to the glibc manual, "S_IREAD is an obsolete synonym provided for BSD compatibility." and similarly for S_IWRITE. I think this should instead be the standard S_IRUSR|S_IWUSR. ------------------------------------------------------------------------------ src/hotspot/share/ci/ciEnv.cpp 1256 int fd = os::open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); ... 1274 int fd = os::open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); Pre-existing: I think it would be better to use the named mode values rather than a hard-coded literal. Similarly here: src/hotspot/share/memory/filemap.cpp 588 int fd = os::open(_full_path, O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0444); and here: src/hotspot/share/utilities/ostream.cpp 563 _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); and here: src/hotspot/share/utilities/vmError.cpp 1197 fd = os::open(buf, O_RDWR | O_CREAT | O_EXCL, 0666); Given how common the 0666 pattern is, maybe a named constant in os for that would be appropriate. ------------------------------------------------------------------------------ src/hotspot/share/utilities/compilerWarnings_gcc.hpp 39 #ifndef DISABLE_DEPRECATE_OPEN 40 // avoid open, use os::open 41 extern "C" int open(const char*, int, ...) __attribute__((__deprecated__("use os::open"))); 42 #endif src/hotspot/os/linux/os_linux.cpp 26 #define DISABLE_DEPRECATE_OPEN As mentioned above, I don't think this ought to be part of the change. Instead, fix the open calls in os_linux.cpp too. Also, this approach doesn't work with precompiled headers. I suspect the reasons for os_linux.cpp explicitly not using precompiled headers are historical. For example, it used to #define __STDC_FORMAT_MACROS. ------------------------------------------------------------------------------ From m.sundar85 at gmail.com Wed Feb 13 04:01:38 2019 From: m.sundar85 at gmail.com (Sundara Mohan M) Date: Tue, 12 Feb 2019 20:01:38 -0800 Subject: -Dsun.java.command is not updated in jps/jcmd In-Reply-To: References: Message-ID: Hi, I am trying to change the main class name (listed via jps) to be different from actual class name used. For example, I am starting a process as com.sundar.XmlConfig as my main class but in jps i want to see it as com.sundar.MyApplication. I tried passing -Dsun.java.command=com.sundar.MyApplication in command line like, java -Dsun.java.command=com.sundar.MyApplication com.sundar.XmlConfig but still it is showing XmlConfig in the jps output. Any idea how to solve this? Thanks, Sundar From david.holmes at oracle.com Wed Feb 13 04:37:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Feb 2019 14:37:39 +1000 Subject: -Dsun.java.command is not updated in jps/jcmd In-Reply-To: References: Message-ID: <13208228-7f41-4a42-ae1d-cc4a50721144@oracle.com> Hi Sundar, On 13/02/2019 2:01 pm, Sundara Mohan M wrote: > Hi, > I am trying to change the main class name (listed via jps) to be > different from actual class name used. > For example, > I am starting a process as com.sundar.XmlConfig as my main class but in > jps i want to see it as com.sundar.MyApplication. > I tried passing -Dsun.java.command=com.sundar.MyApplication in command line > like, > java -Dsun.java.command=com.sundar.MyApplication com.sundar.XmlConfig but > still it is showing XmlConfig in the jps output. > > > Any idea how to solve this? I don't think you can without a custom launcher. sun.java.command is not intended to be user-settable but is a psuedo-property used to communicate between the launcher and the JVM. In the case of the JDK's launcher it sets that property explicitly and appends it (and others) to the end of the explicit command-line args e.g if you set _JAVA_LAUNCHER_DEBUG=true you will see something like: JavaVM args: version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 6 option[ 0] = '-Dsun.java.launcher.diag=true' option[ 1] = '-Dsun.java.command=com.sundar.MyApplication' option[ 2] = '-Djava.class.path=.' option[ 3] = '-Dsun.java.command=com.sundar.XmlConfig' option[ 4] = '-Dsun.java.launcher=SUN_STANDARD' option[ 5] = '-Dsun.java.launcher.pid=26724' So your setting is then overridden by the launcher supplied setting when the JVM processes the args. Cheers, David > Thanks, > Sundar > From thomas.stuefe at gmail.com Wed Feb 13 09:40:42 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 13 Feb 2019 10:40:42 +0100 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: Hi Matthias, not a full review but please do not use os::open in error reporting: http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html We should use as little as possible VM functions here, since they may be broken and/or pull other VM dependencies which may be broken or introduce circularities. I am not sure if the same argument holds for other call sites as well. Best Regards, Thomas On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias wrote: > Hello, here is a first webrev + bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > The gcc deprecation attribute for open in > hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a > hack , > Maybe you have a better idea for disabling ( is there a good way to use a > pragma instead of the define ) ? > > Additionally I was not 100 % sure - are there maybe a few places where we > want to stay away from os::open for good reason ? > > > Best regards, Matthias > > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Dienstag, 12. Februar 2019 10:17 > > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : > open- > > calls in hotspot code instead of os::open ? > > > > Hi Ioi / Kim I created > > > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > > > 8218811: replace open by os::open in hotspot coding > > > > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > For functions which should never be called outside the implementation > of > > the os replacement, we can use (for example) > > > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > > > and in the definition of os::vsnprintf, locally disable the deprecation > > warning with the appropriate diagnostic #pragma. > > > > Should I add something like this for open to compilerWarnings.hpp ? > > I think if yes, I better restrict this for now to gcc . > > > > > > Best regards, Matthias > > > > > > > > Message: 4 > > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > > Content-Type: text/plain; charset=us-ascii > > > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam wrote: > > > > > > > > I think this should be fixed. > > > > > > +1 > > > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > > From matthias.baesken at sap.com Wed Feb 13 10:35:52 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 13 Feb 2019 10:35:52 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: Thanks for the feedback . Do you see any special issue with the os::open implementations that forbid usage in os::error ? Kim what do you think ? I found over 80 references to os::? calls in vmError.cpp so I think it is not generally a bad thing to do it (however for course there might be functions in the os:: layer that cause trouble in error reporting). New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation + vmError.cpp adjustment removed) http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ Best regards, Matthias From: Thomas St?fe Sent: Mittwoch, 13. Februar 2019 10:41 To: Baesken, Matthias Cc: hotspot-dev at openjdk.java.net; Kim Barrett Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, not a full review but please do not use os::open in error reporting: http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html We should use as little as possible VM functions here, since they may be broken and/or pull other VM dependencies which may be broken or introduce circularities. I am not sure if the same argument holds for other call sites as well. Best Regards, Thomas On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias > wrote: Hello, here is a first webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ https://bugs.openjdk.java.net/browse/JDK-8218811 The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 12. Februar 2019 10:17 > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : open- > calls in hotspot code instead of os::open ? > > Hi Ioi / Kim I created > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > 8218811: replace open by os::open in hotspot coding > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > For functions which should never be called outside the implementation of > the os replacement, we can use (for example) > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > and in the definition of os::vsnprintf, locally disable the deprecation > warning with the appropriate diagnostic #pragma. > > Should I add something like this for open to compilerWarnings.hpp ? > I think if yes, I better restrict this for now to gcc . > > > Best regards, Matthias > > > > > Message: 4 > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > Content-Type: text/plain; charset=us-ascii > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam > wrote: > > > > > > I think this should be fixed. > > > > +1 > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > From thomas.stuefe at gmail.com Wed Feb 13 11:42:37 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 13 Feb 2019 12:42:37 +0100 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: My problem with this change are potential re entrant calls which may cause crashes or deadlocks. In addition, there are dependencies on VM initialization order to consider. By wholesale exchanging open() with os::open(), you add dependencies to VM infrastructure at a lot of places where we did have none before. VM infrastructure which may not be reentrant and/or which may be dependent on VM initialization. Example: Lets say you crash in an os::open() function, enter error reporting, which calls the same os::open() function. Then you have a circularity where you may crash again or lock. Even if it works today: these things like to grow and bitrot. Today os::open is simple, tomorrow someone else could very well have the idea of adding hooks to os::open in the future to monitor, count, etc, and boom, you have new dependencies. Case in point is os::malloc() which used to be a harmless drop in malloc replacement and now is a Moloch which calls, among other things, into NMT. I think one has to look at every callsite in your change and determine if: - it runs the risk of being called recursively (e.g. anything triggered from signal handling, or a general purpose class like ostream) - it could theoretically be called before VM initialization or argument parsing, or after cleanup Some examples: -- src/hotspot/os/linux/os_linux.cpp - _print_ascii_file() is used during error reporting. - os::get_core_path() is used during error reporting. -- src/hotspot/share/runtime/arguments.cpp Arguments::parse_vm_options_file(const char* file_name, ScopedVMInitArgs* vm_args) initialization dependency here: this gets called before all VM options are parsed, therefore I would not use VM functions which may rely on VM options. -- src/hotspot/share/utilities/ostream.cpp fdStream::fdStream(const char* file_name) { - _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); + _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); _need_close = true; } fdStream is a general purpose class and used in a lot of places, including os::abort and error reporting, so I would be against this change. However, this constructor variant is called from nowhere: I would scratch this constructor completely. That would simplify fdStream and you also can get rid of the whole _needs_close logic inside fdStream. Cheers, Thomas P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" than others and should not call upward. Examples would be logging (UL) or os::malloc(). For instance, as it is today, UL is not usable before VM initialization, and cannot be used within functions which are used by UL, e.g. os::malloc. On Wed, Feb 13, 2019 at 11:35 AM Baesken, Matthias wrote: > Thanks for the feedback . > > Do you see any special issue with the os::open implementations that > forbid usage in os::error ? > > Kim what do you think ? > > > > I found over 80 references to os::? calls in vmError.cpp so I > think it is not generally a bad thing to do it (however for course there > might be functions in the os:: layer that > > cause trouble in error reporting). > > > > > > New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation > + vmError.cpp adjustment removed) > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ > > > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Mittwoch, 13. Februar 2019 10:41 > *To:* Baesken, Matthias > *Cc:* hotspot-dev at openjdk.java.net; Kim Barrett > *Subject:* Re: 8218811: replace open by os::open in hotspot coding - was > : open-calls in hotspot code instead of os::open ? > > > > Hi Matthias, > > > > not a full review but please do not use os::open in error reporting: > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html > > > > We should use as little as possible VM functions here, since they may be > broken and/or pull other VM dependencies which may be broken or introduce > circularities. > > > > I am not sure if the same argument holds for other call sites as well. > > > > Best Regards, Thomas > > > > > > > > On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Hello, here is a first webrev + bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > The gcc deprecation attribute for open in > hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a > hack , > Maybe you have a better idea for disabling ( is there a good way to use a > pragma instead of the define ) ? > > Additionally I was not 100 % sure - are there maybe a few places where we > want to stay away from os::open for good reason ? > > > Best regards, Matthias > > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Dienstag, 12. Februar 2019 10:17 > > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : > open- > > calls in hotspot code instead of os::open ? > > > > Hi Ioi / Kim I created > > > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > > > 8218811: replace open by os::open in hotspot coding > > > > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > For functions which should never be called outside the implementation > of > > the os replacement, we can use (for example) > > > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > > > and in the definition of os::vsnprintf, locally disable the deprecation > > warning with the appropriate diagnostic #pragma. > > > > Should I add something like this for open to compilerWarnings.hpp ? > > I think if yes, I better restrict this for now to gcc . > > > > > > Best regards, Matthias > > > > > > > > Message: 4 > > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > > Content-Type: text/plain; charset=us-ascii > > > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam wrote: > > > > > > > > I think this should be fixed. > > > > > > +1 > > > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > > From coleen.phillimore at oracle.com Wed Feb 13 13:40:34 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 13 Feb 2019 08:40:34 -0500 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> Message-ID: <3d6e9642-47e0-8a2a-7a08-0d195db8a783@oracle.com> On 2/11/19 3:39 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix the resolving of oops inside the (VM) > OopHandles. > > https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218734 > > Before this patch the OopHandle::_obj was assumed to be located at > offset 0, and the SA resolved OopHandle (Klass::_java_mirror and > ClassLoaderData::_class_loader) without the required load barrier for > ZGC. I've added a new class VMOopHandle (The SA already has a > OopHandle), which handles the resolving (load or load + barrier). This looks good but unfortunate that the SA has a different OopHandle.? Maybe it would be more accurate to call it AccessOopHandle to imply that it has to use barriers? > > The OopHandle type is grouped under the Oops section in vmStructs.cpp. > It's not an oop, so I added a newline to separate it out from the > rest. Any suggestion of a better location in that file? > Seems ok to me.? The change looks fine.? Thank you for fixing this. Thanks, Coleen > Tested with the jtreg tests in serviceability/sa + patches to make ZGC > usable with the SA's hprof dumping. > > Thanks, > StefanK From matthias.baesken at sap.com Wed Feb 13 15:00:37 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 13 Feb 2019 15:00:37 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: Hi Thomas , regarding os_linux.cpp , vmError.cpp and arguments.cpp I could remove the calls to os:::open ( my first webrev did not touch os_linux.cpp because I thought there might be reasons to omit using it there ). Additionally I?d remove fdStream::fdStream(const char* file_name) { Is everyone fine with this ? * P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" * than others and should not call upward. I?d even like to have a very basic layer I could reuse in the native jdk libs too ?? (separate lib). However this is out of scope of this change . Best regards, Matthias From: Thomas St?fe Sent: Mittwoch, 13. Februar 2019 12:43 To: Baesken, Matthias ; Kim Barrett Cc: hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? My problem with this change are potential re entrant calls which may cause crashes or deadlocks. In addition, there are dependencies on VM initialization order to consider. By wholesale exchanging open() with os::open(), you add dependencies to VM infrastructure at a lot of places where we did have none before. VM infrastructure which may not be reentrant and/or which may be dependent on VM initialization. Example: Lets say you crash in an os::open() function, enter error reporting, which calls the same os::open() function. Then you have a circularity where you may crash again or lock. Even if it works today: these things like to grow and bitrot. Today os::open is simple, tomorrow someone else could very well have the idea of adding hooks to os::open in the future to monitor, count, etc, and boom, you have new dependencies. Case in point is os::malloc() which used to be a harmless drop in malloc replacement and now is a Moloch which calls, among other things, into NMT. I think one has to look at every callsite in your change and determine if: - it runs the risk of being called recursively (e.g. anything triggered from signal handling, or a general purpose class like ostream) - it could theoretically be called before VM initialization or argument parsing, or after cleanup Some examples: -- src/hotspot/os/linux/os_linux.cpp - _print_ascii_file() is used during error reporting. - os::get_core_path() is used during error reporting. -- src/hotspot/share/runtime/arguments.cpp Arguments::parse_vm_options_file(const char* file_name, ScopedVMInitArgs* vm_args) initialization dependency here: this gets called before all VM options are parsed, therefore I would not use VM functions which may rely on VM options. -- src/hotspot/share/utilities/ostream.cpp fdStream::fdStream(const char* file_name) { - _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); + _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); _need_close = true; } fdStream is a general purpose class and used in a lot of places, including os::abort and error reporting, so I would be against this change. However, this constructor variant is called from nowhere: I would scratch this constructor completely. That would simplify fdStream and you also can get rid of the whole _needs_close logic inside fdStream. Cheers, Thomas P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" than others and should not call upward. Examples would be logging (UL) or os::malloc(). For instance, as it is today, UL is not usable before VM initialization, and cannot be used within functions which are used by UL, e.g. os::malloc. On Wed, Feb 13, 2019 at 11:35 AM Baesken, Matthias > wrote: Thanks for the feedback . Do you see any special issue with the os::open implementations that forbid usage in os::error ? Kim what do you think ? I found over 80 references to os::? calls in vmError.cpp so I think it is not generally a bad thing to do it (however for course there might be functions in the os:: layer that cause trouble in error reporting). New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation + vmError.cpp adjustment removed) http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 10:41 To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net; Kim Barrett > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, not a full review but please do not use os::open in error reporting: http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html We should use as little as possible VM functions here, since they may be broken and/or pull other VM dependencies which may be broken or introduce circularities. I am not sure if the same argument holds for other call sites as well. Best Regards, Thomas On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias > wrote: Hello, here is a first webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ https://bugs.openjdk.java.net/browse/JDK-8218811 The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 12. Februar 2019 10:17 > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : open- > calls in hotspot code instead of os::open ? > > Hi Ioi / Kim I created > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > 8218811: replace open by os::open in hotspot coding > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > For functions which should never be called outside the implementation of > the os replacement, we can use (for example) > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > and in the definition of os::vsnprintf, locally disable the deprecation > warning with the appropriate diagnostic #pragma. > > Should I add something like this for open to compilerWarnings.hpp ? > I think if yes, I better restrict this for now to gcc . > > > Best regards, Matthias > > > > > Message: 4 > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > Content-Type: text/plain; charset=us-ascii > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam > wrote: > > > > > > I think this should be fixed. > > > > +1 > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > From stefan.karlsson at oracle.com Wed Feb 13 15:40:57 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Feb 2019 16:40:57 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <3d6e9642-47e0-8a2a-7a08-0d195db8a783@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> <3d6e9642-47e0-8a2a-7a08-0d195db8a783@oracle.com> Message-ID: <40d90cf8-0b36-34c0-7122-23f829037c22@oracle.com> On 2019-02-13 14:40, coleen.phillimore at oracle.com wrote: > > > On 2/11/19 3:39 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix the resolving of oops inside the (VM) >> OopHandles. >> >> https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218734 >> >> Before this patch the OopHandle::_obj was assumed to be located at >> offset 0, and the SA resolved OopHandle (Klass::_java_mirror and >> ClassLoaderData::_class_loader) without the required load barrier for >> ZGC. I've added a new class VMOopHandle (The SA already has a >> OopHandle), which handles the resolving (load or load + barrier). > > This looks good but unfortunate that the SA has a different OopHandle. > Maybe it would be more accurate to call it AccessOopHandle to imply that > it has to use barriers? Maybe. I'm not sure I like the name AccessOopHandle any better, but if you feel strongly about this I'll change it. >> >> The OopHandle type is grouped under the Oops section in vmStructs.cpp. >> It's not an oop, so I added a newline to separate it out from the >> rest. Any suggestion of a better location in that file? >> > > Seems ok to me.? The change looks fine.? Thank you for fixing this. Thanks for reviewing. I'll change getAddressField to getField as suggested by Jini in another thread. Thanks, StefanK > > Thanks, > Coleen >> Tested with the jtreg tests in serviceability/sa + patches to make ZGC >> usable with the SA's hprof dumping. >> >> Thanks, >> StefanK > From coleen.phillimore at oracle.com Wed Feb 13 16:12:11 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 13 Feb 2019 11:12:11 -0500 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <40d90cf8-0b36-34c0-7122-23f829037c22@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> <3d6e9642-47e0-8a2a-7a08-0d195db8a783@oracle.com> <40d90cf8-0b36-34c0-7122-23f829037c22@oracle.com> Message-ID: On 2/13/19 10:40 AM, Stefan Karlsson wrote: > On 2019-02-13 14:40, coleen.phillimore at oracle.com wrote: >> >> >> On 2/11/19 3:39 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to fix the resolving of oops inside the >>> (VM) OopHandles. >>> >>> https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8218734 >>> >>> Before this patch the OopHandle::_obj was assumed to be located at >>> offset 0, and the SA resolved OopHandle (Klass::_java_mirror and >>> ClassLoaderData::_class_loader) without the required load barrier >>> for ZGC. I've added a new class VMOopHandle (The SA already has a >>> OopHandle), which handles the resolving (load or load + barrier). >> >> This looks good but unfortunate that the SA has a different >> OopHandle. Maybe it would be more accurate to call it AccessOopHandle >> to imply that it has to use barriers? > > Maybe. I'm not sure I like the name AccessOopHandle any better, but if > you feel strongly about this I'll change it. I don't feel strongly about it. > >>> >>> The OopHandle type is grouped under the Oops section in >>> vmStructs.cpp. It's not an oop, so I added a newline to separate it >>> out from the rest. Any suggestion of a better location in that file? >>> >> >> Seems ok to me.? The change looks fine.? Thank you for fixing this. > > Thanks for reviewing. I'll change getAddressField to getField as > suggested by Jini in another thread. > Good, I didn't see any replies and was wondering if it should be sent to another mailing list. Coleen > Thanks, > StefanK > >> >> Thanks, >> Coleen >>> Tested with the jtreg tests in serviceability/sa + patches to make >>> ZGC usable with the SA's hprof dumping. >>> >>> Thanks, >>> StefanK >> From thomas.stuefe at gmail.com Wed Feb 13 16:41:58 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 13 Feb 2019 17:41:58 +0100 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: Hi Matthias, On Wed, Feb 13, 2019 at 4:00 PM Baesken, Matthias wrote: > Hi Thomas , regarding os_linux.cpp , vmError.cpp and arguments.cpp > I could remove the calls to os:::open ( my first webrev did not touch > os_linux.cpp because I thought there might be > > reasons to omit using it there ). > > > makes sense. > Additionally I?d remove > > > > fdStream::fdStream(const char* file_name) { > > > Is everyone fine with this ? > > Yes, please, and you could then slim down the logic inside fdStream somewhat. Currently it has those two modes, one where he owns the file, one where not. Since we remove the former case, you can remove _needs_close and the close() call in the destructor. Thank you, Thomas > > > - P.S. what I actually think the VM needs, and what is missing, is the > concept of layers - some functions are more "basic" > - than others and should not call upward. > > > > I?d even like to have a very basic layer I could reuse in the native jdk > libs too ?? (separate lib). > > However this is out of scope of this change . > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Mittwoch, 13. Februar 2019 12:43 > *To:* Baesken, Matthias ; Kim Barrett < > kim.barrett at oracle.com> > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: 8218811: replace open by os::open in hotspot coding - was > : open-calls in hotspot code instead of os::open ? > > > > > > My problem with this change are potential re entrant calls which may cause > crashes or deadlocks. In addition, there are dependencies on VM > initialization order to consider. > > > > By wholesale exchanging open() with os::open(), you add dependencies to VM > infrastructure at a lot of places where we did have none before. VM > infrastructure which may not be reentrant and/or which may be dependent on > VM initialization. > > > > Example: Lets say you crash in an os::open() function, enter error > reporting, which calls the same os::open() function. Then you have a > circularity where you may crash again or lock. > > > > Even if it works today: these things like to grow and bitrot. Today > os::open is simple, tomorrow someone else could very well have the idea of > adding hooks to os::open in the future to monitor, count, etc, and boom, > you have new dependencies. > > > > Case in point is os::malloc() which used to be a harmless drop in malloc > replacement and now is a Moloch which calls, among other things, into NMT. > > > > I think one has to look at every callsite in your change and determine if: > > > > - it runs the risk of being called recursively (e.g. anything triggered > from signal handling, or a general purpose class like ostream) > > - it could theoretically be called before VM initialization or argument > parsing, or after cleanup > > > > Some examples: > > > > -- > > src/hotspot/os/linux/os_linux.cpp > > - _print_ascii_file() is used during error reporting. > > - os::get_core_path() is used during error reporting. > > -- > > src/hotspot/share/runtime/arguments.cpp > > Arguments::parse_vm_options_file(const char* file_name, ScopedVMInitArgs* > vm_args) > > > > initialization dependency here: this gets called before all VM options are > parsed, therefore I would not use VM functions which may rely on VM options. > > > > -- > > > > src/hotspot/share/utilities/ostream.cpp > > fdStream::fdStream(const char* file_name) { > - _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); > + _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); > _need_close = true; > } > > fdStream is a general purpose class and used in a lot of places, including > os::abort and error reporting, so I would be against this change. However, > this constructor variant is called from nowhere: I would scratch this > constructor completely. That would simplify fdStream and you also can get > rid of the whole _needs_close logic inside fdStream. > > > > Cheers, Thomas > > > > > > P.S. what I actually think the VM needs, and what is missing, is the > concept of layers - some functions are more "basic" than others and should > not call upward. Examples would be logging (UL) or os::malloc(). For > instance, as it is today, UL is not usable before VM initialization, and > cannot be used within functions which are used by UL, e.g. os::malloc. > > > > > > > > > > On Wed, Feb 13, 2019 at 11:35 AM Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Thanks for the feedback . > > Do you see any special issue with the os::open implementations that > forbid usage in os::error ? > > Kim what do you think ? > > > > I found over 80 references to os::? calls in vmError.cpp so I > think it is not generally a bad thing to do it (however for course there > might be functions in the os:: layer that > > cause trouble in error reporting). > > > > > > New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation > + vmError.cpp adjustment removed) > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ > > > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Mittwoch, 13. Februar 2019 10:41 > *To:* Baesken, Matthias > *Cc:* hotspot-dev at openjdk.java.net; Kim Barrett > *Subject:* Re: 8218811: replace open by os::open in hotspot coding - was > : open-calls in hotspot code instead of os::open ? > > > > Hi Matthias, > > > > not a full review but please do not use os::open in error reporting: > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html > > > > We should use as little as possible VM functions here, since they may be > broken and/or pull other VM dependencies which may be broken or introduce > circularities. > > > > I am not sure if the same argument holds for other call sites as well. > > > > Best Regards, Thomas > > > > > > > > On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Hello, here is a first webrev + bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > The gcc deprecation attribute for open in > hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a > hack , > Maybe you have a better idea for disabling ( is there a good way to use a > pragma instead of the define ) ? > > Additionally I was not 100 % sure - are there maybe a few places where we > want to stay away from os::open for good reason ? > > > Best regards, Matthias > > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Dienstag, 12. Februar 2019 10:17 > > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : > open- > > calls in hotspot code instead of os::open ? > > > > Hi Ioi / Kim I created > > > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > > > 8218811: replace open by os::open in hotspot coding > > > > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > For functions which should never be called outside the implementation > of > > the os replacement, we can use (for example) > > > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > > > and in the definition of os::vsnprintf, locally disable the deprecation > > warning with the appropriate diagnostic #pragma. > > > > Should I add something like this for open to compilerWarnings.hpp ? > > I think if yes, I better restrict this for now to gcc . > > > > > > Best regards, Matthias > > > > > > > > Message: 4 > > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > > Content-Type: text/plain; charset=us-ascii > > > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam wrote: > > > > > > > > I think this should be fixed. > > > > > > +1 > > > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > > From stefan.karlsson at oracle.com Wed Feb 13 16:57:56 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Feb 2019 17:57:56 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> <3d6e9642-47e0-8a2a-7a08-0d195db8a783@oracle.com> <40d90cf8-0b36-34c0-7122-23f829037c22@oracle.com> Message-ID: <189e8356-b7e5-dbfe-ede7-a30fa6495ca7@oracle.com> On 2019-02-13 17:12, coleen.phillimore at oracle.com wrote: > > > On 2/13/19 10:40 AM, Stefan Karlsson wrote: >> On 2019-02-13 14:40, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 2/11/19 3:39 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to fix the resolving of oops inside the >>>> (VM) OopHandles. >>>> >>>> https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8218734 >>>> >>>> Before this patch the OopHandle::_obj was assumed to be located at >>>> offset 0, and the SA resolved OopHandle (Klass::_java_mirror and >>>> ClassLoaderData::_class_loader) without the required load barrier >>>> for ZGC. I've added a new class VMOopHandle (The SA already has a >>>> OopHandle), which handles the resolving (load or load + barrier). >>> >>> This looks good but unfortunate that the SA has a different >>> OopHandle. Maybe it would be more accurate to call it >>> AccessOopHandle to imply that it has to use barriers? >> >> Maybe. I'm not sure I like the name AccessOopHandle any better, but >> if you feel strongly about this I'll change it. > I don't feel strongly about it. >> >>>> >>>> The OopHandle type is grouped under the Oops section in >>>> vmStructs.cpp. It's not an oop, so I added a newline to separate it >>>> out from the rest. Any suggestion of a better location in that file? >>>> >>> >>> Seems ok to me.? The change looks fine.? Thank you for fixing this. >> >> Thanks for reviewing. I'll change getAddressField to getField as >> suggested by Jini in another thread. >> > > Good, I didn't see any replies and was wondering if it should be sent > to another mailing list. I think you dropped serviceability-dev (TO:ed). StefanK > > Coleen > >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >>>> Tested with the jtreg tests in serviceability/sa + patches to make >>>> ZGC usable with the SA's hprof dumping. >>>> >>>> Thanks, >>>> StefanK >>> > From matthias.baesken at sap.com Thu Feb 14 08:49:44 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 14 Feb 2019 08:49:44 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.2/ * Removed my os::open changes from os_linux.cpp and vmError.cpp because of Thomas concerns - Removed fdStream::fdStream(const char* file_name) { ? } from ostream.cpp ; I stayed away from any more ?cleanups? to ostream , could be done in a separate change in case it is wanted Best regards, Matthias From: Thomas St?fe Sent: Mittwoch, 13. Februar 2019 17:42 To: Baesken, Matthias Cc: Kim Barrett ; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, On Wed, Feb 13, 2019 at 4:00 PM Baesken, Matthias > wrote: Hi Thomas , regarding os_linux.cpp , vmError.cpp and arguments.cpp I could remove the calls to os:::open ( my first webrev did not touch os_linux.cpp because I thought there might be reasons to omit using it there ). makes sense. Additionally I?d remove fdStream::fdStream(const char* file_name) { Is everyone fine with this ? Yes, please, and you could then slim down the logic inside fdStream somewhat. Currently it has those two modes, one where he owns the file, one where not. Since we remove the former case, you can remove _needs_close and the close() call in the destructor. Thank you, Thomas * P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" * than others and should not call upward. I?d even like to have a very basic layer I could reuse in the native jdk libs too ?? (separate lib). However this is out of scope of this change . Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 12:43 To: Baesken, Matthias >; Kim Barrett > Cc: hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? My problem with this change are potential re entrant calls which may cause crashes or deadlocks. In addition, there are dependencies on VM initialization order to consider. By wholesale exchanging open() with os::open(), you add dependencies to VM infrastructure at a lot of places where we did have none before. VM infrastructure which may not be reentrant and/or which may be dependent on VM initialization. Example: Lets say you crash in an os::open() function, enter error reporting, which calls the same os::open() function. Then you have a circularity where you may crash again or lock. Even if it works today: these things like to grow and bitrot. Today os::open is simple, tomorrow someone else could very well have the idea of adding hooks to os::open in the future to monitor, count, etc, and boom, you have new dependencies. Case in point is os::malloc() which used to be a harmless drop in malloc replacement and now is a Moloch which calls, among other things, into NMT. I think one has to look at every callsite in your change and determine if: - it runs the risk of being called recursively (e.g. anything triggered from signal handling, or a general purpose class like ostream) - it could theoretically be called before VM initialization or argument parsing, or after cleanup Some examples: -- src/hotspot/os/linux/os_linux.cpp - _print_ascii_file() is used during error reporting. - os::get_core_path() is used during error reporting. -- src/hotspot/share/runtime/arguments.cpp Arguments::parse_vm_options_file(const char* file_name, ScopedVMInitArgs* vm_args) initialization dependency here: this gets called before all VM options are parsed, therefore I would not use VM functions which may rely on VM options. -- src/hotspot/share/utilities/ostream.cpp fdStream::fdStream(const char* file_name) { - _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); + _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); _need_close = true; } fdStream is a general purpose class and used in a lot of places, including os::abort and error reporting, so I would be against this change. However, this constructor variant is called from nowhere: I would scratch this constructor completely. That would simplify fdStream and you also can get rid of the whole _needs_close logic inside fdStream. Cheers, Thomas P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" than others and should not call upward. Examples would be logging (UL) or os::malloc(). For instance, as it is today, UL is not usable before VM initialization, and cannot be used within functions which are used by UL, e.g. os::malloc. On Wed, Feb 13, 2019 at 11:35 AM Baesken, Matthias > wrote: Thanks for the feedback . Do you see any special issue with the os::open implementations that forbid usage in os::error ? Kim what do you think ? I found over 80 references to os::? calls in vmError.cpp so I think it is not generally a bad thing to do it (however for course there might be functions in the os:: layer that cause trouble in error reporting). New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation + vmError.cpp adjustment removed) http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 10:41 To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net; Kim Barrett > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, not a full review but please do not use os::open in error reporting: http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html We should use as little as possible VM functions here, since they may be broken and/or pull other VM dependencies which may be broken or introduce circularities. I am not sure if the same argument holds for other call sites as well. Best Regards, Thomas On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias > wrote: Hello, here is a first webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ https://bugs.openjdk.java.net/browse/JDK-8218811 The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 12. Februar 2019 10:17 > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : open- > calls in hotspot code instead of os::open ? > > Hi Ioi / Kim I created > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > 8218811: replace open by os::open in hotspot coding > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > For functions which should never be called outside the implementation of > the os replacement, we can use (for example) > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > and in the definition of os::vsnprintf, locally disable the deprecation > warning with the appropriate diagnostic #pragma. > > Should I add something like this for open to compilerWarnings.hpp ? > I think if yes, I better restrict this for now to gcc . > > > Best regards, Matthias > > > > > Message: 4 > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > Content-Type: text/plain; charset=us-ascii > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam > wrote: > > > > > > I think this should be fixed. > > > > +1 > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > From erik.osterlund at oracle.com Thu Feb 14 09:01:01 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 10:01:01 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> Message-ID: <56d28bba-68d3-22e2-4e40-1615944c26d2@oracle.com> Hi Stefan, Looks good. One thing though... At VMOopHandle.java line 38: * Remove weird double indentation * Remove weird double semicolon * Use Field instead of AddressField I don't think I need another webrev. Thanks, /Erik On 2019-02-11 09:39, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix the resolving of oops inside the (VM) > OopHandles. > > https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218734 > > Before this patch the OopHandle::_obj was assumed to be located at > offset 0, and the SA resolved OopHandle (Klass::_java_mirror and > ClassLoaderData::_class_loader) without the required load barrier for > ZGC. I've added a new class VMOopHandle (The SA already has a > OopHandle), which handles the resolving (load or load + barrier). > > The OopHandle type is grouped under the Oops section in vmStructs.cpp. > It's not an oop, so I added a newline to separate it out from the rest. > Any suggestion of a better location in that file? > > Tested with the jtreg tests in serviceability/sa + patches to make ZGC > usable with the SA's hprof dumping. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 09:12:03 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 10:12:03 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <56d28bba-68d3-22e2-4e40-1615944c26d2@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> <56d28bba-68d3-22e2-4e40-1615944c26d2@oracle.com> Message-ID: <058b39bb-a0da-621d-6981-36bbf06ec23f@oracle.com> On 2019-02-14 10:01, Erik ?sterlund wrote: > Hi Stefan, > > Looks good. One thing though... > > At VMOopHandle.java line 38: > > * Remove weird double indentation > * Remove weird double semicolon > * Use Field instead of AddressField I'll fix. > > I don't think I need another webrev. Thanks for reviewing. StefanK > > Thanks, > /Erik > > On 2019-02-11 09:39, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix the resolving of oops inside the (VM) >> OopHandles. >> >> https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218734 >> >> Before this patch the OopHandle::_obj was assumed to be located at >> offset 0, and the SA resolved OopHandle (Klass::_java_mirror and >> ClassLoaderData::_class_loader) without the required load barrier for >> ZGC. I've added a new class VMOopHandle (The SA already has a >> OopHandle), which handles the resolving (load or load + barrier). >> >> The OopHandle type is grouped under the Oops section in vmStructs.cpp. >> It's not an oop, so I added a newline to separate it out from the >> rest. Any suggestion of a better location in that file? >> >> Tested with the jtreg tests in serviceability/sa + patches to make ZGC >> usable with the SA's hprof dumping. >> >> Thanks, >> StefanK From thomas.stuefe at gmail.com Thu Feb 14 10:07:34 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 14 Feb 2019 11:07:34 +0100 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: Hi Matthias, fdStream: can you pls also remove: fdStream::fdStream(const char* file_name) bool _need_close; and the close() call in the constructor? -- CompileLog::finish_log_on_error() is also used during error reporting (see comment above the function). --- src/hotspot/share/utilities/compilerWarnings_gcc.hpp is a whitespace only change. -- Skimmed the rest and it seems ok. Thanks Thomas On Thu, Feb 14, 2019 at 9:49 AM Baesken, Matthias wrote: > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.2/ > > > > - Removed my os::open changes from os_linux.cpp and vmError.cpp > because of Thomas concerns > > - Removed fdStream::fdStream(const char* file_name) { ? } from ostream.cpp ; I stayed away from any more ?cleanups? to ostream , could be done in a separate change in case it is wanted > > > > > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Mittwoch, 13. Februar 2019 17:42 > *To:* Baesken, Matthias > *Cc:* Kim Barrett ; ioi.lam at oracle.com; > hotspot-dev at openjdk.java.net > *Subject:* Re: 8218811: replace open by os::open in hotspot coding - was > : open-calls in hotspot code instead of os::open ? > > > > > > Hi Matthias, > > > > On Wed, Feb 13, 2019 at 4:00 PM Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Hi Thomas , regarding os_linux.cpp , vmError.cpp and > arguments.cpp I could remove the calls to os:::open ( my first webrev > did not touch os_linux.cpp because I thought there might be > > reasons to omit using it there ). > > > > > > makes sense. > > > > Additionally I?d remove > > > > fdStream::fdStream(const char* file_name) { > > > > Is everyone fine with this ? > > > > Yes, please, and you could then slim down the logic inside fdStream > somewhat. Currently it has those two modes, one where he owns the file, one > where not. Since we remove the former case, you can remove _needs_close and > the close() call in the destructor. > > > > Thank you, > > > > Thomas > > > > > > - P.S. what I actually think the VM needs, and what is missing, is the > concept of layers - some functions are more "basic" > - than others and should not call upward. > > > > I?d even like to have a very basic layer I could reuse in the native jdk > libs too ?? (separate lib). > > However this is out of scope of this change . > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Mittwoch, 13. Februar 2019 12:43 > *To:* Baesken, Matthias ; Kim Barrett < > kim.barrett at oracle.com> > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: 8218811: replace open by os::open in hotspot coding - was > : open-calls in hotspot code instead of os::open ? > > > > > > My problem with this change are potential re entrant calls which may cause > crashes or deadlocks. In addition, there are dependencies on VM > initialization order to consider. > > > > By wholesale exchanging open() with os::open(), you add dependencies to VM > infrastructure at a lot of places where we did have none before. VM > infrastructure which may not be reentrant and/or which may be dependent on > VM initialization. > > > > Example: Lets say you crash in an os::open() function, enter error > reporting, which calls the same os::open() function. Then you have a > circularity where you may crash again or lock. > > > > Even if it works today: these things like to grow and bitrot. Today > os::open is simple, tomorrow someone else could very well have the idea of > adding hooks to os::open in the future to monitor, count, etc, and boom, > you have new dependencies. > > > > Case in point is os::malloc() which used to be a harmless drop in malloc > replacement and now is a Moloch which calls, among other things, into NMT. > > > > I think one has to look at every callsite in your change and determine if: > > > > - it runs the risk of being called recursively (e.g. anything triggered > from signal handling, or a general purpose class like ostream) > > - it could theoretically be called before VM initialization or argument > parsing, or after cleanup > > > > Some examples: > > > > -- > > src/hotspot/os/linux/os_linux.cpp > > - _print_ascii_file() is used during error reporting. > > - os::get_core_path() is used during error reporting. > > -- > > src/hotspot/share/runtime/arguments.cpp > > Arguments::parse_vm_options_file(const char* file_name, ScopedVMInitArgs* > vm_args) > > > > initialization dependency here: this gets called before all VM options are > parsed, therefore I would not use VM functions which may rely on VM options. > > > > -- > > > > src/hotspot/share/utilities/ostream.cpp > > fdStream::fdStream(const char* file_name) { > - _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); > + _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); > _need_close = true; > } > > fdStream is a general purpose class and used in a lot of places, including > os::abort and error reporting, so I would be against this change. However, > this constructor variant is called from nowhere: I would scratch this > constructor completely. That would simplify fdStream and you also can get > rid of the whole _needs_close logic inside fdStream. > > > > Cheers, Thomas > > > > > > P.S. what I actually think the VM needs, and what is missing, is the > concept of layers - some functions are more "basic" than others and should > not call upward. Examples would be logging (UL) or os::malloc(). For > instance, as it is today, UL is not usable before VM initialization, and > cannot be used within functions which are used by UL, e.g. os::malloc. > > > > > > > > > > On Wed, Feb 13, 2019 at 11:35 AM Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Thanks for the feedback . > > Do you see any special issue with the os::open implementations that > forbid usage in os::error ? > > Kim what do you think ? > > > > I found over 80 references to os::? calls in vmError.cpp so I > think it is not generally a bad thing to do it (however for course there > might be functions in the os:: layer that > > cause trouble in error reporting). > > > > > > New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation > + vmError.cpp adjustment removed) > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ > > > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Mittwoch, 13. Februar 2019 10:41 > *To:* Baesken, Matthias > *Cc:* hotspot-dev at openjdk.java.net; Kim Barrett > *Subject:* Re: 8218811: replace open by os::open in hotspot coding - was > : open-calls in hotspot code instead of os::open ? > > > > Hi Matthias, > > > > not a full review but please do not use os::open in error reporting: > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html > > > > We should use as little as possible VM functions here, since they may be > broken and/or pull other VM dependencies which may be broken or introduce > circularities. > > > > I am not sure if the same argument holds for other call sites as well. > > > > Best Regards, Thomas > > > > > > > > On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Hello, here is a first webrev + bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > The gcc deprecation attribute for open in > hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a > hack , > Maybe you have a better idea for disabling ( is there a good way to use a > pragma instead of the define ) ? > > Additionally I was not 100 % sure - are there maybe a few places where we > want to stay away from os::open for good reason ? > > > Best regards, Matthias > > > > -----Original Message----- > > From: Baesken, Matthias > > Sent: Dienstag, 12. Februar 2019 10:17 > > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : > open- > > calls in hotspot code instead of os::open ? > > > > Hi Ioi / Kim I created > > > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > > > 8218811: replace open by os::open in hotspot coding > > > > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > For functions which should never be called outside the implementation > of > > the os replacement, we can use (for example) > > > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > > > and in the definition of os::vsnprintf, locally disable the deprecation > > warning with the appropriate diagnostic #pragma. > > > > Should I add something like this for open to compilerWarnings.hpp ? > > I think if yes, I better restrict this for now to gcc . > > > > > > Best regards, Matthias > > > > > > > > Message: 4 > > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > > Content-Type: text/plain; charset=us-ascii > > > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam wrote: > > > > > > > > I think this should be fixed. > > > > > > +1 > > > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > > > > > From matthias.baesken at sap.com Thu Feb 14 11:42:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 14 Feb 2019 11:42:51 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: >fdStream::fdStream(const char* file_name) > >bool _need_close; > >and the close() call in the constructor? Hi, this has nothing to do with this change. I have very bad experience with bringing in unrelated cleanups into a change my request after request etc. Will remove the os::open from CompileLog::finish_log_on_error() and the whitespace stuff. Thanks, Matthias From: Thomas St?fe Sent: Donnerstag, 14. Februar 2019 11:08 To: Baesken, Matthias Cc: Kim Barrett ; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, fdStream: can you pls also remove: fdStream::fdStream(const char* file_name) bool _need_close; and the close() call in the constructor? -- CompileLog::finish_log_on_error() is also used during error reporting (see comment above the function). --- src/hotspot/share/utilities/compilerWarnings_gcc.hpp is a whitespace only change. -- Skimmed the rest and it seems ok. Thanks Thomas On Thu, Feb 14, 2019 at 9:49 AM Baesken, Matthias > wrote: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.2/ * Removed my os::open changes from os_linux.cpp and vmError.cpp because of Thomas concerns - Removed fdStream::fdStream(const char* file_name) { ? } from ostream.cpp ; I stayed away from any more ?cleanups? to ostream , could be done in a separate change in case it is wanted Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 17:42 To: Baesken, Matthias > Cc: Kim Barrett >; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, On Wed, Feb 13, 2019 at 4:00 PM Baesken, Matthias > wrote: Hi Thomas , regarding os_linux.cpp , vmError.cpp and arguments.cpp I could remove the calls to os:::open ( my first webrev did not touch os_linux.cpp because I thought there might be reasons to omit using it there ). makes sense. Additionally I?d remove fdStream::fdStream(const char* file_name) { Is everyone fine with this ? Yes, please, and you could then slim down the logic inside fdStream somewhat. Currently it has those two modes, one where he owns the file, one where not. Since we remove the former case, you can remove _needs_close and the close() call in the destructor. Thank you, Thomas * P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" * than others and should not call upward. I?d even like to have a very basic layer I could reuse in the native jdk libs too ?? (separate lib). However this is out of scope of this change . Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 12:43 To: Baesken, Matthias >; Kim Barrett > Cc: hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? My problem with this change are potential re entrant calls which may cause crashes or deadlocks. In addition, there are dependencies on VM initialization order to consider. By wholesale exchanging open() with os::open(), you add dependencies to VM infrastructure at a lot of places where we did have none before. VM infrastructure which may not be reentrant and/or which may be dependent on VM initialization. Example: Lets say you crash in an os::open() function, enter error reporting, which calls the same os::open() function. Then you have a circularity where you may crash again or lock. Even if it works today: these things like to grow and bitrot. Today os::open is simple, tomorrow someone else could very well have the idea of adding hooks to os::open in the future to monitor, count, etc, and boom, you have new dependencies. Case in point is os::malloc() which used to be a harmless drop in malloc replacement and now is a Moloch which calls, among other things, into NMT. I think one has to look at every callsite in your change and determine if: - it runs the risk of being called recursively (e.g. anything triggered from signal handling, or a general purpose class like ostream) - it could theoretically be called before VM initialization or argument parsing, or after cleanup Some examples: -- src/hotspot/os/linux/os_linux.cpp - _print_ascii_file() is used during error reporting. - os::get_core_path() is used during error reporting. -- src/hotspot/share/runtime/arguments.cpp Arguments::parse_vm_options_file(const char* file_name, ScopedVMInitArgs* vm_args) initialization dependency here: this gets called before all VM options are parsed, therefore I would not use VM functions which may rely on VM options. -- src/hotspot/share/utilities/ostream.cpp fdStream::fdStream(const char* file_name) { - _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); + _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); _need_close = true; } fdStream is a general purpose class and used in a lot of places, including os::abort and error reporting, so I would be against this change. However, this constructor variant is called from nowhere: I would scratch this constructor completely. That would simplify fdStream and you also can get rid of the whole _needs_close logic inside fdStream. Cheers, Thomas P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" than others and should not call upward. Examples would be logging (UL) or os::malloc(). For instance, as it is today, UL is not usable before VM initialization, and cannot be used within functions which are used by UL, e.g. os::malloc. On Wed, Feb 13, 2019 at 11:35 AM Baesken, Matthias > wrote: Thanks for the feedback . Do you see any special issue with the os::open implementations that forbid usage in os::error ? Kim what do you think ? I found over 80 references to os::? calls in vmError.cpp so I think it is not generally a bad thing to do it (however for course there might be functions in the os:: layer that cause trouble in error reporting). New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation + vmError.cpp adjustment removed) http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 10:41 To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net; Kim Barrett > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, not a full review but please do not use os::open in error reporting: http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html We should use as little as possible VM functions here, since they may be broken and/or pull other VM dependencies which may be broken or introduce circularities. I am not sure if the same argument holds for other call sites as well. Best Regards, Thomas On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias > wrote: Hello, here is a first webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ https://bugs.openjdk.java.net/browse/JDK-8218811 The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 12. Februar 2019 10:17 > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : open- > calls in hotspot code instead of os::open ? > > Hi Ioi / Kim I created > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > 8218811: replace open by os::open in hotspot coding > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > For functions which should never be called outside the implementation of > the os replacement, we can use (for example) > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > and in the definition of os::vsnprintf, locally disable the deprecation > warning with the appropriate diagnostic #pragma. > > Should I add something like this for open to compilerWarnings.hpp ? > I think if yes, I better restrict this for now to gcc . > > > Best regards, Matthias > > > > > Message: 4 > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > Content-Type: text/plain; charset=us-ascii > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam > wrote: > > > > > > I think this should be fixed. > > > > +1 > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > From volker.simonis at gmail.com Thu Feb 14 13:20:10 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Feb 2019 14:20:10 +0100 Subject: CFV: New hotspot Group Member: Thomas Stuefe Message-ID: I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to Membership in the HotSpot Group. Thomas is one of the initial authors of the AIX/OS400 port, a jdk project Reviewer and long term OpenJDK Contributor. Since 2015 he has contributed more than 140 changes [3] and reviewed more than 240 [4] mostly in the hotspot runtime area. Votes are due by February 28, 2019, 18:00 CET. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. With best regards, Volker [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc From volker.simonis at gmail.com Thu Feb 14 13:24:44 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Feb 2019 14:24:44 +0100 Subject: CFV: New hotspot Group Member: Martin Doerr Message-ID: I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to Membership in the HotSpot Group. Martin is one of the initial authors of the ppc64 port, a jdk project Reviewer and long term OpenJDK Contributor. Since 2014 he has contributed more than 112 changes [3] and reviewed more than 154 [4]. Votes are due by February 28, 2019, 18:00 CET. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. With best regards, Volker [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc From coleen.phillimore at oracle.com Thu Feb 14 13:37:08 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 14 Feb 2019 08:37:08 -0500 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes On 2/14/19 8:20 AM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc From coleen.phillimore at oracle.com Thu Feb 14 13:48:01 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 14 Feb 2019 08:48:01 -0500 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <36e4db10-5dfe-5cab-3dc4-ab73a45f50e3@oracle.com> Vote: yes On 2/14/19 8:24 AM, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc From matthias.baesken at sap.com Thu Feb 14 15:44:04 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 14 Feb 2019 15:44:04 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: Hello, here is the updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.4/ Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 14. Februar 2019 12:43 To: 'Thomas St?fe' Cc: Kim Barrett ; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net Subject: RE: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? >fdStream::fdStream(const char* file_name) > >bool _need_close; > >and the close() call in the constructor? Hi, this has nothing to do with this change. I have very bad experience with bringing in unrelated cleanups into a change my request after request etc. Will remove the os::open from CompileLog::finish_log_on_error() and the whitespace stuff. Thanks, Matthias From: Thomas St?fe > Sent: Donnerstag, 14. Februar 2019 11:08 To: Baesken, Matthias > Cc: Kim Barrett >; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, fdStream: can you pls also remove: fdStream::fdStream(const char* file_name) bool _need_close; and the close() call in the constructor? -- CompileLog::finish_log_on_error() is also used during error reporting (see comment above the function). --- src/hotspot/share/utilities/compilerWarnings_gcc.hpp is a whitespace only change. -- Skimmed the rest and it seems ok. Thanks Thomas On Thu, Feb 14, 2019 at 9:49 AM Baesken, Matthias > wrote: New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.2/ * Removed my os::open changes from os_linux.cpp and vmError.cpp because of Thomas concerns - Removed fdStream::fdStream(const char* file_name) { ? } from ostream.cpp ; I stayed away from any more ?cleanups? to ostream , could be done in a separate change in case it is wanted Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 17:42 To: Baesken, Matthias > Cc: Kim Barrett >; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, On Wed, Feb 13, 2019 at 4:00 PM Baesken, Matthias > wrote: Hi Thomas , regarding os_linux.cpp , vmError.cpp and arguments.cpp I could remove the calls to os:::open ( my first webrev did not touch os_linux.cpp because I thought there might be reasons to omit using it there ). makes sense. Additionally I?d remove fdStream::fdStream(const char* file_name) { Is everyone fine with this ? Yes, please, and you could then slim down the logic inside fdStream somewhat. Currently it has those two modes, one where he owns the file, one where not. Since we remove the former case, you can remove _needs_close and the close() call in the destructor. Thank you, Thomas * P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" * than others and should not call upward. I?d even like to have a very basic layer I could reuse in the native jdk libs too ?? (separate lib). However this is out of scope of this change . Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 12:43 To: Baesken, Matthias >; Kim Barrett > Cc: hotspot-dev at openjdk.java.net Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? My problem with this change are potential re entrant calls which may cause crashes or deadlocks. In addition, there are dependencies on VM initialization order to consider. By wholesale exchanging open() with os::open(), you add dependencies to VM infrastructure at a lot of places where we did have none before. VM infrastructure which may not be reentrant and/or which may be dependent on VM initialization. Example: Lets say you crash in an os::open() function, enter error reporting, which calls the same os::open() function. Then you have a circularity where you may crash again or lock. Even if it works today: these things like to grow and bitrot. Today os::open is simple, tomorrow someone else could very well have the idea of adding hooks to os::open in the future to monitor, count, etc, and boom, you have new dependencies. Case in point is os::malloc() which used to be a harmless drop in malloc replacement and now is a Moloch which calls, among other things, into NMT. I think one has to look at every callsite in your change and determine if: - it runs the risk of being called recursively (e.g. anything triggered from signal handling, or a general purpose class like ostream) - it could theoretically be called before VM initialization or argument parsing, or after cleanup Some examples: -- src/hotspot/os/linux/os_linux.cpp - _print_ascii_file() is used during error reporting. - os::get_core_path() is used during error reporting. -- src/hotspot/share/runtime/arguments.cpp Arguments::parse_vm_options_file(const char* file_name, ScopedVMInitArgs* vm_args) initialization dependency here: this gets called before all VM options are parsed, therefore I would not use VM functions which may rely on VM options. -- src/hotspot/share/utilities/ostream.cpp fdStream::fdStream(const char* file_name) { - _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); + _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); _need_close = true; } fdStream is a general purpose class and used in a lot of places, including os::abort and error reporting, so I would be against this change. However, this constructor variant is called from nowhere: I would scratch this constructor completely. That would simplify fdStream and you also can get rid of the whole _needs_close logic inside fdStream. Cheers, Thomas P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" than others and should not call upward. Examples would be logging (UL) or os::malloc(). For instance, as it is today, UL is not usable before VM initialization, and cannot be used within functions which are used by UL, e.g. os::malloc. On Wed, Feb 13, 2019 at 11:35 AM Baesken, Matthias > wrote: Thanks for the feedback . Do you see any special issue with the os::open implementations that forbid usage in os::error ? Kim what do you think ? I found over 80 references to os::? calls in vmError.cpp so I think it is not generally a bad thing to do it (however for course there might be functions in the os:: layer that cause trouble in error reporting). New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation + vmError.cpp adjustment removed) http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ Best regards, Matthias From: Thomas St?fe > Sent: Mittwoch, 13. Februar 2019 10:41 To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net; Kim Barrett > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? Hi Matthias, not a full review but please do not use os::open in error reporting: http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html We should use as little as possible VM functions here, since they may be broken and/or pull other VM dependencies which may be broken or introduce circularities. I am not sure if the same argument holds for other call sites as well. Best Regards, Thomas On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias > wrote: Hello, here is a first webrev + bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ https://bugs.openjdk.java.net/browse/JDK-8218811 The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 12. Februar 2019 10:17 > To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > > Subject: 8218811: replace open by os::open in hotspot coding - was : open- > calls in hotspot code instead of os::open ? > > Hi Ioi / Kim I created > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > 8218811: replace open by os::open in hotspot coding > > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > For functions which should never be called outside the implementation of > the os replacement, we can use (for example) > > > > extern "C" int vsnprintf(char*, size_t, const char*, va_list) > > __attribute__((__deprecated__("use os::vsnprintf"))); > > > > and in the definition of os::vsnprintf, locally disable the deprecation > warning with the appropriate diagnostic #pragma. > > Should I add something like this for open to compilerWarnings.hpp ? > I think if yes, I better restrict this for now to gcc . > > > Best regards, Matthias > > > > > Message: 4 > > Date: Thu, 7 Feb 2019 12:40:00 -0500 > > From: Kim Barrett > > > To: Ioi Lam > > > Cc: hotspot-dev developers > > > Subject: Re: open-calls in hotspot code instead of os::open ? > > Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> > > Content-Type: text/plain; charset=us-ascii > > > > > On Feb 6, 2019, at 9:08 AM, Ioi Lam > wrote: > > > > > > I think this should be fixed. > > > > +1 > > > > > BTW, is there a way to forbid all the calls to ::open()? > > > > Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 > > > > From jesper.wilhelmsson at oracle.com Thu Feb 14 16:08:57 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 14 Feb 2019 17:08:57 +0100 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <2EB09E08-C7A4-4190-B044-B9AA7B939777@oracle.com> Vote: Yes /Jesper > On 14 Feb 2019, at 14:20, Volker Simonis wrote: > > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc From jesper.wilhelmsson at oracle.com Thu Feb 14 16:08:12 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 14 Feb 2019 17:08:12 +0100 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: Vote: Yes /Jesper > On 14 Feb 2019, at 14:24, Volker Simonis wrote: > > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc From vladimir.kozlov at oracle.com Thu Feb 14 16:18:02 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Feb 2019 08:18:02 -0800 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <2e990ae7-95c9-0a2a-65bd-ef32a9bdda3f@oracle.com> Vote: yes On 2/14/19 5:24 AM, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc > From vladimir.kozlov at oracle.com Thu Feb 14 16:18:22 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Feb 2019 08:18:22 -0800 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <53949e56-5392-6c6c-de66-7f230270820c@oracle.com> Vote: yes On 2/14/19 5:20 AM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc > From thomas.schatzl at oracle.com Thu Feb 14 16:41:34 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 14 Feb 2019 17:41:34 +0100 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: <2e990ae7-95c9-0a2a-65bd-ef32a9bdda3f@oracle.com> References: <2e990ae7-95c9-0a2a-65bd-ef32a9bdda3f@oracle.com> Message-ID: Vote: yes On Thu, 2019-02-14 at 08:18 -0800, Vladimir Kozlov wrote: > Vote: yes > > On 2/14/19 5:24 AM, Volker Simonis wrote: > > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > > Membership in the HotSpot Group. > > > > Martin is one of the initial authors of the ppc64 port, a jdk > > project Reviewer and long term OpenJDK Contributor. Since 2014 he > > has > > contributed more than 112 changes [3] and reviewed more than 154 > > [4]. > > > > Votes are due by February 28, 2019, 18:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote > > on > > this nomination. Votes must be cast in the open by replying to this > > mailing list. > > > > For Lazy Consensus voting instructions, see [2]. > > > > With best regards, > > Volker > > > > [1] http://openjdk.java.net/census#hotspot > > [2] http://openjdk.java.net/groups/#member-vote > > [3] > > https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc > > From karen.kinnear at oracle.com Thu Feb 14 16:51:06 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 14 Feb 2019 11:51:06 -0500 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <7E7F6A68-EA76-46C2-BD63-1CAFD59C3573@oracle.com> Vote: yes thanks, Karen > On Feb 14, 2019, at 8:24 AM, Volker Simonis wrote: > > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc From karen.kinnear at oracle.com Thu Feb 14 16:51:26 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 14 Feb 2019 11:51:26 -0500 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes thanks, Karen > On Feb 14, 2019, at 8:20 AM, Volker Simonis wrote: > > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc From shade at redhat.com Thu Feb 14 16:53:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Feb 2019 17:53:27 +0100 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: Vote: yes On 2/14/19 2:24 PM, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. From shade at redhat.com Thu Feb 14 16:54:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Feb 2019 17:54:03 +0100 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <06350642-f9eb-6fa6-4700-9523fc9d42ad@redhat.com> Vote: yes -Aleksey On 2/14/19 2:20 PM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc > From jini.george at oracle.com Thu Feb 14 17:11:42 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 14 Feb 2019 22:41:42 +0530 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> Message-ID: <2a1b75dd-6b87-9a1d-98a7-385bd8d96877@oracle.com> Hi Stefan, Other than the getAddressField to getField change and the comments by Erik, I just have a couple of nits to add. 1. This line in VMOopHandle.java can be removed: 31 import sun.jvm.hotspot.runtime.VMObjectFactory; 2. The copyright year for some of the files need updation. This looks good to me otherwise. Thanks, Jini. On 2/11/2019 2:09 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix the resolving of oops inside the (VM) > OopHandles. > > https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218734 > > Before this patch the OopHandle::_obj was assumed to be located at > offset 0, and the SA resolved OopHandle (Klass::_java_mirror and > ClassLoaderData::_class_loader) without the required load barrier for > ZGC. I've added a new class VMOopHandle (The SA already has a > OopHandle), which handles the resolving (load or load + barrier). > > The OopHandle type is grouped under the Oops section in vmStructs.cpp. > It's not an oop, so I added a newline to separate it out from the rest. > Any suggestion of a better location in that file? > > Tested with the jtreg tests in serviceability/sa + patches to make ZGC > usable with the SA's hprof dumping. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 17:21:35 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 18:21:35 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <2a1b75dd-6b87-9a1d-98a7-385bd8d96877@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> <2a1b75dd-6b87-9a1d-98a7-385bd8d96877@oracle.com> Message-ID: <1cf7527d-237e-80ad-2c97-55ffc5c32965@oracle.com> Hi Jini, On 2019-02-14 18:11, Jini George wrote: > Hi Stefan, > > Other than the getAddressField to getField change and the comments by > Erik, I just have a couple of nits to add. > > 1. This line in VMOopHandle.java can be removed: > > 31 import sun.jvm.hotspot.runtime.VMObjectFactory; Done. > > 2. The copyright year for some of the files need updation. Sure. > > This looks good to me otherwise. Thanks for reviewing. StefanK > > Thanks, > Jini. > > > On 2/11/2019 2:09 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to fix the resolving of oops inside the (VM) >> OopHandles. >> >> https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218734 >> >> Before this patch the OopHandle::_obj was assumed to be located at >> offset 0, and the SA resolved OopHandle (Klass::_java_mirror and >> ClassLoaderData::_class_loader) without the required load barrier for >> ZGC. I've added a new class VMOopHandle (The SA already has a >> OopHandle), which handles the resolving (load or load + barrier). >> >> The OopHandle type is grouped under the Oops section in >> vmStructs.cpp. It's not an oop, so I added a newline to separate it >> out from the rest. Any suggestion of a better location in that file? >> >> Tested with the jtreg tests in serviceability/sa + patches to make >> ZGC usable with the SA's hprof dumping. >> >> Thanks, >> StefanK From kim.barrett at oracle.com Thu Feb 14 17:25:06 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 14 Feb 2019 12:25:06 -0500 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: vote: yes > On Feb 14, 2019, at 8:24 AM, Volker Simonis wrote: > > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc From kim.barrett at oracle.com Thu Feb 14 17:25:35 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 14 Feb 2019 12:25:35 -0500 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <17C008BC-4374-41E5-9328-A406AE7A4C05@oracle.com> vote: yes > On Feb 14, 2019, at 8:20 AM, Volker Simonis wrote: > > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc From daniel.daugherty at oracle.com Thu Feb 14 18:31:38 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Feb 2019 13:31:38 -0500 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes Dan On 2/14/19 8:20 AM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc > From daniel.daugherty at oracle.com Thu Feb 14 18:31:53 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Feb 2019 13:31:53 -0500 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <7d43b89d-5022-494f-9fc7-be0177337820@oracle.com> Vote: yes Dan On 2/14/19 8:24 AM, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc > From aph at redhat.com Thu Feb 14 18:36:48 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Feb 2019 18:36:48 +0000 Subject: RFR: 8219006:AArch64: Register corruption in slow subtype check Message-ID: Thanks to Martin Doerr for finding and analaysing this one. StubRoutines::generic_arraycopy (debug build) incorrectly uses rscratch2. The convention in AArch64 HotSpot is that rscratch1 and rscratch2 are scratch in all assembler macros. Any caller must therefore not expect these scratch registers to be preserved across macros. In this case, the caller is the generic_arraycopy stub, and this stub is called using the native calling convention, so we don't need to use rscratch2. We have many spare registers to choose from, and I have chosen to use the first free argument register. Although the bug is present in all AArch64 versions of HotSpot, it only affects debug builds because rscratch2 is only used inside code guarded by #ifndef PRODUCT. So, I'm not thinking there's any need for a backport. http://cr.openjdk.java.net/~aph/8219006/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From igor.ignatyev at oracle.com Thu Feb 14 18:37:58 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 14 Feb 2019 10:37:58 -0800 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes -- Igor > On Feb 14, 2019, at 5:20 AM, Volker Simonis wrote: > > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. From igor.ignatyev at oracle.com Thu Feb 14 18:38:37 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 14 Feb 2019 10:38:37 -0800 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <2D681EBA-3B9B-4B20-A7F5-E818B101A616@oracle.com> Vote: yes -- Igor > On Feb 14, 2019, at 5:24 AM, Volker Simonis wrote: > > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. From aph at redhat.com Thu Feb 14 18:43:27 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Feb 2019 18:43:27 +0000 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: Vote: yes On 2/14/19 1:24 PM, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc > -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From karen.kinnear at oracle.com Thu Feb 14 22:11:23 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 14 Feb 2019 17:11:23 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> <78b0d148-e1fc-7700-c25f-836d5bb38465@oracle.com> Message-ID: Robbin, Went over V06_2_u1 and it looks good to me too. This is a major improvement! Many thanks! Thank you for adding so many assertions and comments. I don?t need to see a new webrev Minor comments interfaceSupport.inline.hpp 319: ?enought? -> ?enough? Safepoint.cpp line 760 ?should have already have? -> ?should already have? thank you so much! Karen > On Feb 12, 2019, at 7:38 AM, David Holmes wrote: > > Hi Robbin, > > I've gone through v06_2_u1 one more time and overall I think things generally look good. > > One or two nits on naming but nothing worth haggling over :) > > Thanks, > David > > On 12/02/2019 7:28 am, David Holmes wrote: >> On 12/02/2019 6:14 am, Robbin Ehn wrote: >>> Hi all, >>> >>> Updated of v2: >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/full/ >>> (open.changeset still two patches, e.g. if you look at interfaceSupport.inline.hpp it's patched twice) >> Simplified version: >> http://cr.openjdk.java.net/~dholmes/8203469/webrev.v06_2_u1/ >> David >> ----- >>> Inc: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/inc/ >>> >>> Passes several hours more stress testing and t1-5, KS 24H stress still running. >>> >>> I did update alternative one also with Dan's feedback, and it also still passes stress tests and t1-5. >>> I'll leave that unpublished since we are focusing on this version where we can get some simplifications. >>> >>> Thanks, Robbin >>> >>> On 2019-02-07 17:05, Robbin Ehn wrote: >>>> Hi all, here is the promised re-base (v06) on >>>> 8210832: Remove sneaky locking in class Monitor. >>>> >>>> v06_1 is just a straight re-base. >>>> >>>> Full: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >>>> Inc: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >>>> >>>> Passes stress test and t1-5. >>>> >>>> But there is a 'better' way. >>>> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >>>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >>>> back-off as the rolling forward loop. It turns out that we mostly never spin >>>> here at all, when all java threads are stop the callbacks is often already done. >>>> So the addition of the semaphore have no impact on our benchmarks and is mostly >>>> unused. This is because most threads are in java which we need to spin-wait >>>> since they can elide into native without doing a callback. My proposed re-base >>>> removes the the callbacks completely and let the vm thread do all thread >>>> accounting. All that the stopping threads needs to do is write state and >>>> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >>>> a local store per thread against doing 2 stores per thread by the vm thread. >>>> This makes it possible for a thread in vm to transition into blocked WITHOUT >>>> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >>>> leaving that state. >>>> >>>> v06_2 >>>> Full: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>>> Inc against v05: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>>> Inc against v06_1: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>>> >>>> v06_2 simplifies and removes ~200 LOC with same performance. >>>> If there is a case with a thread in vm taking long time, it will already >>>> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >>>> see no reason why we should not push v06_2. >>>> >>>> Passes stress test and t1-5. >>>> >>>> Thanks, Robbin >>>> >>>> >>>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>>> Hi all, please review. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>>> >>>>> Thanks to Dan for pre-reviewing a lot! >>>>> >>>>> Background: >>>>> ZGC often does very short safepoint operations. For a perspective, in a >>>>> specJBB2015 run, G1 can have young collection stops lasting about 170 ms. While >>>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >>>>> operation it is. The time it takes to stop and start the JavaThreads is relative >>>>> very large to a ZGC safepoint. With an operation that just takes 0.2ms the >>>>> overhead of stopping and starting JavaThreads is several times the operation. >>>>> >>>>> High-level functionality change: >>>>> Serializing the starting over Threads_lock takes time. >>>>> - Don't wait on Threads_lock use the WaitBarrier. >>>>> Serializing the stopping over Safepoint_lock takes time. >>>>> - Let threads stop in parallel, remove Safepoint_lock. >>>>> >>>>> Details: >>>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>>> - Safe means the JavaThread will not touch Java heap or VM internal structures >>>>> without doing a transition and block before doing so. >>>>> - The safe states are: >>>>> - When polls armed: _thread_in_native and _thread_blocked. >>>>> - When Threads_lock is held: externally suspended flag is set. >>>>> - VM Thread have polls armed and holds the Threads_lock during a >>>>> safepoint. >>>>> - Unsafe means that either Java heap or VM internal structures can be accessed >>>>> by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>>> - All combination that are not safe are unsafe. >>>>> >>>>> We cannot start a safepoint until all unsafe threads have transitioned to a safe >>>>> state. To make them safe, we arm polls in compiled code and make sure any >>>>> transition to another unsafe state will be blocked. JavaThreads which are unsafe >>>>> with state _thread_in_Java may transition to _thread_in_native without being >>>>> blocked, since it just became a safe thread and we can proceed. Any safe thread >>>>> may try to transition at any time to an unsafe state, thus coming into the >>>>> safepoint blocking code at any moment, e.g., after the safepoint is over, or >>>>> even at the beginning of next safepoint. >>>>> >>>>> The VMThread cannot tolerate false positives from the JavaThread thread state >>>>> because that would mean starting the safepoint without all JavaThreads being >>>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we never observe >>>>> false positives from the safepoint blocking code, if we remove them, how do we >>>>> handle false positives? >>>>> >>>>> By first publishing which barrier tag (safepoint counter) we will call >>>>> WaitBarrier.wait() with as the threads safepoint id and then change the state to >>>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of >>>>> the state. A stable load of the thread state is successful if the thread >>>>> safepoint id is the same both before and after the load of the state and >>>>> safepoint id is current or InactiveSafepointCounter. If the stable load fails, >>>>> the thread is considered safepoint unsafe. It's no longer enough that thread is >>>>> have state _thread_blocked it must also have correct safepoint id before and >>>>> after we read the state. >>>>> >>>>> Performance: >>>>> The result of faster safepoints is that the average CPU time for JavaThreads >>>>> between safepoints is higher, thus increasing the allocation rate. The thread >>>>> that stops first waits shorter time until it gets started. Even the thread that >>>>> stops last also have shorter stop since we start them faster. If your >>>>> application is using a concurrent GC it may need re-tunning since each java >>>>> worker thread have an increased CPU time/allocation rate. Often this means max >>>>> performance is achieved using slightly less java worker threads than before. >>>>> Also the increase allocation rate means shorter time between GC safepoints. >>>>> - If you are using a non-concurrent GC, you should see improved latency and >>>>> throughput. >>>>> - After re-tunning with a concurrent GC throughput should be equal or better but >>>>> with better latency. But bear in mind this is a latency patch, not a >>>>> throughput one. >>>>> With current code a java thread is not to guarantee to run between safepoint (in >>>>> theory a java thread can be starved indefinitely), since the VM thread may >>>>> re-grab the Threads_locks before it woke up from previous safepoint. If the >>>>> GC/VM don't respect MMU (minimum mutator utilization) or if your machine is very >>>>> over-provisioned this can happen. >>>>> The current schema thus re-safepoint quickly if the java threads have not >>>>> started yet at the cost of latency. Since the new code uses the WaitBarrier with >>>>> the safepoint counter, all threads must roll forward to next safepoint by >>>>> getting at least some CPU time between two safepoints. Meaning MMU violations >>>>> are more obvious. >>>>> >>>>> Some examples on numbers: >>>>> - On a 16 strand machine synchronization and un-synchronization/starting is at >>>>> least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and >>>>> starting ~400->~100us. >>>>> (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). >>>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>>> synchronization time on 16 strands and ~5% score increase. In this case the GC >>>>> op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. >>>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>>> >>>>> Thanks, Robbin From daniel.daugherty at oracle.com Thu Feb 14 22:49:18 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 14 Feb 2019 17:49:18 -0500 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> References: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> Message-ID: <5454f122-450b-af59-819c-8a840369370f@oracle.com> On 2/11/19 3:14 PM, Robbin Ehn wrote: > Hi all, > > Updated of v2: > Full: > http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/full/ > (open.changeset still two patches, e.g. if you look at > interfaceSupport.inline.hpp it's patched twice) > Inc: > http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/inc/ src/hotspot/share/runtime/interfaceSupport.inline.hpp ??? L317: ??? // All unsafe states are treated the same. ??? L318: ??? // We do not need to go to _thread_in_vm_trans. ??? L319: ??? // Since we don't read poll, it's enought to order the stores. ??????? Please consider this version: ????????????? // All unsafe states are treated the same by the VMThread ????????????? // so we can skip the _thread_in_vm_trans state here. Since ????????????? // we don't read poll, it's enough to order the stores. src/hotspot/share/runtime/safepoint.cpp ??? No comments. src/hotspot/share/runtime/safepoint.hpp ??? No comments. Thumbs up. Dan > > Passes several hours more stress testing and t1-5, KS 24H stress still > running. > > I did update alternative one also with Dan's feedback, and it also > still passes stress tests and t1-5. > I'll leave that unpublished since we are focusing on this version > where we can get some simplifications. > > Thanks, Robbin > > On 2019-02-07 17:05, Robbin Ehn wrote: >> Hi all, here is the promised re-base (v06) on >> 8210832: Remove sneaky locking in class Monitor. >> >> v06_1 is just a straight re-base. >> >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >> Inc: >> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >> >> Passes stress test and t1-5. >> >> But there is a 'better' way. >> Before I added the more graceful "_vm_wait->wait();" semaphore in the >> while >> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >> back-off as the rolling forward loop. It turns out that we mostly >> never spin >> here at all, when all java threads are stop the callbacks is often >> already done. >> So the addition of the semaphore have no impact on our benchmarks and >> is mostly >> unused. This is because most threads are in java which we need to >> spin-wait >> since they can elide into native without doing a callback. My >> proposed re-base >> removes the the callbacks completely and let the vm thread do all thread >> accounting. All that the stopping threads needs to do is write state and >> safepoint id, everything else is handle by the vm thread. We trade 2 >> atomics + >> a local store per thread against doing 2 stores per thread by the vm >> thread. >> This makes it possible for a thread in vm to transition into blocked >> WITHOUT >> safepoint poll. Just set thread_blocked and promise to do safepoint >> poll when >> leaving that state. >> >> v06_2 >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >> Inc against v05: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >> Inc against v06_1: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >> >> v06_2 simplifies and removes ~200 LOC with same performance. >> If there is a case with a thread in vm taking long time, it will already >> screw-up latency and thus should be fixed regardless of v06_1 vs >> v06_2. So I >> see no reason why we should not push v06_2. >> >> Passes stress test and t1-5. >> >> Thanks, Robbin >> >> >> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>> Hi all, please review. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>> >>> Thanks to Dan for pre-reviewing a lot! >>> >>> Background: >>> ZGC often does very short safepoint operations. For a perspective, in a >>> specJBB2015 run, G1 can have young collection stops lasting about >>> 170 ms. While >>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on >>> which >>> operation it is. The time it takes to stop and start the JavaThreads >>> is relative >>> very large to a ZGC safepoint. With an operation that just takes >>> 0.2ms the >>> overhead of stopping and starting JavaThreads is several times the >>> operation. >>> >>> High-level functionality change: >>> Serializing the starting over Threads_lock takes time. >>> - Don't wait on Threads_lock use the WaitBarrier. >>> Serializing the stopping over Safepoint_lock takes time. >>> - Let threads stop in parallel, remove Safepoint_lock. >>> >>> Details: >>> JavaThreads have 2 abstract logical states: unsafe or safe. >>> - Safe means the JavaThread will not touch Java heap or VM internal >>> structures >>> ?? without doing a transition and block before doing so. >>> ???????? - The safe states are: >>> ???????????????? - When polls armed: _thread_in_native and >>> _thread_blocked. >>> ???????????????? - When Threads_lock is held: externally suspended >>> flag is set. >>> ???????? - VM Thread have polls armed and holds the Threads_lock >>> during a >>> ?????????? safepoint. >>> - Unsafe means that either Java heap or VM internal structures can >>> be accessed >>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>> ???????? - All combination that are not safe are unsafe. >>> >>> We cannot start a safepoint until all unsafe threads have >>> transitioned to a safe >>> state. To make them safe, we arm polls in compiled code and make >>> sure any >>> transition to another unsafe state will be blocked. JavaThreads >>> which are unsafe >>> with state _thread_in_Java may transition to _thread_in_native >>> without being >>> blocked, since it just became a safe thread and we can proceed. Any >>> safe thread >>> may try to transition at any time to an unsafe state, thus coming >>> into the >>> safepoint blocking code at any moment, e.g., after the safepoint is >>> over, or >>> even at the beginning of next safepoint. >>> >>> The VMThread cannot tolerate false positives from the JavaThread >>> thread state >>> because that would mean starting the safepoint without all >>> JavaThreads being >>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we >>> never observe >>> false positives from the safepoint blocking code, if we remove them, >>> how do we >>> handle false positives? >>> >>> By first publishing which barrier tag (safepoint counter) we will call >>> WaitBarrier.wait() with as the threads safepoint id and then change >>> the state to >>> _thread_blocked, the VMThread can ignore JavaThreads by doing a >>> stable load of >>> the state. A stable load of the thread state is successful if the >>> thread >>> safepoint id is the same both before and after the load of the state >>> and >>> safepoint id is current or InactiveSafepointCounter. If the stable >>> load fails, >>> the thread is considered safepoint unsafe. It's no longer enough >>> that thread is >>> have state _thread_blocked it must also have correct safepoint id >>> before and >>> after we read the state. >>> >>> Performance: >>> The result of faster safepoints is that the average CPU time for >>> JavaThreads >>> between safepoints is higher, thus increasing the allocation rate. >>> The thread >>> that stops first waits shorter time until it gets started. Even the >>> thread that >>> stops last also have shorter stop since we start them faster. If your >>> application is using a concurrent GC it may need re-tunning since >>> each java >>> worker thread have an increased CPU time/allocation rate. Often this >>> means max >>> performance is achieved using slightly less java worker threads than >>> before. >>> Also the increase allocation rate means shorter time between GC >>> safepoints. >>> - If you are using a non-concurrent GC, you should see improved >>> latency and >>> ?? throughput. >>> - After re-tunning with a concurrent GC throughput should be equal >>> or better but >>> ?? with better latency. But bear in mind this is a latency patch, not a >>> ?? throughput one. >>> With current code a java thread is not to guarantee to run between >>> safepoint (in >>> theory a java thread can be starved indefinitely), since the VM >>> thread may >>> re-grab the Threads_locks before it woke up from previous safepoint. >>> If the >>> GC/VM don't respect MMU (minimum mutator utilization) or if your >>> machine is very >>> over-provisioned this can happen. >>> The current schema thus re-safepoint quickly if the java threads >>> have not >>> started yet at the cost of latency. Since the new code uses the >>> WaitBarrier with >>> the safepoint counter, all threads must roll forward to next >>> safepoint by >>> getting at least some CPU time between two safepoints. Meaning MMU >>> violations >>> are more obvious. >>> >>> Some examples on numbers: >>> - On a 16 strand machine synchronization and >>> un-synchronization/starting is at >>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> >>> ~100us and >>> ?? starting ~400->~100us. >>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on >>> Linux). >>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>> ?? synchronization time on 16 strands and ~5% score increase. In >>> this case the GC >>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% >>> to 10%. >>> - specJBB2015 ParGC ~9% increase in critical-jops. >>> >>> Thanks, Robbin From kim.barrett at oracle.com Thu Feb 14 22:53:19 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 14 Feb 2019 17:53:19 -0500 Subject: RFR: 8214363: HeapWord should not be a fake class Message-ID: <26DCA5CE-96D9-43AE-9DF3-854CC4C404E3@oracle.com> Please review this change to the definitions of HeapWord and MetaWord. They are no longer a class type. Rather, they are typedefs for a pointer to associated incomplete (and never defined) helper classes. Thus, we no longer pretend to have class objects where they never existed. Among other things, this makes memset on a HeapWord[] no longer trigger gcc8's new -Wclass-memaccess in ObjectStartArray::set_covered_region(). Other than the change to the definitions of HeapWord and MetaWord, most of the changes are removal of no longer valid forward class declarations for those types. CR: https://bugs.openjdk.java.net/browse/JDK-8214363 Webrev: http://cr.openjdk.java.net/~kbarrett/8214363/open.02/ Testing: mach5 tier1-3. Built using gcc8.2 and verified there is no longer a -Wclass-memaccess warning from objectStartArray.cpp. From david.holmes at oracle.com Fri Feb 15 01:38:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2019 11:38:51 +1000 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <59b41e94-6ff3-a2c6-4709-6d7a1b0b65a6@oracle.com> Vote: yes David On 14/02/2019 11:24 pm, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc > From david.holmes at oracle.com Fri Feb 15 01:39:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Feb 2019 11:39:03 +1000 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <5a046fac-6016-1ac1-57ce-09c06a03347f@oracle.com> Vote: yes David On 14/02/2019 11:20 pm, Volker Simonis wrote: > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc > From tobias.hartmann at oracle.com Fri Feb 15 08:02:21 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Feb 2019 09:02:21 +0100 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 14.02.19 14:20, Volker Simonis wrote: > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc > From tobias.hartmann at oracle.com Fri Feb 15 08:02:27 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Feb 2019 09:02:27 +0100 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 14.02.19 14:24, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc > From robbin.ehn at oracle.com Fri Feb 15 09:07:52 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 15 Feb 2019 10:07:52 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: References: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> <78b0d148-e1fc-7700-c25f-836d5bb38465@oracle.com> Message-ID: <8910e433-e233-c702-1a8b-f2938ed9e207@oracle.com> Hi Karen, On 2/14/19 11:11 PM, Karen Kinnear wrote: > Robbin, > > Went over V06_2_u1 and it looks good to me too. This is a major improvement! Many thanks! > Thank you for adding so many assertions and comments. > I don?t need to see a new webrev > > Minor comments > > interfaceSupport.inline.hpp > 319: ?enought? -> ?enough? > > Safepoint.cpp line 760 > ?should have already have? -> ?should already have? Fixed! > > thank you so much! > Karen Thanks, Robbin > >> On Feb 12, 2019, at 7:38 AM, David Holmes wrote: >> >> Hi Robbin, >> >> I've gone through v06_2_u1 one more time and overall I think things generally look good. >> >> One or two nits on naming but nothing worth haggling over :) >> >> Thanks, >> David >> >> On 12/02/2019 7:28 am, David Holmes wrote: >>> On 12/02/2019 6:14 am, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Updated of v2: >>>> Full: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/full/ >>>> (open.changeset still two patches, e.g. if you look at interfaceSupport.inline.hpp it's patched twice) >>> Simplified version: >>> http://cr.openjdk.java.net/~dholmes/8203469/webrev.v06_2_u1/ >>> David >>> ----- >>>> Inc: >>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/inc/ >>>> >>>> Passes several hours more stress testing and t1-5, KS 24H stress still running. >>>> >>>> I did update alternative one also with Dan's feedback, and it also still passes stress tests and t1-5. >>>> I'll leave that unpublished since we are focusing on this version where we can get some simplifications. >>>> >>>> Thanks, Robbin >>>> >>>> On 2019-02-07 17:05, Robbin Ehn wrote: >>>>> Hi all, here is the promised re-base (v06) on >>>>> 8210832: Remove sneaky locking in class Monitor. >>>>> >>>>> v06_1 is just a straight re-base. >>>>> >>>>> Full: >>>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >>>>> Inc: >>>>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >>>>> >>>>> Passes stress test and t1-5. >>>>> >>>>> But there is a 'better' way. >>>>> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >>>>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >>>>> back-off as the rolling forward loop. It turns out that we mostly never spin >>>>> here at all, when all java threads are stop the callbacks is often already done. >>>>> So the addition of the semaphore have no impact on our benchmarks and is mostly >>>>> unused. This is because most threads are in java which we need to spin-wait >>>>> since they can elide into native without doing a callback. My proposed re-base >>>>> removes the the callbacks completely and let the vm thread do all thread >>>>> accounting. All that the stopping threads needs to do is write state and >>>>> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >>>>> a local store per thread against doing 2 stores per thread by the vm thread. >>>>> This makes it possible for a thread in vm to transition into blocked WITHOUT >>>>> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >>>>> leaving that state. >>>>> >>>>> v06_2 >>>>> Full: >>>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>>>> Inc against v05: >>>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>>>> Inc against v06_1: >>>>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>>>> >>>>> v06_2 simplifies and removes ~200 LOC with same performance. >>>>> If there is a case with a thread in vm taking long time, it will already >>>>> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >>>>> see no reason why we should not push v06_2. >>>>> >>>>> Passes stress test and t1-5. >>>>> >>>>> Thanks, Robbin >>>>> >>>>> >>>>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>>>> Hi all, please review. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>>>> >>>>>> Thanks to Dan for pre-reviewing a lot! >>>>>> >>>>>> Background: >>>>>> ZGC often does very short safepoint operations. For a perspective, in a >>>>>> specJBB2015 run, G1 can have young collection stops lasting about 170 ms. While >>>>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >>>>>> operation it is. The time it takes to stop and start the JavaThreads is relative >>>>>> very large to a ZGC safepoint. With an operation that just takes 0.2ms the >>>>>> overhead of stopping and starting JavaThreads is several times the operation. >>>>>> >>>>>> High-level functionality change: >>>>>> Serializing the starting over Threads_lock takes time. >>>>>> - Don't wait on Threads_lock use the WaitBarrier. >>>>>> Serializing the stopping over Safepoint_lock takes time. >>>>>> - Let threads stop in parallel, remove Safepoint_lock. >>>>>> >>>>>> Details: >>>>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>>>> - Safe means the JavaThread will not touch Java heap or VM internal structures >>>>>> without doing a transition and block before doing so. >>>>>> - The safe states are: >>>>>> - When polls armed: _thread_in_native and _thread_blocked. >>>>>> - When Threads_lock is held: externally suspended flag is set. >>>>>> - VM Thread have polls armed and holds the Threads_lock during a >>>>>> safepoint. >>>>>> - Unsafe means that either Java heap or VM internal structures can be accessed >>>>>> by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>>>> - All combination that are not safe are unsafe. >>>>>> >>>>>> We cannot start a safepoint until all unsafe threads have transitioned to a safe >>>>>> state. To make them safe, we arm polls in compiled code and make sure any >>>>>> transition to another unsafe state will be blocked. JavaThreads which are unsafe >>>>>> with state _thread_in_Java may transition to _thread_in_native without being >>>>>> blocked, since it just became a safe thread and we can proceed. Any safe thread >>>>>> may try to transition at any time to an unsafe state, thus coming into the >>>>>> safepoint blocking code at any moment, e.g., after the safepoint is over, or >>>>>> even at the beginning of next safepoint. >>>>>> >>>>>> The VMThread cannot tolerate false positives from the JavaThread thread state >>>>>> because that would mean starting the safepoint without all JavaThreads being >>>>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we never observe >>>>>> false positives from the safepoint blocking code, if we remove them, how do we >>>>>> handle false positives? >>>>>> >>>>>> By first publishing which barrier tag (safepoint counter) we will call >>>>>> WaitBarrier.wait() with as the threads safepoint id and then change the state to >>>>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of >>>>>> the state. A stable load of the thread state is successful if the thread >>>>>> safepoint id is the same both before and after the load of the state and >>>>>> safepoint id is current or InactiveSafepointCounter. If the stable load fails, >>>>>> the thread is considered safepoint unsafe. It's no longer enough that thread is >>>>>> have state _thread_blocked it must also have correct safepoint id before and >>>>>> after we read the state. >>>>>> >>>>>> Performance: >>>>>> The result of faster safepoints is that the average CPU time for JavaThreads >>>>>> between safepoints is higher, thus increasing the allocation rate. The thread >>>>>> that stops first waits shorter time until it gets started. Even the thread that >>>>>> stops last also have shorter stop since we start them faster. If your >>>>>> application is using a concurrent GC it may need re-tunning since each java >>>>>> worker thread have an increased CPU time/allocation rate. Often this means max >>>>>> performance is achieved using slightly less java worker threads than before. >>>>>> Also the increase allocation rate means shorter time between GC safepoints. >>>>>> - If you are using a non-concurrent GC, you should see improved latency and >>>>>> throughput. >>>>>> - After re-tunning with a concurrent GC throughput should be equal or better but >>>>>> with better latency. But bear in mind this is a latency patch, not a >>>>>> throughput one. >>>>>> With current code a java thread is not to guarantee to run between safepoint (in >>>>>> theory a java thread can be starved indefinitely), since the VM thread may >>>>>> re-grab the Threads_locks before it woke up from previous safepoint. If the >>>>>> GC/VM don't respect MMU (minimum mutator utilization) or if your machine is very >>>>>> over-provisioned this can happen. >>>>>> The current schema thus re-safepoint quickly if the java threads have not >>>>>> started yet at the cost of latency. Since the new code uses the WaitBarrier with >>>>>> the safepoint counter, all threads must roll forward to next safepoint by >>>>>> getting at least some CPU time between two safepoints. Meaning MMU violations >>>>>> are more obvious. >>>>>> >>>>>> Some examples on numbers: >>>>>> - On a 16 strand machine synchronization and un-synchronization/starting is at >>>>>> least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and >>>>>> starting ~400->~100us. >>>>>> (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). >>>>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>>>> synchronization time on 16 strands and ~5% score increase. In this case the GC >>>>>> op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. >>>>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>>>> >>>>>> Thanks, Robbin > From robbin.ehn at oracle.com Fri Feb 15 09:09:38 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 15 Feb 2019 10:09:38 +0100 Subject: RFR(XL): 8203469: Faster safepoints In-Reply-To: <5454f122-450b-af59-819c-8a840369370f@oracle.com> References: <0b8c389b-6a35-892a-9a17-79d4734095a5@oracle.com> <5454f122-450b-af59-819c-8a840369370f@oracle.com> Message-ID: <34da9dff-b0cd-c74b-8457-d524c6875d88@oracle.com> Hi Dan, On 2/14/19 11:49 PM, Daniel D. Daugherty wrote: > On 2/11/19 3:14 PM, Robbin Ehn wrote: >> Hi all, >> >> Updated of v2: >> Full: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/full/ >> (open.changeset still two patches, e.g. if you look at >> interfaceSupport.inline.hpp it's patched twice) >> Inc: >> http://cr.openjdk.java.net/~rehn/8203469/v06_2_u1/inc/ > > src/hotspot/share/runtime/interfaceSupport.inline.hpp > ??? L317: ??? // All unsafe states are treated the same. > ??? L318: ??? // We do not need to go to _thread_in_vm_trans. > ??? L319: ??? // Since we don't read poll, it's enought to order the stores. > ??????? Please consider this version: > > ????????????? // All unsafe states are treated the same by the VMThread > ????????????? // so we can skip the _thread_in_vm_trans state here. Since > ????????????? // we don't read poll, it's enough to order the stores. > Fixed! > src/hotspot/share/runtime/safepoint.cpp > ??? No comments. > > src/hotspot/share/runtime/safepoint.hpp > ??? No comments. > > Thumbs up. Thanks, Robbin > > Dan > > > >> >> Passes several hours more stress testing and t1-5, KS 24H stress still running. >> >> I did update alternative one also with Dan's feedback, and it also still >> passes stress tests and t1-5. >> I'll leave that unpublished since we are focusing on this version where we can >> get some simplifications. >> >> Thanks, Robbin >> >> On 2019-02-07 17:05, Robbin Ehn wrote: >>> Hi all, here is the promised re-base (v06) on >>> 8210832: Remove sneaky locking in class Monitor. >>> >>> v06_1 is just a straight re-base. >>> >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/full/ >>> Inc: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_1/inc/ >>> >>> Passes stress test and t1-5. >>> >>> But there is a 'better' way. >>> Before I added the more graceful "_vm_wait->wait();" semaphore in the while >>> (_waiting_to_block > 0) { loop, it was a just a busy spin using the same >>> back-off as the rolling forward loop. It turns out that we mostly never spin >>> here at all, when all java threads are stop the callbacks is often already done. >>> So the addition of the semaphore have no impact on our benchmarks and is mostly >>> unused. This is because most threads are in java which we need to spin-wait >>> since they can elide into native without doing a callback. My proposed re-base >>> removes the the callbacks completely and let the vm thread do all thread >>> accounting. All that the stopping threads needs to do is write state and >>> safepoint id, everything else is handle by the vm thread. We trade 2 atomics + >>> a local store per thread against doing 2 stores per thread by the vm thread. >>> This makes it possible for a thread in vm to transition into blocked WITHOUT >>> safepoint poll. Just set thread_blocked and promise to do safepoint poll when >>> leaving that state. >>> >>> v06_2 >>> Full: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/full/ >>> Inc against v05: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/inc/ >>> Inc against v06_1: >>> http://cr.openjdk.java.net/~rehn/8203469/v06_2/rebase_inc/ >>> >>> v06_2 simplifies and removes ~200 LOC with same performance. >>> If there is a case with a thread in vm taking long time, it will already >>> screw-up latency and thus should be fixed regardless of v06_1 vs v06_2. So I >>> see no reason why we should not push v06_2. >>> >>> Passes stress test and t1-5. >>> >>> Thanks, Robbin >>> >>> >>> On 1/15/19 11:39 AM, Robbin Ehn wrote: >>>> Hi all, please review. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203469 >>>> Code: http://cr.openjdk.java.net/~rehn/8203469/v00/webrev/ >>>> >>>> Thanks to Dan for pre-reviewing a lot! >>>> >>>> Background: >>>> ZGC often does very short safepoint operations. For a perspective, in a >>>> specJBB2015 run, G1 can have young collection stops lasting about 170 ms. While >>>> in the same setup ZGC does 0.2ms to 1.5 ms operations depending on which >>>> operation it is. The time it takes to stop and start the JavaThreads is >>>> relative >>>> very large to a ZGC safepoint. With an operation that just takes 0.2ms the >>>> overhead of stopping and starting JavaThreads is several times the operation. >>>> >>>> High-level functionality change: >>>> Serializing the starting over Threads_lock takes time. >>>> - Don't wait on Threads_lock use the WaitBarrier. >>>> Serializing the stopping over Safepoint_lock takes time. >>>> - Let threads stop in parallel, remove Safepoint_lock. >>>> >>>> Details: >>>> JavaThreads have 2 abstract logical states: unsafe or safe. >>>> - Safe means the JavaThread will not touch Java heap or VM internal structures >>>> ?? without doing a transition and block before doing so. >>>> ???????? - The safe states are: >>>> ???????????????? - When polls armed: _thread_in_native and _thread_blocked. >>>> ???????????????? - When Threads_lock is held: externally suspended flag is set. >>>> ???????? - VM Thread have polls armed and holds the Threads_lock during a >>>> ?????????? safepoint. >>>> - Unsafe means that either Java heap or VM internal structures can be accessed >>>> ?? by the JavaThread, e.g., _thread_in_Java, _thread_in_vm. >>>> ???????? - All combination that are not safe are unsafe. >>>> >>>> We cannot start a safepoint until all unsafe threads have transitioned to a >>>> safe >>>> state. To make them safe, we arm polls in compiled code and make sure any >>>> transition to another unsafe state will be blocked. JavaThreads which are >>>> unsafe >>>> with state _thread_in_Java may transition to _thread_in_native without being >>>> blocked, since it just became a safe thread and we can proceed. Any safe thread >>>> may try to transition at any time to an unsafe state, thus coming into the >>>> safepoint blocking code at any moment, e.g., after the safepoint is over, or >>>> even at the beginning of next safepoint. >>>> >>>> The VMThread cannot tolerate false positives from the JavaThread thread state >>>> because that would mean starting the safepoint without all JavaThreads being >>>> safe. The two locks (Threads_lock and Safepoint_lock) make sure we never >>>> observe >>>> false positives from the safepoint blocking code, if we remove them, how do we >>>> handle false positives? >>>> >>>> By first publishing which barrier tag (safepoint counter) we will call >>>> WaitBarrier.wait() with as the threads safepoint id and then change the >>>> state to >>>> _thread_blocked, the VMThread can ignore JavaThreads by doing a stable load of >>>> the state. A stable load of the thread state is successful if the thread >>>> safepoint id is the same both before and after the load of the state and >>>> safepoint id is current or InactiveSafepointCounter. If the stable load fails, >>>> the thread is considered safepoint unsafe. It's no longer enough that thread is >>>> have state _thread_blocked it must also have correct safepoint id before and >>>> after we read the state. >>>> >>>> Performance: >>>> The result of faster safepoints is that the average CPU time for JavaThreads >>>> between safepoints is higher, thus increasing the allocation rate. The thread >>>> that stops first waits shorter time until it gets started. Even the thread that >>>> stops last also have shorter stop since we start them faster. If your >>>> application is using a concurrent GC it may need re-tunning since each java >>>> worker thread have an increased CPU time/allocation rate. Often this means max >>>> performance is achieved using slightly less java worker threads than before. >>>> Also the increase allocation rate means shorter time between GC safepoints. >>>> - If you are using a non-concurrent GC, you should see improved latency and >>>> ?? throughput. >>>> - After re-tunning with a concurrent GC throughput should be equal or better >>>> but >>>> ?? with better latency. But bear in mind this is a latency patch, not a >>>> ?? throughput one. >>>> With current code a java thread is not to guarantee to run between safepoint >>>> (in >>>> theory a java thread can be starved indefinitely), since the VM thread may >>>> re-grab the Threads_locks before it woke up from previous safepoint. If the >>>> GC/VM don't respect MMU (minimum mutator utilization) or if your machine is >>>> very >>>> over-provisioned this can happen. >>>> The current schema thus re-safepoint quickly if the java threads have not >>>> started yet at the cost of latency. Since the new code uses the WaitBarrier >>>> with >>>> the safepoint counter, all threads must roll forward to next safepoint by >>>> getting at least some CPU time between two safepoints. Meaning MMU violations >>>> are more obvious. >>>> >>>> Some examples on numbers: >>>> - On a 16 strand machine synchronization and un-synchronization/starting is at >>>> ?? least 3x faster (in non-trivial test). Synchronization ~600 -> ~100us and >>>> ?? starting ~400->~100us. >>>> ?? (Semaphore path is a bit slower than futex in the WaitBarrier on Linux). >>>> - SPECjvm2008 serial (untuned G1) gives 10x (1 ms vs 100 us) faster >>>> ?? synchronization time on 16 strands and ~5% score increase. In this case >>>> the GC >>>> ?? op is 1ms, so we reduce the overhead of synchronization from 100% to 10%. >>>> - specJBB2015 ParGC ~9% increase in critical-jops. >>>> >>>> Thanks, Robbin > From stefan.karlsson at oracle.com Fri Feb 15 09:43:11 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 15 Feb 2019 10:43:11 +0100 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <439321c5-84e5-199f-738c-ae0dd5f1a879@oracle.com> Vote: yes StefanK On 2019-02-14 14:20, Volker Simonis wrote: > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc > From stefan.karlsson at oracle.com Fri Feb 15 09:43:02 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 15 Feb 2019 10:43:02 +0100 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: Vote: yes StefanK On 2019-02-14 14:24, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc > From adinn at redhat.com Fri Feb 15 10:09:22 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 15 Feb 2019 10:09:22 +0000 Subject: RFR: 8219006:AArch64: Register corruption in slow subtype check In-Reply-To: References: Message-ID: <0aee05cf-e55c-ebd0-62cc-d40837a6d967@redhat.com> On 14/02/2019 18:36, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8219006/ Reviewed. > Although the bug is present in all AArch64 versions of HotSpot, it > only affects debug builds because rscratch2 is only used inside code > guarded by #ifndef PRODUCT. So, I'm not thinking there's any need for > a backport. If you also add the qualification that the bug does not manifest very often then I'll agree to that. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martin.doerr at sap.com Fri Feb 15 10:58:18 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 15 Feb 2019 10:58:18 +0000 Subject: RFR: 8219006:AArch64: Register corruption in slow subtype check In-Reply-To: <0aee05cf-e55c-ebd0-62cc-d40837a6d967@redhat.com> References: <0aee05cf-e55c-ebd0-62cc-d40837a6d967@redhat.com> Message-ID: Hi Andrew, thanks for fixing it. Looks good to me, too. Unfortunately, we have 2 issues for this: JDK-8218670, JDK-8219006 I can close the first one as duplicate. I think we can still decide to backport it later if the issue shows up during regular testing. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Andrew Dinn Sent: Freitag, 15. Februar 2019 11:09 To: Andrew Haley ; hotspot-dev at openjdk.java.net Subject: Re: RFR: 8219006:AArch64: Register corruption in slow subtype check On 14/02/2019 18:36, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8219006/ Reviewed. > Although the bug is present in all AArch64 versions of HotSpot, it > only affects debug builds because rscratch2 is only used inside code > guarded by #ifndef PRODUCT. So, I'm not thinking there's any need for > a backport. If you also add the qualification that the bug does not manifest very often then I'll agree to that. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thomas.schatzl at oracle.com Fri Feb 15 12:58:27 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 15 Feb 2019 13:58:27 +0100 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: <26DCA5CE-96D9-43AE-9DF3-854CC4C404E3@oracle.com> References: <26DCA5CE-96D9-43AE-9DF3-854CC4C404E3@oracle.com> Message-ID: Hi Kim, On Thu, 2019-02-14 at 17:53 -0500, Kim Barrett wrote: > Please review this change to the definitions of HeapWord and > MetaWord. > They are no longer a class type. Rather, they are typedefs for a > pointer to associated incomplete (and never defined) helper classes. > Thus, we no longer pretend to have class objects where they never > existed. > > Among other things, this makes memset on a HeapWord[] no longer > trigger gcc8's new -Wclass-memaccess in > ObjectStartArray::set_covered_region(). > > Other than the change to the definitions of HeapWord and MetaWord, > most of the changes are removal of no longer valid forward class > declarations for those types. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8214363 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8214363/open.02/ > > Testing: > mach5 tier1-3. > Built using gcc8.2 and verified there is no longer a -Wclass- > memaccess warning from objectStartArray.cpp. looks good. Thanks. Thomas From aph at redhat.com Fri Feb 15 13:38:33 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 Feb 2019 13:38:33 +0000 Subject: RFR: 8219006:AArch64: Register corruption in slow subtype check In-Reply-To: <0aee05cf-e55c-ebd0-62cc-d40837a6d967@redhat.com> References: <0aee05cf-e55c-ebd0-62cc-d40837a6d967@redhat.com> Message-ID: On 2/15/19 10:09 AM, Andrew Dinn wrote: > On 14/02/2019 18:36, Andrew Haley wrote: >> http://cr.openjdk.java.net/~aph/8219006/ > Reviewed. > >> Although the bug is present in all AArch64 versions of HotSpot, it >> only affects debug builds because rscratch2 is only used inside code >> guarded by #ifndef PRODUCT. So, I'm not thinking there's any need for >> a backport. > > If you also add the qualification that the bug does not manifest very > often then I'll agree to that. I'll add the qualification that it was hell's own difficult even to reproduce it repeatably. It took me all afternoon. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From markus.gronlund at oracle.com Fri Feb 15 18:44:05 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 15 Feb 2019 18:44:05 +0000 (UTC) Subject: CFV: New HotSpot Group Member: Erik Gahlin Message-ID: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Greetings, I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. Votes are due by March 1, 2019, 20:00 CET. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() From markus.gronlund at oracle.com Fri Feb 15 18:45:04 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 15 Feb 2019 18:45:04 +0000 (UTC) Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <2e3a63c9-201b-43f4-b29f-9074b4b35fac@default> Vote: yes Markus -----Original Message----- From: Volker Simonis Sent: den 14 februari 2019 14:25 To: HotSpot Open Source Developers Subject: CFV: New hotspot Group Member: Martin Doerr I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to Membership in the HotSpot Group. Martin is one of the initial authors of the ppc64 port, a jdk project Reviewer and long term OpenJDK Contributor. Since 2014 he has contributed more than 112 changes [3] and reviewed more than 154 [4]. Votes are due by February 28, 2019, 18:00 CET. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. With best regards, Volker [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc From markus.gronlund at oracle.com Fri Feb 15 18:45:45 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 15 Feb 2019 18:45:45 +0000 (UTC) Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <9919962d-9044-41fc-bb16-62cc00048b11@default> Vote: yes Markus -----Original Message----- From: Volker Simonis Sent: den 14 februari 2019 14:20 To: HotSpot Open Source Developers Subject: CFV: New hotspot Group Member: Thomas Stuefe I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to Membership in the HotSpot Group. Thomas is one of the initial authors of the AIX/OS400 port, a jdk project Reviewer and long term OpenJDK Contributor. Since 2015 he has contributed more than 140 changes [3] and reviewed more than 240 [4] mostly in the hotspot runtime area. Votes are due by February 28, 2019, 18:00 CET. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. With best regards, Volker [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc From coleen.phillimore at oracle.com Fri Feb 15 19:11:04 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Feb 2019 14:11:04 -0500 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: Vote: yes On 2/15/19 1:44 PM, Markus Gronlund wrote: > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() From igor.ignatyev at oracle.com Fri Feb 15 19:17:24 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 15 Feb 2019 11:17:24 -0800 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <915E74FF-A2AA-4649-A7B6-FE86D544EC27@oracle.com> Vote: yes > On Feb 15, 2019, at 10:44 AM, Markus Gronlund wrote: > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. From daniel.daugherty at oracle.com Fri Feb 15 20:07:25 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Feb 2019 15:07:25 -0500 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <70f71fdf-ae75-c62d-bd1a-c91a4b0ab91f@oracle.com> Vote: yes Dan On 2/15/19 1:44 PM, Markus Gronlund wrote: > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() > From john.r.rose at oracle.com Fri Feb 15 20:20:32 2019 From: john.r.rose at oracle.com (John Rose) Date: Fri, 15 Feb 2019 12:20:32 -0800 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes From john.r.rose at oracle.com Fri Feb 15 20:21:04 2019 From: john.r.rose at oracle.com (John Rose) Date: Fri, 15 Feb 2019 12:21:04 -0800 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <1984C57F-2D91-4A7C-AAA3-676EB7AEA3DB@oracle.com> Vote: yes From kim.barrett at oracle.com Fri Feb 15 20:24:47 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 15:24:47 -0500 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: References: <26DCA5CE-96D9-43AE-9DF3-854CC4C404E3@oracle.com> Message-ID: <37D700A0-D30E-489A-A37B-03CBEE05543E@oracle.com> > On Feb 15, 2019, at 7:58 AM, Thomas Schatzl wrote: > > Hi Kim, > > On Thu, 2019-02-14 at 17:53 -0500, Kim Barrett wrote: >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8214363 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8214363/open.02/ >> >> Testing: >> mach5 tier1-3. >> Built using gcc8.2 and verified there is no longer a -Wclass- >> memaccess warning from objectStartArray.cpp. > > looks good. Thanks. > > Thomas Thanks. From kim.barrett at oracle.com Fri Feb 15 20:24:00 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 15:24:00 -0500 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <612D7C9B-4F27-4862-A3B8-361B0DFDAD80@oracle.com> vote: yes > On Feb 15, 2019, at 1:44 PM, Markus Gronlund wrote: > > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() From coleen.phillimore at oracle.com Fri Feb 15 20:27:17 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Feb 2019 15:27:17 -0500 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: References: <05E1D4C4-F08A-45A7-99B6-5F485FF2D7C1@oracle.com> Message-ID: <897c26d7-32e3-9df7-f19e-3ab535d6d573@oracle.com> moving to hotspot-dev. Coleen On 2/15/19 8:07 AM, coleen.phillimore at oracle.com wrote: > > This is nice but what does this mean? > > http://cr.openjdk.java.net/~kbarrett/8214363/open.02/src/hotspot/share/gc/shared/spaceDecorator.cpp.udiff.html > > > + return badHeapWord == (max_juint & reinterpret_cast(*q)); > > > I thought since it has no implementation class, you can't use *q ? > > http://cr.openjdk.java.net/~kbarrett/8214363/open.02/src/hotspot/share/gc/shared/vmStructs_gc.hpp.udiff.html > > > Checked SA, looks unused. Phew. > > thanks, > Coleen > > On 2/14/19 5:54 PM, Kim Barrett wrote: >> I meant to send this to hotspot-dev, not hotspot-runtime-dev.? Please >> use the other thread. >> >>> On Feb 14, 2019, at 5:04 PM, Kim Barrett >>> wrote: >>> >>> Please review this change to the definitions of HeapWord and MetaWord. >>> They are no longer a class type.? Rather, they are typedefs for a >>> pointer to associated incomplete (and never defined) helper classes. >>> Thus, we no longer pretend to have class objects where they never >>> existed. >>> >>> Among other things, this makes memset on a HeapWord[] no longer trigger >>> gcc8's new -Wclass-memaccess in ObjectStartArray::set_covered_region(). >>> >>> Other than the change to the definitions of HeapWord and MetaWord, >>> most of the changes are removal of no longer valid forward class >>> declarations for those types. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8214363 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8214363/open.02/ >>> >>> Testing: >>> mach5 tier1-3. >> > From john.r.rose at oracle.com Fri Feb 15 20:28:40 2019 From: john.r.rose at oracle.com (John Rose) Date: Fri, 15 Feb 2019 12:28:40 -0800 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <103FC3E0-2CC4-482B-891F-37509DB09709@oracle.com> Vote: yes From kim.barrett at oracle.com Fri Feb 15 20:44:31 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 15:44:31 -0500 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: <897c26d7-32e3-9df7-f19e-3ab535d6d573@oracle.com> References: <05E1D4C4-F08A-45A7-99B6-5F485FF2D7C1@oracle.com> <897c26d7-32e3-9df7-f19e-3ab535d6d573@oracle.com> Message-ID: <0ED83292-F06A-445E-BF0A-6FADD6FB8D12@oracle.com> > On Feb 15, 2019, at 3:27 PM, coleen.phillimore at oracle.com wrote: > > > moving to hotspot-dev. > Coleen > > On 2/15/19 8:07 AM, coleen.phillimore at oracle.com wrote: >> >> This is nice but what does this mean? >> >> http://cr.openjdk.java.net/~kbarrett/8214363/open.02/src/hotspot/share/gc/shared/spaceDecorator.cpp.udiff.html >> >> + return badHeapWord == (max_juint & reinterpret_cast(*q)); >> >> >> I thought since it has no implementation class, you can't use *q ? The type of q is HeapWord*, which is (with this change) HeapWordImpl**. Dereferencing q => HeapWordImpl*, which is then cast to a uintptr_t. A pretty similar effect could have been achieved by changing HeapWord to struct HeapWord { HeapWordImpl* value; }; e.g. making the member public (to eliminate the new gcc warning) and changing the pointee type of the member to an incomplete type (to prevent dereference). From mikael.vidstedt at oracle.com Fri Feb 15 21:13:43 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 13:13:43 -0800 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: <0ED83292-F06A-445E-BF0A-6FADD6FB8D12@oracle.com> References: <05E1D4C4-F08A-45A7-99B6-5F485FF2D7C1@oracle.com> <897c26d7-32e3-9df7-f19e-3ab535d6d573@oracle.com> <0ED83292-F06A-445E-BF0A-6FADD6FB8D12@oracle.com> Message-ID: <2F41F7FB-99ED-4E67-80AC-DBB612B80943@oracle.com> > On Feb 15, 2019, at 12:44 PM, Kim Barrett wrote: > >> On Feb 15, 2019, at 3:27 PM, coleen.phillimore at oracle.com wrote: >> >> >> moving to hotspot-dev. >> Coleen >> >> On 2/15/19 8:07 AM, coleen.phillimore at oracle.com wrote: >>> >>> This is nice but what does this mean? >>> >>> http://cr.openjdk.java.net/~kbarrett/8214363/open.02/src/hotspot/share/gc/shared/spaceDecorator.cpp.udiff.html >>> >>> + return badHeapWord == (max_juint & reinterpret_cast(*q)); >>> >>> >>> I thought since it has no implementation class, you can't use *q ? > > The type of q is HeapWord*, which is (with this change) HeapWordImpl**. > Dereferencing q => HeapWordImpl*, which is then cast to a uintptr_t. > > A pretty similar effect could have been achieved by changing HeapWord to > struct HeapWord { HeapWordImpl* value; }; > e.g. making the member public (to eliminate the new gcc warning) and changing > the pointee type of the member to an incomplete type (to prevent dereference). I was also confused by that. Not enough to have a strong opinion though. Looks good to me. For completeness I too tried your change with gcc 8.2 and the warnings are indeed gone. Cheers, Mikael From kim.barrett at oracle.com Fri Feb 15 21:34:35 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 16:34:35 -0500 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: <2F41F7FB-99ED-4E67-80AC-DBB612B80943@oracle.com> References: <05E1D4C4-F08A-45A7-99B6-5F485FF2D7C1@oracle.com> <897c26d7-32e3-9df7-f19e-3ab535d6d573@oracle.com> <0ED83292-F06A-445E-BF0A-6FADD6FB8D12@oracle.com> <2F41F7FB-99ED-4E67-80AC-DBB612B80943@oracle.com> Message-ID: <08A59C6C-AF45-4BC8-8E10-E600B3174248@oracle.com> > On Feb 15, 2019, at 4:13 PM, Mikael Vidstedt wrote: > > > >> On Feb 15, 2019, at 12:44 PM, Kim Barrett wrote: >> >>> On Feb 15, 2019, at 3:27 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> moving to hotspot-dev. >>> Coleen >>> >>> On 2/15/19 8:07 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> This is nice but what does this mean? >>>> >>>> http://cr.openjdk.java.net/~kbarrett/8214363/open.02/src/hotspot/share/gc/shared/spaceDecorator.cpp.udiff.html >>>> >>>> + return badHeapWord == (max_juint & reinterpret_cast(*q)); >>>> >>>> >>>> I thought since it has no implementation class, you can't use *q ? >> >> The type of q is HeapWord*, which is (with this change) HeapWordImpl**. >> Dereferencing q => HeapWordImpl*, which is then cast to a uintptr_t. >> >> A pretty similar effect could have been achieved by changing HeapWord to >> struct HeapWord { HeapWordImpl* value; }; >> e.g. making the member public (to eliminate the new gcc warning) and changing >> the pointee type of the member to an incomplete type (to prevent dereference). > > I was also confused by that. Not enough to have a strong opinion though. > > Looks good to me. For completeness I too tried your change with gcc 8.2 and the warnings are indeed gone. > > Cheers, > Mikael I thought about adding ?uintptr_t heap_word_value(HeapWord*)?, but it didn?t seem worth the trouble for a single caller. If that would have helped? From mikael.vidstedt at oracle.com Fri Feb 15 21:36:29 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 13:36:29 -0800 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: <08A59C6C-AF45-4BC8-8E10-E600B3174248@oracle.com> References: <05E1D4C4-F08A-45A7-99B6-5F485FF2D7C1@oracle.com> <897c26d7-32e3-9df7-f19e-3ab535d6d573@oracle.com> <0ED83292-F06A-445E-BF0A-6FADD6FB8D12@oracle.com> <2F41F7FB-99ED-4E67-80AC-DBB612B80943@oracle.com> <08A59C6C-AF45-4BC8-8E10-E600B3174248@oracle.com> Message-ID: I wouldn?t be against that. :) Cheers, Mikael > On Feb 15, 2019, at 1:34 PM, Kim Barrett wrote: > >> On Feb 15, 2019, at 4:13 PM, Mikael Vidstedt wrote: >> >> >> >>> On Feb 15, 2019, at 12:44 PM, Kim Barrett wrote: >>> >>>> On Feb 15, 2019, at 3:27 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> moving to hotspot-dev. >>>> Coleen >>>> >>>> On 2/15/19 8:07 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> This is nice but what does this mean? >>>>> >>>>> http://cr.openjdk.java.net/~kbarrett/8214363/open.02/src/hotspot/share/gc/shared/spaceDecorator.cpp.udiff.html >>>>> >>>>> + return badHeapWord == (max_juint & reinterpret_cast(*q)); >>>>> >>>>> >>>>> I thought since it has no implementation class, you can't use *q ? >>> >>> The type of q is HeapWord*, which is (with this change) HeapWordImpl**. >>> Dereferencing q => HeapWordImpl*, which is then cast to a uintptr_t. >>> >>> A pretty similar effect could have been achieved by changing HeapWord to >>> struct HeapWord { HeapWordImpl* value; }; >>> e.g. making the member public (to eliminate the new gcc warning) and changing >>> the pointee type of the member to an incomplete type (to prevent dereference). >> >> I was also confused by that. Not enough to have a strong opinion though. >> >> Looks good to me. For completeness I too tried your change with gcc 8.2 and the warnings are indeed gone. >> >> Cheers, >> Mikael > > I thought about adding ?uintptr_t heap_word_value(HeapWord*)?, but it didn?t seem worth > the trouble for a single caller. If that would have helped? > From mikael.vidstedt at oracle.com Fri Feb 15 21:50:03 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 13:50:03 -0800 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes Cheers, Mikael > On Feb 14, 2019, at 5:20 AM, Volker Simonis wrote: > > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc From mikael.vidstedt at oracle.com Fri Feb 15 21:53:16 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 13:53:16 -0800 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <869A153C-0F70-4EFC-BBDE-6483685550D7@oracle.com> Vote: yes Cheers, Mikael > On Feb 14, 2019, at 5:24 AM, Volker Simonis wrote: > > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc From mikael.vidstedt at oracle.com Fri Feb 15 21:54:38 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 15 Feb 2019 13:54:38 -0800 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <9F605D96-6511-457A-8E44-7A08E2F031F6@oracle.com> Vote: yes Cheers, Mikael > On Feb 15, 2019, at 10:44 AM, Markus Gronlund wrote: > > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() From karen.kinnear at oracle.com Fri Feb 15 21:57:49 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 15 Feb 2019 16:57:49 -0500 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: Vote: yes Thanks, Karen > On Feb 15, 2019, at 1:44 PM, Markus Gronlund wrote: > > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() From coleen.phillimore at oracle.com Fri Feb 15 22:41:39 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Feb 2019 17:41:39 -0500 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: References: <05E1D4C4-F08A-45A7-99B6-5F485FF2D7C1@oracle.com> <897c26d7-32e3-9df7-f19e-3ab535d6d573@oracle.com> <0ED83292-F06A-445E-BF0A-6FADD6FB8D12@oracle.com> <2F41F7FB-99ED-4E67-80AC-DBB612B80943@oracle.com> <08A59C6C-AF45-4BC8-8E10-E600B3174248@oracle.com> Message-ID: I don't think heap_word_value() is necesary.? I was just missing a "*" in that expression.? It's not dereferencing an opaque type. LGTM! thanks, Coleen On 2/15/19 4:36 PM, Mikael Vidstedt wrote: > I wouldn?t be against that. :) > > Cheers, > Mikael > >> On Feb 15, 2019, at 1:34 PM, Kim Barrett wrote: >> >>> On Feb 15, 2019, at 4:13 PM, Mikael Vidstedt wrote: >>> >>> >>> >>>> On Feb 15, 2019, at 12:44 PM, Kim Barrett wrote: >>>> >>>>> On Feb 15, 2019, at 3:27 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> moving to hotspot-dev. >>>>> Coleen >>>>> >>>>> On 2/15/19 8:07 AM, coleen.phillimore at oracle.com wrote: >>>>>> This is nice but what does this mean? >>>>>> >>>>>> http://cr.openjdk.java.net/~kbarrett/8214363/open.02/src/hotspot/share/gc/shared/spaceDecorator.cpp.udiff.html >>>>>> >>>>>> + return badHeapWord == (max_juint & reinterpret_cast(*q)); >>>>>> >>>>>> >>>>>> I thought since it has no implementation class, you can't use *q ? >>>> The type of q is HeapWord*, which is (with this change) HeapWordImpl**. >>>> Dereferencing q => HeapWordImpl*, which is then cast to a uintptr_t. >>>> >>>> A pretty similar effect could have been achieved by changing HeapWord to >>>> struct HeapWord { HeapWordImpl* value; }; >>>> e.g. making the member public (to eliminate the new gcc warning) and changing >>>> the pointee type of the member to an incomplete type (to prevent dereference). >>> I was also confused by that. Not enough to have a strong opinion though. >>> >>> Looks good to me. For completeness I too tried your change with gcc 8.2 and the warnings are indeed gone. >>> >>> Cheers, >>> Mikael >> I thought about adding ?uintptr_t heap_word_value(HeapWord*)?, but it didn?t seem worth >> the trouble for a single caller. If that would have helped? >> From jesper.wilhelmsson at oracle.com Fri Feb 15 23:44:16 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Sat, 16 Feb 2019 00:44:16 +0100 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <1DBB6D7B-D2BE-4CD1-94E4-F57207798B7F@oracle.com> Vote: Yes /Jesper > On 15 Feb 2019, at 19:44, Markus Gronlund wrote: > > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() From kim.barrett at oracle.com Sat Feb 16 00:56:28 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 15 Feb 2019 19:56:28 -0500 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: References: <05E1D4C4-F08A-45A7-99B6-5F485FF2D7C1@oracle.com> <897c26d7-32e3-9df7-f19e-3ab535d6d573@oracle.com> <0ED83292-F06A-445E-BF0A-6FADD6FB8D12@oracle.com> <2F41F7FB-99ED-4E67-80AC-DBB612B80943@oracle.com> <08A59C6C-AF45-4BC8-8E10-E600B3174248@oracle.com> Message-ID: > On Feb 15, 2019, at 5:41 PM, coleen.phillimore at oracle.com wrote: > > > I don't think heap_word_value() is necesary. I was just missing a "*" in that expression. It's not dereferencing an opaque type. > LGTM! Thanks. From vladimir.kozlov at oracle.com Sat Feb 16 01:36:20 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Feb 2019 17:36:20 -0800 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: Vote: yes On 2/15/19 10:44 AM, Markus Gronlund wrote: > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() > From david.holmes at oracle.com Sat Feb 16 03:58:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Feb 2019 13:58:25 +1000 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <2b4d5e91-cae8-343d-72f3-0716cec5a162@oracle.com> Vote: yes David On 16/02/2019 4:44 am, Markus Gronlund wrote: > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() > From fanjinke at hygon.cn Sat Feb 16 05:18:27 2019 From: fanjinke at hygon.cn (Jinke Fan) Date: Sat, 16 Feb 2019 13:18:27 +0800 Subject: [PATCH]: Add Hygon Dhyana support In-Reply-To: <943f9a61-3fc2-bd13-b249-c16c4546e0b9@hygon.cn> References: <943f9a61-3fc2-bd13-b249-c16c4546e0b9@hygon.cn> Message-ID: <3796ec0d-cebb-a746-71cb-61e659c6515f@hygon.cn> Hello All, This patch is used to support Hygon Dhyana x86 vendor id (HygonGenuine). As Hygon Dhyana share most architecture feature as AMD Family 17h, the patch adds Hygon CPU Vendor ID to check for reused AMD code paths. Background: Chengdu Haiguang IC Design Co., Ltd (Hygon) is a Joint Venture between AMD and Haiguang Information Technology Co.,Ltd., aims at providing high performance x86 processor for China server market. Its first generation processor codename is Dhyana, which originates from AMD technology and shares most of the architecture with AMD's family 17h, but with different CPU Vendor ID("HygonGenuine")/Family series number(Family 18h). The patch is based on the original repository: hg.openjdk.java.net/jdk/jdk changeset: 53783:72709e703abd tag: tip user: mbalao date: Fri Feb 15 11:46:15 2019 -0300 summary: 8219011: Implement MacroAssembler::warn method on AArch64 Please help me with the commit process. Thank you very much! *patch Webrev: https://fjkbo.github.io/openjdk/webrev/index.html The output of hg diff -g: diff --git a/src/hotspot/cpu/x86/assembler_x86.cpp b/src/hotspot/cpu/x86/assembler_x86.cpp --- a/src/hotspot/cpu/x86/assembler_x86.cpp +++ b/src/hotspot/cpu/x86/assembler_x86.cpp @@ -3099,7 +3099,7 @@ } return; } - if (UseAddressNop && VM_Version::is_amd()) { + if (UseAddressNop && (VM_Version::is_amd() || VM_Version::is_hygon())) { // // Using multi-bytes nops "0x0F 0x1F [address]" for AMD. // 1: 0x90 diff --git a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_ext_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_ext_x86.cpp @@ -340,6 +340,10 @@ return !is_amd_Barcelona(); } + if (is_hygon()) { + return true; + } + return false; } diff --git a/src/hotspot/cpu/x86/vm_version_x86.cpp b/src/hotspot/cpu/x86/vm_version_x86.cpp --- a/src/hotspot/cpu/x86/vm_version_x86.cpp +++ b/src/hotspot/cpu/x86/vm_version_x86.cpp @@ -1161,7 +1161,7 @@ } } - if( is_amd() ) { // AMD cpus specific settings + if( is_amd() || is_hygon() ) { // AMD cpus specific settings if( supports_sse2() && FLAG_IS_DEFAULT(UseAddressNop) ) { // Use it on new AMD cpus starting from Opteron. UseAddressNop = true; @@ -1235,8 +1235,8 @@ } #endif // COMPILER2 - // Some defaults for AMD family 17h - if ( cpu_family() == 0x17 ) { + // Some defaults for AMD family 17h || Hygon family 18h + if ( cpu_family() == 0x17 || cpu_family() == 0x18 ) { // On family 17h processors use XMM and UnalignedLoadStores for Array Copy if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); diff --git a/src/hotspot/cpu/x86/vm_version_x86.hpp b/src/hotspot/cpu/x86/vm_version_x86.hpp --- a/src/hotspot/cpu/x86/vm_version_x86.hpp +++ b/src/hotspot/cpu/x86/vm_version_x86.hpp @@ -495,13 +495,13 @@ result |= CPU_CX8; if (_cpuid_info.std_cpuid1_edx.bits.cmov != 0) result |= CPU_CMOV; - if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || (is_amd() && + if (_cpuid_info.std_cpuid1_edx.bits.fxsr != 0 || ((is_amd() || is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.fxsr != 0)) result |= CPU_FXSR; // HT flag is set for multi-core processors also. if (threads_per_core() > 1) result |= CPU_HT; - if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || (is_amd() && + if (_cpuid_info.std_cpuid1_edx.bits.mmx != 0 || ((is_amd() || is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx != 0)) result |= CPU_MMX; if (_cpuid_info.std_cpuid1_edx.bits.sse != 0) @@ -576,8 +576,8 @@ if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) result |= CPU_FMA; - // AMD features. - if (is_amd()) { + // AMD|Hygon features. + if (is_amd() || is_hygon()) { if ((_cpuid_info.ext_cpuid1_edx.bits.tdnow != 0) || (_cpuid_info.ext_cpuid1_ecx.bits.prefetchw != 0)) result |= CPU_3DNOW_PREFETCH; @@ -711,6 +711,7 @@ static int cpu_family() { return _cpu;} static bool is_P6() { return cpu_family() >= 6; } static bool is_amd() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x68747541; } // 'htuA' + static bool is_hygon() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x6F677948; } // 'ogyH' static bool is_intel() { assert_is_initialized(); return _cpuid_info.std_vendor_name_0 == 0x756e6547; } // 'uneG' static bool is_zx() { assert_is_initialized(); return (_cpuid_info.std_vendor_name_0 == 0x746e6543) || (_cpuid_info.std_vendor_name_0 == 0x68532020); } // 'tneC'||'hS ' static bool is_atom_family() { return ((cpu_family() == 0x06) && ((extended_cpu_model() == 0x36) || (extended_cpu_model() == 0x37) || (extended_cpu_model() == 0x4D))); } //Silvermont and Centerton @@ -734,7 +735,7 @@ if (!supports_topology || result == 0) { result = (_cpuid_info.dcp_cpuid4_eax.bits.cores_per_cpu + 1); } - } else if (is_amd()) { + } else if (is_amd() || is_hygon()) { result = (_cpuid_info.ext_cpuid8_ecx.bits.cores_per_cpu + 1); } else if (is_zx()) { bool supports_topology = supports_processor_topology(); @@ -770,7 +771,7 @@ intx result = 0; if (is_intel()) { result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); - } else if (is_amd()) { + } else if (is_amd() || is_hygon()) { result = _cpuid_info.ext_cpuid5_ecx.bits.L1_line_size; } else if (is_zx()) { result = (_cpuid_info.dcp_cpuid4_ebx.bits.L1_line_size + 1); @@ -857,7 +858,7 @@ // AMD features static bool supports_3dnow_prefetch() { return (_features & CPU_3DNOW_PREFETCH) != 0; } - static bool supports_mmx_ext() { return is_amd() && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } + static bool supports_mmx_ext() { return (is_amd()||is_hygon()) && _cpuid_info.ext_cpuid1_edx.bits.mmx_amd != 0; } static bool supports_lzcnt() { return (_features & CPU_LZCNT) != 0; } static bool supports_sse4a() { return (_features & CPU_SSE4A) != 0; } @@ -870,7 +871,7 @@ } static bool supports_tscinv() { return supports_tscinv_bit() && - ( (is_amd() && !is_amd_Barcelona()) || + ( ((is_amd()||is_hygon()) && !is_amd_Barcelona()) || is_intel_tsc_synched_at_init() ); } @@ -896,7 +897,7 @@ // Core - 256 / prefetchnta // It will be used only when AllocatePrefetchStyle > 0 - if (is_amd()) { // AMD + if (is_amd() || is_hygon()) { // AMD if (supports_sse2()) { return 256; // Opteron } else { *test I tested it with jtreg and found no regressions. Base Run? ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1364 1363 1 0 << >> jtreg:test/jdk:tier1 1877 1876 1 0 << >> jtreg:test/langtools:tier1 3985 3984 1 0 << jtreg:test/nashorn:tier1 0 0 0 0 jtreg:test/jaxp:tier1 0 0 0 0 ============================== TEST FAILURE And The result of after patching is the same as the before. ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:test/hotspot/jtreg:tier1 1364 1363 1 0 << >> jtreg:test/jdk:tier1 1877 1876 1 0 << >> jtreg:test/langtools:tier1 3985 3984 1 0 << jtreg:test/nashorn:tier1 0 0 0 0 jtreg:test/jaxp:tier1 0 0 0 0 ============================== TEST FAILURE Is there anything incorrectly? Please let me know your comments. Best Regards! Fanjinke. From tobias.hartmann at oracle.com Mon Feb 18 07:46:59 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 18 Feb 2019 08:46:59 +0100 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <5499b518-173a-f5cc-6595-713837003b1f@oracle.com> Vote: yes Best regards, Tobias On 15.02.19 19:44, Markus Gronlund wrote: > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() > From matthias.baesken at sap.com Mon Feb 18 08:47:49 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 18 Feb 2019 08:47:49 +0000 Subject: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark Message-ID: Hello, please review this small fix. It adds missing 2 times a missing ResouceMark in s390x specific coding (there are 2 name_and_sig_as_C_string() calls in frame_s390.cpp that miss a ResourceMark ). Bug/webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8219112.0/ https://bugs.openjdk.java.net/browse/JDK-8219112 Thanks , Matthias From volker.simonis at gmail.com Mon Feb 18 09:19:26 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Feb 2019 10:19:26 +0100 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: Vote: yes On Fri, Feb 15, 2019 at 7:46 PM Markus Gronlund wrote: > > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() From per.liden at oracle.com Mon Feb 18 11:50:59 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 18 Feb 2019 12:50:59 +0100 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <047abcca-dd47-9e6b-d4b7-48b73155c2bf@oracle.com> Vote: yes /Per On 02/15/2019 07:44 PM, Markus Gronlund wrote: > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() > From per.liden at oracle.com Mon Feb 18 11:53:55 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 18 Feb 2019 12:53:55 +0100 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <3d849607-5fc3-526c-6c50-a840daa2152d@oracle.com> Vote: yes /Per On 02/14/2019 02:20 PM, Volker Simonis wrote: > I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to > Membership in the HotSpot Group. > > Thomas is one of the initial authors of the AIX/OS400 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2015 he has > contributed more than 140 changes [3] and reviewed more than 240 [4] > mostly in the hotspot runtime area. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc > From per.liden at oracle.com Mon Feb 18 11:51:55 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 18 Feb 2019 12:51:55 +0100 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <79bf7015-b48b-9ba4-d979-c14a713c27cf@oracle.com> Vote: yes /Per On 02/14/2019 02:24 PM, Volker Simonis wrote: > I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to > Membership in the HotSpot Group. > > Martin is one of the initial authors of the ppc64 port, a jdk > project Reviewer and long term OpenJDK Contributor. Since 2014 he has > contributed more than 112 changes [3] and reviewed more than 154 [4]. > > Votes are due by February 28, 2019, 18:00 CET. > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > With best regards, > Volker > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 > [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc > From per.liden at oracle.com Mon Feb 18 11:56:22 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 18 Feb 2019 12:56:22 +0100 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: <26DCA5CE-96D9-43AE-9DF3-854CC4C404E3@oracle.com> References: <26DCA5CE-96D9-43AE-9DF3-854CC4C404E3@oracle.com> Message-ID: <9c0f0081-8c97-2ce4-9faf-a97b7e0f70c5@oracle.com> On 02/14/2019 11:53 PM, Kim Barrett wrote: > Please review this change to the definitions of HeapWord and MetaWord. > They are no longer a class type. Rather, they are typedefs for a > pointer to associated incomplete (and never defined) helper classes. > Thus, we no longer pretend to have class objects where they never > existed. > > Among other things, this makes memset on a HeapWord[] no longer trigger > gcc8's new -Wclass-memaccess in ObjectStartArray::set_covered_region(). > > Other than the change to the definitions of HeapWord and MetaWord, > most of the changes are removal of no longer valid forward class > declarations for those types. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8214363 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8214363/open.02/ Looks good! /Per > > Testing: > mach5 tier1-3. > Built using gcc8.2 and verified there is no longer a -Wclass-memaccess > warning from objectStartArray.cpp. > From shade at redhat.com Mon Feb 18 11:55:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Feb 2019 12:55:19 +0100 Subject: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark In-Reply-To: References: Message-ID: <51dbe5cb-3fe2-a1d8-f2ce-aeaefd37ae17@redhat.com> On 2/18/19 9:47 AM, Baesken, Matthias wrote: > Bug/webrev : > http://cr.openjdk.java.net/~mbaesken/webrevs/8219112.0/ Looks good and trivial. -Aleksey From erik.osterlund at oracle.com Mon Feb 18 12:01:22 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 18 Feb 2019 13:01:22 +0100 Subject: RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean Message-ID: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> Hi, When transitioning CompiledICs to clean, we sometimes need to use transitional states (using JIT-compiled ICStubs). The trick is that today when we clean ICs, we atomically and logically write NULL to the data section, and set the destination to some resolve stub. In reality, the NULL gets translated to Universe::non_oop_word. But the point is that in order to set both data and destination atomically, we use an ICStub. ...but we don't need to set them both. When the inline cache is cleaned, the data part is no longer relevant, and could really be set to any nonsense value, as long as subsequent transitions away from that cleaned inline cache (monomorphic/interpreted) uses a transitional state to do so. I suspect that at some point in time, when inline caches pointed at oops in perm gen or something, it was crucial that the data part of the inline cache made sense to the GC. This is not the case today, and we can just ignore the value pretending it doesn't exist instead. The benefit with deferring the use of transitional state to when someone performs a subsequent transition away from clean (set_to_monomorphic), is that all code paths where cleaning inline caches fail can be removed. This in particular simplifies the sweeper and ZGC nmethod unloading code, that needs to handle failures in inline cache cleaning due to running out of ICStubs forcing us to trigger safepoints to refill IC stubs. It should also reduce the overall number of safepoints due to running out of ICStubs. Bug: https://bugs.openjdk.java.net/browse/JDK-8219101 Webrev: http://cr.openjdk.java.net/~eosterlund/8219101/webrev.00/ Testing: mach5 hs-tier1-5. Thanks, /Erik From lutz.schmidt at sap.com Mon Feb 18 13:19:38 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 18 Feb 2019 13:19:38 +0000 Subject: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark In-Reply-To: <51dbe5cb-3fe2-a1d8-f2ce-aeaefd37ae17@redhat.com> References: <51dbe5cb-3fe2-a1d8-f2ce-aeaefd37ae17@redhat.com> Message-ID: <39667789-4678-4F1F-8DAC-20146F7E74F2@sap.com> Hi Matthias, looks good, and useful. Trivial anyway. Please note: I'm not a reviewer. Thanks, Lutz ?On 18.02.19, 12:55, "hotspot-dev on behalf of Aleksey Shipilev" wrote: On 2/18/19 9:47 AM, Baesken, Matthias wrote: > Bug/webrev : > http://cr.openjdk.java.net/~mbaesken/webrevs/8219112.0/ Looks good and trivial. -Aleksey From matthias.baesken at sap.com Mon Feb 18 13:40:18 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 18 Feb 2019 13:40:18 +0000 Subject: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark In-Reply-To: <51dbe5cb-3fe2-a1d8-f2ce-aeaefd37ae17@redhat.com> References: <51dbe5cb-3fe2-a1d8-f2ce-aeaefd37ae17@redhat.com> Message-ID: Hi Aleksey and Lutz , thanks for the reviews. One (maybe stupid) general question - is there an easy way to find out all locations of missing ResourceMark usages ? Currently it looks to me like a very error prone process . The name_and_sig_as_C_string() issue in this CR seems to be an easy and simple case . But in other cases it is (for me at least) not so easy to say - is the ResourceMark missing or is it somewhere located in the calling functions ? One example : src/hotspot/cpu/ppc/nativeInst_ppc.cpp 363 void NativeGeneralJump::insert_unconditional(address code_pos, address entry) { 364 CodeBuffer cb(code_pos, BytesPerInstWord + 1); 365 MacroAssembler* a = new MacroAssembler(&cb); 366 a->b(entry); 367 ICache::ppc64_flush_icache_bytes(code_pos, NativeGeneralJump::instruction_size); 368 } Do we need the ResouceMark here or not ? Best regards, Matthias > -----Original Message----- > From: Aleksey Shipilev > Sent: Montag, 18. Februar 2019 12:55 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: RFR [XS] : 8219112: name_and_sig_as_C_string usages in > frame_s390 miss ResourceMark > > On 2/18/19 9:47 AM, Baesken, Matthias wrote: > > Bug/webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219112.0/ > > Looks good and trivial. > > -Aleksey From per.liden at oracle.com Mon Feb 18 14:40:36 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 18 Feb 2019 15:40:36 +0100 Subject: RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean In-Reply-To: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> References: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> Message-ID: On 02/18/2019 01:01 PM, Erik ?sterlund wrote: > Hi, > > When transitioning CompiledICs to clean, we sometimes need to use > transitional states (using JIT-compiled ICStubs). > The trick is that today when we clean ICs, we atomically and logically > write NULL to the data section, and set the destination to some resolve > stub. In reality, the NULL gets translated to Universe::non_oop_word. > But the point is that in order to set both data and destination > atomically, we use an ICStub. > > ...but we don't need to set them both. > > When the inline cache is cleaned, the data part is no longer relevant, > and could really be set to any nonsense value, as long as subsequent > transitions away from that cleaned inline cache > (monomorphic/interpreted) uses a transitional state to do so. > I suspect that at some point in time, when inline caches pointed at oops > in perm gen or something, it was crucial that the data part of the > inline cache made sense to the GC. This is not the case today, and we > can just ignore the value pretending it doesn't exist instead. > > The benefit with deferring the use of transitional state to when someone > performs a subsequent transition away from clean (set_to_monomorphic), > is that all code paths where cleaning inline caches fail can be removed. > This in particular simplifies the sweeper and ZGC nmethod unloading > code, that needs to handle failures in inline cache cleaning due to > running out of ICStubs forcing us to trigger safepoints to refill IC > stubs. It should also reduce the overall number of safepoints due to > running out of ICStubs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219101 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8219101/webrev.00/ Not a complete review, but the ZGC change looks awesome ;) /Per > > Testing: mach5 hs-tier1-5. > > Thanks, > /Erik From martin.doerr at sap.com Mon Feb 18 14:52:21 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Feb 2019 14:52:21 +0000 Subject: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark In-Reply-To: References: <51dbe5cb-3fe2-a1d8-f2ce-aeaefd37ae17@redhat.com> Message-ID: Hi Matthias, we would get "fatal error: memory leak: allocating without ResourceMark" in the debug build if there was no ResourceMark at all on the stack. However, the existing one may be at a bad position where its scope never gets left and the resources never get freed. This situation can't get detected automatically. In the example below (nativeInst_ppc.cpp), I think we should add one. At least, I couldn't find one at a good place. Yes, the current process is error prone. ResourceMarks can also easily get placed at wrong positions leading to "assert... re-allocated with a different ResourceMark". Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Baesken, Matthias Sent: Montag, 18. Februar 2019 14:40 To: Aleksey Shipilev ; 'hotspot-dev at openjdk.java.net' Subject: RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark Hi Aleksey and Lutz , thanks for the reviews. One (maybe stupid) general question - is there an easy way to find out all locations of missing ResourceMark usages ? Currently it looks to me like a very error prone process . The name_and_sig_as_C_string() issue in this CR seems to be an easy and simple case . But in other cases it is (for me at least) not so easy to say - is the ResourceMark missing or is it somewhere located in the calling functions ? One example : src/hotspot/cpu/ppc/nativeInst_ppc.cpp 363 void NativeGeneralJump::insert_unconditional(address code_pos, address entry) { 364 CodeBuffer cb(code_pos, BytesPerInstWord + 1); 365 MacroAssembler* a = new MacroAssembler(&cb); 366 a->b(entry); 367 ICache::ppc64_flush_icache_bytes(code_pos, NativeGeneralJump::instruction_size); 368 } Do we need the ResouceMark here or not ? Best regards, Matthias > -----Original Message----- > From: Aleksey Shipilev > Sent: Montag, 18. Februar 2019 12:55 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: RFR [XS] : 8219112: name_and_sig_as_C_string usages in > frame_s390 miss ResourceMark > > On 2/18/19 9:47 AM, Baesken, Matthias wrote: > > Bug/webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219112.0/ > > Looks good and trivial. > > -Aleksey From erik.osterlund at oracle.com Mon Feb 18 15:22:30 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 18 Feb 2019 16:22:30 +0100 Subject: RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean In-Reply-To: References: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> Message-ID: <61628e88-f653-72b2-6233-00569b6aea7a@oracle.com> Hi Per, Thanks for the partial review! /Erik On 2019-02-18 15:40, Per Liden wrote: > On 02/18/2019 01:01 PM, Erik ?sterlund wrote: >> Hi, >> >> When transitioning CompiledICs to clean, we sometimes need to use >> transitional states (using JIT-compiled ICStubs). >> The trick is that today when we clean ICs, we atomically and >> logically write NULL to the data section, and set the destination to >> some resolve stub. In reality, the NULL gets translated to >> Universe::non_oop_word. But the point is that in order to set both >> data and destination atomically, we use an ICStub. >> >> ...but we don't need to set them both. >> >> When the inline cache is cleaned, the data part is no longer >> relevant, and could really be set to any nonsense value, as long as >> subsequent transitions away from that cleaned inline cache >> (monomorphic/interpreted) uses a transitional state to do so. >> I suspect that at some point in time, when inline caches pointed at >> oops in perm gen or something, it was crucial that the data part of >> the inline cache made sense to the GC. This is not the case today, >> and we can just ignore the value pretending it doesn't exist instead. >> >> The benefit with deferring the use of transitional state to when >> someone performs a subsequent transition away from clean >> (set_to_monomorphic), is that all code paths where cleaning inline >> caches fail can be removed. This in particular simplifies the sweeper >> and ZGC nmethod unloading code, that needs to handle failures in >> inline cache cleaning due to running out of ICStubs forcing us to >> trigger safepoints to refill IC stubs. It should also reduce the >> overall number of safepoints due to running out of ICStubs. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8219101 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8219101/webrev.00/ > > Not a complete review, but the ZGC change looks awesome ;) > > /Per > >> >> Testing: mach5 hs-tier1-5. >> >> Thanks, >> /Erik From kim.barrett at oracle.com Mon Feb 18 20:18:09 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 18 Feb 2019 15:18:09 -0500 Subject: RFR: 8214363: HeapWord should not be a fake class In-Reply-To: <9c0f0081-8c97-2ce4-9faf-a97b7e0f70c5@oracle.com> References: <26DCA5CE-96D9-43AE-9DF3-854CC4C404E3@oracle.com> <9c0f0081-8c97-2ce4-9faf-a97b7e0f70c5@oracle.com> Message-ID: > On Feb 18, 2019, at 6:56 AM, Per Liden wrote: > > On 02/14/2019 11:53 PM, Kim Barrett wrote: >> Please review this change to the definitions of HeapWord and MetaWord. >> They are no longer a class type. Rather, they are typedefs for a >> pointer to associated incomplete (and never defined) helper classes. >> Thus, we no longer pretend to have class objects where they never >> existed. >> Among other things, this makes memset on a HeapWord[] no longer trigger >> gcc8's new -Wclass-memaccess in ObjectStartArray::set_covered_region(). >> Other than the change to the definitions of HeapWord and MetaWord, >> most of the changes are removal of no longer valid forward class >> declarations for those types. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8214363 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8214363/open.02/ > > Looks good! > > /Per > >> Testing: >> mach5 tier1-3. >> Built using gcc8.2 and verified there is no longer a -Wclass-memaccess >> warning from objectStartArray.cpp. Thanks. From ChrisPhi at LGonQn.Org Tue Feb 19 04:55:29 2019 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Mon, 18 Feb 2019 23:55:29 -0500 Subject: CFV: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: Vote: yes Cheers, Chris From david.holmes at oracle.com Tue Feb 19 05:13:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2019 15:13:11 +1000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: Message-ID: <3b65ddd4-c408-10f7-c0ab-9c256e2b42f6@oracle.com> On 15/02/2019 1:44 am, Baesken, Matthias wrote: > Hello, here is the updated webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.4/ This seems okay to me. Thanks, David ----- > Best regards, Matthias > > > > From: Baesken, Matthias > Sent: Donnerstag, 14. Februar 2019 12:43 > To: 'Thomas St?fe' > Cc: Kim Barrett ; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net > Subject: RE: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? > >> fdStream::fdStream(const char* file_name) >> >> bool _need_close; >> >> and the close() call in the constructor? > > Hi, this has nothing to do with this change. > I have very bad experience with bringing in unrelated cleanups into a change my request after request etc. > > Will remove the os::open from CompileLog::finish_log_on_error() and the whitespace stuff. > > Thanks, Matthias > > > From: Thomas St?fe > > Sent: Donnerstag, 14. Februar 2019 11:08 > To: Baesken, Matthias > > Cc: Kim Barrett >; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? > > Hi Matthias, > > fdStream: can you pls also remove: > > fdStream::fdStream(const char* file_name) > > bool _need_close; > > and the close() call in the constructor? > > -- > > CompileLog::finish_log_on_error() is also used during error reporting (see comment above the function). > > --- > > src/hotspot/share/utilities/compilerWarnings_gcc.hpp is a whitespace only change. > > -- > > Skimmed the rest and it seems ok. > > Thanks Thomas > > > > > On Thu, Feb 14, 2019 at 9:49 AM Baesken, Matthias > wrote: > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.2/ > > > * Removed my os::open changes from os_linux.cpp and vmError.cpp because of Thomas concerns > > - Removed fdStream::fdStream(const char* file_name) { ? } from ostream.cpp ; I stayed away from any more ?cleanups? to ostream , could be done in a separate change in case it is wanted > > > > > > > Best regards, Matthias > > > From: Thomas St?fe > > Sent: Mittwoch, 13. Februar 2019 17:42 > To: Baesken, Matthias > > Cc: Kim Barrett >; ioi.lam at oracle.com; hotspot-dev at openjdk.java.net > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? > > > Hi Matthias, > > On Wed, Feb 13, 2019 at 4:00 PM Baesken, Matthias > wrote: > Hi Thomas , regarding os_linux.cpp , vmError.cpp and arguments.cpp I could remove the calls to os:::open ( my first webrev did not touch os_linux.cpp because I thought there might be > reasons to omit using it there ). > > > makes sense. > > Additionally I?d remove > > fdStream::fdStream(const char* file_name) { > > Is everyone fine with this ? > > Yes, please, and you could then slim down the logic inside fdStream somewhat. Currently it has those two modes, one where he owns the file, one where not. Since we remove the former case, you can remove _needs_close and the close() call in the destructor. > > Thank you, > > Thomas > > > > * P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" > * than others and should not call upward. > > I?d even like to have a very basic layer I could reuse in the native jdk libs too ?? (separate lib). > However this is out of scope of this change . > > Best regards, Matthias > > > From: Thomas St?fe > > Sent: Mittwoch, 13. Februar 2019 12:43 > To: Baesken, Matthias >; Kim Barrett > > Cc: hotspot-dev at openjdk.java.net > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? > > > My problem with this change are potential re entrant calls which may cause crashes or deadlocks. In addition, there are dependencies on VM initialization order to consider. > > By wholesale exchanging open() with os::open(), you add dependencies to VM infrastructure at a lot of places where we did have none before. VM infrastructure which may not be reentrant and/or which may be dependent on VM initialization. > > Example: Lets say you crash in an os::open() function, enter error reporting, which calls the same os::open() function. Then you have a circularity where you may crash again or lock. > > Even if it works today: these things like to grow and bitrot. Today os::open is simple, tomorrow someone else could very well have the idea of adding hooks to os::open in the future to monitor, count, etc, and boom, you have new dependencies. > > Case in point is os::malloc() which used to be a harmless drop in malloc replacement and now is a Moloch which calls, among other things, into NMT. > > I think one has to look at every callsite in your change and determine if: > > - it runs the risk of being called recursively (e.g. anything triggered from signal handling, or a general purpose class like ostream) > - it could theoretically be called before VM initialization or argument parsing, or after cleanup > > Some examples: > > -- > > src/hotspot/os/linux/os_linux.cpp > - _print_ascii_file() is used during error reporting. > - os::get_core_path() is used during error reporting. > > -- > > src/hotspot/share/runtime/arguments.cpp > > Arguments::parse_vm_options_file(const char* file_name, ScopedVMInitArgs* vm_args) > > initialization dependency here: this gets called before all VM options are parsed, therefore I would not use VM functions which may rely on VM options. > > -- > > src/hotspot/share/utilities/ostream.cpp > > fdStream::fdStream(const char* file_name) { > - _fd = open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); > + _fd = os::open(file_name, O_WRONLY | O_CREAT | O_TRUNC, 0666); > _need_close = true; > } > > fdStream is a general purpose class and used in a lot of places, including os::abort and error reporting, so I would be against this change. However, this constructor variant is called from nowhere: I would scratch this constructor completely. That would simplify fdStream and you also can get rid of the whole _needs_close logic inside fdStream. > > Cheers, Thomas > > > P.S. what I actually think the VM needs, and what is missing, is the concept of layers - some functions are more "basic" than others and should not call upward. Examples would be logging (UL) or os::malloc(). For instance, as it is today, UL is not usable before VM initialization, and cannot be used within functions which are used by UL, e.g. os::malloc. > > > > > On Wed, Feb 13, 2019 at 11:35 AM Baesken, Matthias > wrote: > Thanks for the feedback . > Do you see any special issue with the os::open implementations that forbid usage in os::error ? > Kim what do you think ? > > I found over 80 references to os::? calls in vmError.cpp so I think it is not generally a bad thing to do it (however for course there might be functions in the os:: layer that > cause trouble in error reporting). > > > New webrev : (compilerWarnings_gcc.hpp deprecation open deprecation + vmError.cpp adjustment removed) > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.1/ > > > Best regards, Matthias > > > From: Thomas St?fe > > Sent: Mittwoch, 13. Februar 2019 10:41 > To: Baesken, Matthias > > Cc: hotspot-dev at openjdk.java.net; Kim Barrett > > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? > > Hi Matthias, > > not a full review but please do not use os::open in error reporting: > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/src/hotspot/share/utilities/vmError.cpp.udiff.html > > We should use as little as possible VM functions here, since they may be broken and/or pull other VM dependencies which may be broken or introduce circularities. > > I am not sure if the same argument holds for other call sites as well. > > Best Regards, Thomas > > > > On Tue, Feb 12, 2019 at 5:19 PM Baesken, Matthias > wrote: > Hello, here is a first webrev + bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.0/ > > https://bugs.openjdk.java.net/browse/JDK-8218811 > > The gcc deprecation attribute for open in hotspot/share/utilities/compilerWarnings_gcc.hpp is still a bit of a hack , > Maybe you have a better idea for disabling ( is there a good way to use a pragma instead of the define ) ? > > Additionally I was not 100 % sure - are there maybe a few places where we want to stay away from os::open for good reason ? > > > Best regards, Matthias > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Dienstag, 12. Februar 2019 10:17 >> To: hotspot-dev at openjdk.java.net; 'Kim Barrett' > >> Subject: 8218811: replace open by os::open in hotspot coding - was : open- >> calls in hotspot code instead of os::open ? >> >> Hi Ioi / Kim I created >> >> https://bugs.openjdk.java.net/browse/JDK-8218811 >> >> 8218811: replace open by os::open in hotspot coding >> >>> >>> Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 >>> >> >> Regarding https://bugs.openjdk.java.net/browse/JDK-8214976 >> >> >>> For functions which should never be called outside the implementation of >> the os replacement, we can use (for example) >>> >>> extern "C" int vsnprintf(char*, size_t, const char*, va_list) >>> __attribute__((__deprecated__("use os::vsnprintf"))); >>> >>> and in the definition of os::vsnprintf, locally disable the deprecation >> warning with the appropriate diagnostic #pragma. >> >> Should I add something like this for open to compilerWarnings.hpp ? >> I think if yes, I better restrict this for now to gcc . >> >> >> Best regards, Matthias >> >>> >>> Message: 4 >>> Date: Thu, 7 Feb 2019 12:40:00 -0500 >>> From: Kim Barrett > >>> To: Ioi Lam > >>> Cc: hotspot-dev developers > >>> Subject: Re: open-calls in hotspot code instead of os::open ? >>> Message-ID: <0FD37FD4-A478-4849-B474-A3A8CDCDD6D5 at oracle.com> >>> Content-Type: text/plain; charset=us-ascii >>> >>>> On Feb 6, 2019, at 9:08 AM, Ioi Lam > wrote: >>>> >>>> I think this should be fixed. >>> >>> +1 >>> >>>> BTW, is there a way to forbid all the calls to ::open()? >>> >>> Not yet, but see https://bugs.openjdk.java.net/browse/JDK-8214976 >>> >>> From ioi.lam at oracle.com Tue Feb 19 07:17:34 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 18 Feb 2019 23:17:34 -0800 Subject: CFV: New HotSpot Group Member: Calvin Cheung Message-ID: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Greetings, I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 100 changesets [3]. Votes are due by March 4, 2019, 11:30 PST. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [1]http://openjdk.java.net/census#hotspot [2]http://openjdk.java.net/groups/#member-vote [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() From david.holmes at oracle.com Tue Feb 19 07:29:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Feb 2019 17:29:58 +1000 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <17b56f97-d201-02ef-5c50-b2327fee71da@oracle.com> Vote: yes David On 19/02/2019 5:17 pm, Ioi Lam wrote: > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to > Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK > Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > > From tobias.hartmann at oracle.com Tue Feb 19 07:44:46 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 19 Feb 2019 08:44:46 +0100 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <7b56e48e-1865-c881-32a2-1d2a2c0c00dd@oracle.com> Vote: yes Best regards, Tobias On 19.02.19 08:17, Ioi Lam wrote: > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed > over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be > cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > From volker.simonis at gmail.com Tue Feb 19 08:26:07 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 19 Feb 2019 09:26:07 +0100 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: Vote: yes On Tue, Feb 19, 2019 at 8:17 AM Ioi Lam wrote: > > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > From matthias.baesken at sap.com Tue Feb 19 08:31:06 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 19 Feb 2019 08:31:06 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: <3b65ddd4-c408-10f7-c0ab-9c256e2b42f6@oracle.com> References: <3b65ddd4-c408-10f7-c0ab-9c256e2b42f6@oracle.com> Message-ID: Hi David, thanks for the review . However I had to address an issue in src/hotspot/os/linux/perfMemory_linux.cpp . There were some open calls that deal with ***directories*** , and there os::open cannot be used . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.5/ Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Dienstag, 19. Februar 2019 06:13 > To: Baesken, Matthias ; Thomas St?fe > > Cc: hotspot-dev at openjdk.java.net > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : > open-calls in hotspot code instead of os::open ? > > On 15/02/2019 1:44 am, Baesken, Matthias wrote: > > Hello, here is the updated webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.4/ > > This seems okay to me. > > Thanks, > David > ----- > > > Best regards, Matthias > > > > > > > > From: Baesken, Matthias > > Sent: Donnerstag, 14. Februar 2019 12:43 > > To: 'Thomas St?fe' > > Cc: Kim Barrett ; ioi.lam at oracle.com; hotspot- > dev at openjdk.java.net > > Subject: RE: 8218811: replace open by os::open in hotspot coding - was : > open-calls in hotspot code instead of os::open ? > > > >> fdStream::fdStream(const char* file_name) > >> > >> bool _need_close; > >> > >> and the close() call in the constructor? > > > > Hi, this has nothing to do with this change. > > I have very bad experience with bringing in unrelated cleanups into a > change my request after request etc. > > > > Will remove the os::open from CompileLog::finish_log_on_error() and > the whitespace stuff. > > > > Thanks, Matthias > > From matthias.baesken at sap.com Tue Feb 19 08:46:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 19 Feb 2019 08:46:43 +0000 Subject: NativeGeneralJump::insert_unconditional ResourceMark - was : RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark Message-ID: Hi Martin, thanks for commenting . > > In the example below (nativeInst_ppc.cpp), I think we should add one. At > least, I couldn't find one at a good place. > NativeGeneralJump::insert_unconditional for aarch64 looks similar to what we see in nativeInst_ppc.cpp , should we add a ResourceMark here as well ? (maybe someone from the aarch64 developers could comment). src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp 490void NativeGeneralJump::insert_unconditional(address code_pos, address entry) { 491 NativeGeneralJump* n_jump = (NativeGeneralJump*)code_pos; 492 493 CodeBuffer cb(code_pos, instruction_size); 494 MacroAssembler a(&cb); 495 496 a.movptr(rscratch1, (uintptr_t)entry); 497 a.br(rscratch1); 498 499 ICache::invalidate_range(code_pos, instruction_size); 500} Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 18. Februar 2019 15:52 > To: Baesken, Matthias ; Aleksey Shipilev > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in > frame_s390 miss ResourceMark > > Hi Matthias, > > we would get "fatal error: memory leak: allocating without ResourceMark" in > the debug build if there was no ResourceMark at all on the stack. However, > the existing one may be at a bad position where its scope never gets left and > the resources never get freed. This situation can't get detected > automatically. > > In the example below (nativeInst_ppc.cpp), I think we should add one. At > least, I couldn't find one at a good place. > > Yes, the current process is error prone. ResourceMarks can also easily get > placed at wrong positions leading to "assert... re-allocated with a different > ResourceMark". > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Montag, 18. Februar 2019 14:40 > To: Aleksey Shipilev ; 'hotspot-dev at openjdk.java.net' > > Subject: RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in > frame_s390 miss ResourceMark > > Hi Aleksey and Lutz , thanks for the reviews. > > > One (maybe stupid) general question - is there an easy way to find out all > locations of missing ResourceMark usages ? > Currently it looks to me like a very error prone process . > > The name_and_sig_as_C_string() issue in this CR seems to be an easy and > simple case . > > > But in other cases it is (for me at least) not so easy to say - is the > ResourceMark missing or is it somewhere located in the calling functions ? > One example : > > src/hotspot/cpu/ppc/nativeInst_ppc.cpp > > 363 void NativeGeneralJump::insert_unconditional(address code_pos, > address entry) { > 364 CodeBuffer cb(code_pos, BytesPerInstWord + 1); > 365 MacroAssembler* a = new MacroAssembler(&cb); > 366 a->b(entry); > 367 ICache::ppc64_flush_icache_bytes(code_pos, > NativeGeneralJump::instruction_size); > 368 } > > Do we need the ResouceMark here or not ? > From thomas.schatzl at oracle.com Tue Feb 19 11:47:31 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 19 Feb 2019 12:47:31 +0100 Subject: CFV: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: <20290548212e06e0adb33cc0ab8f3800a76c3103.camel@oracle.com> Vote: yes On Fri, 2019-02-15 at 18:44 +0000, Markus Gronlund wrote: > Greetings, > > I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to > Membership in the Hotspot Group. > > Erik is a member of the HotSpot Runtime group at Oracle, is a JDK > Reviewer and has contributed over 60 changesets [3]. > > Votes are due by March 1, 2019, 20:00 CET. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1] http://openjdk.java.net/census#hotspot > [2] http://openjdk.java.net/groups/#member-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() > From martin.doerr at sap.com Tue Feb 19 12:09:29 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 19 Feb 2019 12:09:29 +0000 Subject: NativeGeneralJump::insert_unconditional ResourceMark - was : RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark In-Reply-To: References: Message-ID: Hi Matthias, aarch64 looks ok. The MacroAssembler is allocated on stack. So I can't find anything which gets allocated in resource area. Actually, I think this would be a better fix for PPC64 than adding a ResourceMark (see below). Best regards, Martin diff -r 140ecd460080 src/hotspot/cpu/ppc/nativeInst_ppc.cpp --- a/src/hotspot/cpu/ppc/nativeInst_ppc.cpp Tue Feb 19 12:52:28 2019 +0100 +++ b/src/hotspot/cpu/ppc/nativeInst_ppc.cpp Tue Feb 19 12:56:50 2019 +0100 @@ -362,8 +362,8 @@ void NativeGeneralJump::insert_unconditional(address code_pos, address entry) { CodeBuffer cb(code_pos, BytesPerInstWord + 1); - MacroAssembler* a = new MacroAssembler(&cb); - a->b(entry); + MacroAssembler a(&cb); + a.b(entry); ICache::ppc64_flush_icache_bytes(code_pos, NativeGeneralJump::instruction_size); } -----Original Message----- From: Baesken, Matthias Sent: Dienstag, 19. Februar 2019 09:47 To: Doerr, Martin ; Aleksey Shipilev ; 'hotspot-dev at openjdk.java.net' Subject: NativeGeneralJump::insert_unconditional ResourceMark - was : RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss ResourceMark Hi Martin, thanks for commenting . > > In the example below (nativeInst_ppc.cpp), I think we should add one. At > least, I couldn't find one at a good place. > NativeGeneralJump::insert_unconditional for aarch64 looks similar to what we see in nativeInst_ppc.cpp , should we add a ResourceMark here as well ? (maybe someone from the aarch64 developers could comment). src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp 490void NativeGeneralJump::insert_unconditional(address code_pos, address entry) { 491 NativeGeneralJump* n_jump = (NativeGeneralJump*)code_pos; 492 493 CodeBuffer cb(code_pos, instruction_size); 494 MacroAssembler a(&cb); 495 496 a.movptr(rscratch1, (uintptr_t)entry); 497 a.br(rscratch1); 498 499 ICache::invalidate_range(code_pos, instruction_size); 500} Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 18. Februar 2019 15:52 > To: Baesken, Matthias ; Aleksey Shipilev > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in > frame_s390 miss ResourceMark > > Hi Matthias, > > we would get "fatal error: memory leak: allocating without ResourceMark" in > the debug build if there was no ResourceMark at all on the stack. However, > the existing one may be at a bad position where its scope never gets left and > the resources never get freed. This situation can't get detected > automatically. > > In the example below (nativeInst_ppc.cpp), I think we should add one. At > least, I couldn't find one at a good place. > > Yes, the current process is error prone. ResourceMarks can also easily get > placed at wrong positions leading to "assert... re-allocated with a different > ResourceMark". > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Montag, 18. Februar 2019 14:40 > To: Aleksey Shipilev ; 'hotspot-dev at openjdk.java.net' > > Subject: RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in > frame_s390 miss ResourceMark > > Hi Aleksey and Lutz , thanks for the reviews. > > > One (maybe stupid) general question - is there an easy way to find out all > locations of missing ResourceMark usages ? > Currently it looks to me like a very error prone process . > > The name_and_sig_as_C_string() issue in this CR seems to be an easy and > simple case . > > > But in other cases it is (for me at least) not so easy to say - is the > ResourceMark missing or is it somewhere located in the calling functions ? > One example : > > src/hotspot/cpu/ppc/nativeInst_ppc.cpp > > 363 void NativeGeneralJump::insert_unconditional(address code_pos, > address entry) { > 364 CodeBuffer cb(code_pos, BytesPerInstWord + 1); > 365 MacroAssembler* a = new MacroAssembler(&cb); > 366 a->b(entry); > 367 ICache::ppc64_flush_icache_bytes(code_pos, > NativeGeneralJump::instruction_size); > 368 } > > Do we need the ResouceMark here or not ? > From coleen.phillimore at oracle.com Tue Feb 19 14:06:06 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Feb 2019 09:06:06 -0500 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: Vote: yes On 2/19/19 2:17 AM, Ioi Lam wrote: > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to > Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK > Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > > From markus.gronlund at oracle.com Tue Feb 19 15:08:53 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 19 Feb 2019 07:08:53 -0800 (PST) Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <6422a217-d137-4110-b06e-0711c40b9a12@default> Vote: yes Markus -----Original Message----- From: Ioi Lam Sent: den 19 februari 2019 08:18 To: HotSpot Developers Subject: CFV: New HotSpot Group Member: Calvin Cheung Greetings, I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 100 changesets [3]. Votes are due by March 4, 2019, 11:30 PST. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [1]http://openjdk.java.net/census#hotspot [2]http://openjdk.java.net/groups/#member-vote [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() From mikael.vidstedt at oracle.com Tue Feb 19 15:48:30 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 19 Feb 2019 07:48:30 -0800 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <5B3FC6F4-4471-42FD-B84F-61B003DBE90F@oracle.com> Vote: yes Cheers, Mikael > On Feb 18, 2019, at 11:17 PM, Ioi Lam wrote: > > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > From vladimir.kozlov at oracle.com Tue Feb 19 16:33:40 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Feb 2019 08:33:40 -0800 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <48848155-ea20-5af7-39a9-490f0fd55f11@oracle.com> Vote: yes On 2/18/19 11:17 PM, Ioi Lam wrote: > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > From igor.ignatyev at oracle.com Tue Feb 19 17:19:30 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 09:19:30 -0800 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: Vote: yes -- Igor > On Feb 18, 2019, at 11:17 PM, Ioi Lam wrote: > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. From daniel.daugherty at oracle.com Tue Feb 19 17:22:32 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Feb 2019 12:22:32 -0500 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <548016a0-1585-486f-c9aa-6d59bdf2d36d@oracle.com> Vote: yes Dan On 2/19/19 2:17 AM, Ioi Lam wrote: > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to > Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK > Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > > > From kim.barrett at oracle.com Tue Feb 19 18:12:57 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 19 Feb 2019 13:12:57 -0500 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: vote: yes > On Feb 19, 2019, at 2:17 AM, Ioi Lam wrote: > > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() From karen.kinnear at oracle.com Tue Feb 19 19:12:02 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 19 Feb 2019 14:12:02 -0500 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <7b56e48e-1865-c881-32a2-1d2a2c0c00dd@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> <7b56e48e-1865-c881-32a2-1d2a2c0c00dd@oracle.com> Message-ID: <8B3D2BE2-EDD6-47BD-B2AF-C2992AB9E606@oracle.com> Vote: yes Thanks, Karen > On Feb 19, 2019, at 2:44 AM, Tobias Hartmann wrote: > > Vote: yes > > Best regards, > Tobias > >> On 19.02.19 08:17, Ioi Lam wrote: >> Greetings, >> >> I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. >> >> Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed >> over 100 changesets [3]. >> >> Votes are due by March 4, 2019, 11:30 PST. >> >> Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be >> cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Thank you >> Markus >> >> [1]http://openjdk.java.net/census#hotspot >> [2]http://openjdk.java.net/groups/#member-vote >> [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() >> From harold.seigel at oracle.com Tue Feb 19 20:49:18 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 19 Feb 2019 15:49:18 -0500 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <353767b8-54a6-db6f-25a9-2c662e725af6@redhat.com> References: <0cd0c5ff-11a5-44db-aea1-d02748b6728f@redhat.com> <5d581b70-a575-777e-0f29-8aae92cd4d93@oracle.com> <31f17b94-bb37-d404-47dc-d26fd32b1b8a@oracle.com> <943aeb27-6ab9-e0d4-2bec-f83fb10df6d7@oracle.com> <353767b8-54a6-db6f-25a9-2c662e725af6@redhat.com> Message-ID: <2e47e139-d039-ab97-c33e-8eec6f078e09@oracle.com> Hi Aleksey, >> The availability of -XX:+BytecodeVerification{Local,Remote} options does resolve my concerns, though! Good! >> Is there a way to print out the message for "replacement" options in the deprecation message? We do not plan to include the "replacement" options in the deprecation message because we are trying to discourage users from turning off verification. Thanks, Harold On 2/7/2019 8:07 AM, Aleksey Shipilev wrote: > On 2/6/19 9:46 PM, Harold Seigel wrote: >>> On 2/6/19 11:39 AM, Harold Seigel wrote: >>>> Thank you for pointing out that I had not acknowledged David's comment.? I have since entered a >>>> response pointing out that users can now use AppCDS to get their performance boost because AppCDS >>>> code is verified at archive time. >>>> >>>> Does the availability of AppCDS allay your concerns about this change? > The availability of AppCDS does not resolve my concerns: it requires additional work, has space > overheads, potential I/O overheads, etc. The availability of -XX:+BytecodeVerification{Local,Remote} > options does resolve my concerns, though! > > Is there a way to print out the message for "replacement" options in the deprecation message? > > Thanks, > -Aleksey > From harold.seigel at oracle.com Tue Feb 19 20:53:22 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 19 Feb 2019 15:53:22 -0500 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <5c5c968c.1c69fb81.e4d29.450f@mx.google.com> References: <5c5c968c.1c69fb81.e4d29.450f@mx.google.com> Message-ID: Hi Bernd, Thanks for your input. I hope that alternatives to -Xverify:none that were mentioned in previous emails for this review thread will help resolve the issues you mention below once -Xverify:none is deprecated. Thanks, Harold On 2/7/2019 3:35 PM, Bernd Eckenfels wrote: > BTW, just want to mention, we had quite some work to do to remove -verify:none from a complex application Server due to class Validation fail when the classpath (especially in OSGi) was incomplete. > > Verifying a class seems to fail if types used in the signature of the class are missing. This new requirement of validating classes is not present when verifyer is turned off ? which means those unused but needed classes can creep into your deployment. So it is not trivial to fix and therefore a deprecation Messages (as opposed to doc) should exist to give people a heads up. > > Besides I would agree that with less and less sandbox Java applications and with a plan to downsize the security Manager having the non-verifyer optimization removed seems contraproductive (especially as Long as CDS is not mature). > > Gruss > Bernd From harold.seigel at oracle.com Tue Feb 19 21:51:04 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 19 Feb 2019 16:51:04 -0500 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: References: Message-ID: <4ca352aa-c4e5-be55-86fa-315d6617e994@oracle.com> Hi, Please review this updated webrev.? It has a modified warning message in arguments.cpp: http://cr.openjdk.java.net/~hseigel/bug_8214719.2/webrev/index.html Thanks, Harold On 2/6/2019 9:18 AM, Harold Seigel wrote: > Hi, > > Please review this change to deprecate the -Xverify:none and -noverify > options in JDK-13.? The following warning message will be issued when > these options are used: > > ??? ?warning: Options -Xverify:none and -noverify were deprecated in > ?? version 13.0 and will likely be removed in a future release. > > The options were removed from tests that no longer needed them or the > options were changed as needed. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html > > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on > Linux-x64, and by running JCK Lang and VM tests on Linux-x64. > > Thanks, Harold > From igor.ignatyev at oracle.com Wed Feb 20 00:34:49 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 16:34:49 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 Message-ID: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html > 1 line changed: 0 ins; 0 del; 1 mod; Hi all, could you please review this one-liner which switch jtreg version to jtreg4.2-b14? webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies Thanks, -- Igor From erik.joelsson at oracle.com Wed Feb 20 01:01:34 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Feb 2019 17:01:34 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> Message-ID: <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> Looks good. Do we need to also bump the required version in the TEST.ROOT files? /Erik On 2019-02-19 16:34, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >> 1 line changed: 0 ins; 0 del; 1 mod; > Hi all, > > could you please review this one-liner which switch jtreg version to jtreg4.2-b14? > > webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 > testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies > > Thanks, > -- Igor From igor.ignatyev at oracle.com Wed Feb 20 01:06:59 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 17:06:59 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> Message-ID: Hi Erik, thanks for your review. we can't just bump the required version as it can introduce changes in tests' behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], this will affect all the tests which have ${} in their @run directives, for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests which will be affected and will file RFE(s) to cover them as well. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 [2] https://bugs.openjdk.java.net/browse/JDK-8219140 Thanks, -- Igor > On Feb 19, 2019, at 5:01 PM, Erik Joelsson wrote: > > Looks good. > > Do we need to also bump the required version in the TEST.ROOT files? > > /Erik > > On 2019-02-19 16:34, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>> 1 line changed: 0 ins; 0 del; 1 mod; >> Hi all, >> >> could you please review this one-liner which switch jtreg version to jtreg4.2-b14? >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 >> testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies >> >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Wed Feb 20 01:26:46 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 17:26:46 -0800 Subject: RFR(S) : 8219395 : integrate gcov w/ run-test Message-ID: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html > 65 lines changed: 59 ins; 0 del; 6 mod; Hi all, could you please review the patch which makes it easy to run tests on the builds w/ native-code-coverage enabled? to do so the patch - sets GCOV_PREFIX env. variable, so .gcda files will be stored in build/*/test-results/gcov-output directory, and makes jtreg to propagate this env. variable to JDK under test - adds linux-x64-gcov and macosx-x64-gcov jib profiles - changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if it's the tested profile is -gcov profile and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4. webrev: http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8219395 testing: - :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov - checked that *-gcov builds have .gcno files generated and stored in symbols bundle; and regular builds don't - checked that *-gcov runs have .gcda files generated in test-results/gcov-output; and runs on regular builds don't Thanks, -- Igor From joe.darcy at oracle.com Wed Feb 20 01:49:11 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 19 Feb 2019 17:49:11 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> Message-ID: <5C6CB217.80909@oracle.com> Hello, On 2/19/2019 5:06 PM, Igor Ignatyev wrote: > Hi Erik, > > thanks for your review. > > we can't just bump the required version as it can introduce changes in tests' behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], From what I understand from Jon, allowSmartActionArgs is opt-in and has to be enabled in the TEST.ROOT file with allowSmartActionArgs=true Therefore, IIRC, the required version could be bumped without enabling smart action args. (I have a patch in progress to use smart action args for langtools tests: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012959.html) HTH, -Joe > this will affect all the tests which have ${} in their @run directives, for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests which will be affected and will file RFE(s) to cover them as well. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 > [2] https://bugs.openjdk.java.net/browse/JDK-8219140 > > Thanks, > -- Igor > >> On Feb 19, 2019, at 5:01 PM, Erik Joelsson wrote: >> >> Looks good. >> >> Do we need to also bump the required version in the TEST.ROOT files? >> >> /Erik >> >> On 2019-02-19 16:34, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>>> 1 line changed: 0 ins; 0 del; 1 mod; >>> Hi all, >>> >>> could you please review this one-liner which switch jtreg version to jtreg4.2-b14? >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 >>> testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies >>> >>> Thanks, >>> -- Igor From igor.ignatyev at oracle.com Wed Feb 20 01:54:08 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 17:54:08 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: <5C6CB217.80909@oracle.com> References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> <5C6CB217.80909@oracle.com> Message-ID: Joe, allowSmartActionArgs is opt-in if requiredVersion < b14, and opt-out if requiredVersion >= b14, please see http://hg.openjdk.java.net/code-tools/jtreg/rev/36c592d2f544 . so you don't have to have allowSmartActionArgs=true in 8219254. Thanks, -- Igor > On Feb 19, 2019, at 5:49 PM, Joseph D. Darcy wrote: > > Hello, > > On 2/19/2019 5:06 PM, Igor Ignatyev wrote: >> Hi Erik, >> >> thanks for your review. >> >> we can't just bump the required version as it can introduce changes in tests' behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], > > From what I understand from Jon, allowSmartActionArgs is opt-in and has to be enabled in the TEST.ROOT file with > > allowSmartActionArgs=true > > Therefore, IIRC, the required version could be bumped without enabling smart action args. > > (I have a patch in progress to use smart action args for langtools tests: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-February/012959.html) > > HTH, > > -Joe > >> this will affect all the tests which have ${} in their @run directives, for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests which will be affected and will file RFE(s) to cover them as well. >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 >> [2] https://bugs.openjdk.java.net/browse/JDK-8219140 >> >> Thanks, >> -- Igor >> >>> On Feb 19, 2019, at 5:01 PM, Erik Joelsson wrote: >>> >>> Looks good. >>> >>> Do we need to also bump the required version in the TEST.ROOT files? >>> >>> /Erik >>> >>> On 2019-02-19 16:34, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>>>> 1 line changed: 0 ins; 0 del; 1 mod; >>>> Hi all, >>>> >>>> could you please review this one-liner which switch jtreg version to jtreg4.2-b14? >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 >>>> testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies >>>> >>>> Thanks, >>>> -- Igor > From joe.darcy at oracle.com Wed Feb 20 01:57:10 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 19 Feb 2019 17:57:10 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> <5C6CB217.80909@oracle.com> Message-ID: <5C6CB3F6.3050401@oracle.com> Hi Igor, On 2/19/2019 5:54 PM, Igor Ignatyev wrote: > Joe, > > allowSmartActionArgs is opt-in if requiredVersion < b14, and opt-out > if requiredVersion >= b14, please see > http://hg.openjdk.java.net/code-tools/jtreg/rev/36c592d2f544 . so you > don't have to have allowSmartActionArgs=true in 8219254. > > Thanks, > -- Igor > Thanks for the correction Igor; I'll update my patch accordingly. Cheers, -Joe From david.holmes at oracle.com Wed Feb 20 02:43:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2019 12:43:50 +1000 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <4ca352aa-c4e5-be55-86fa-315d6617e994@oracle.com> References: <4ca352aa-c4e5-be55-86fa-315d6617e994@oracle.com> Message-ID: <1d9807b1-1ef3-e9da-68e9-19de4254d444@oracle.com> Hi Harold, That all looks fine to me. Thanks, David On 20/02/2019 7:51 am, Harold Seigel wrote: > Hi, > > Please review this updated webrev.? It has a modified warning message in > arguments.cpp: > > ?? http://cr.openjdk.java.net/~hseigel/bug_8214719.2/webrev/index.html > > Thanks, Harold > > On 2/6/2019 9:18 AM, Harold Seigel wrote: >> Hi, >> >> Please review this change to deprecate the -Xverify:none and -noverify >> options in JDK-13.? The following warning message will be issued when >> these options are used: >> >> ??? ?warning: Options -Xverify:none and -noverify were deprecated in >> ?? version 13.0 and will likely be removed in a future release. >> >> The options were removed from tests that no longer needed them or the >> options were changed as needed. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >> >> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests and >> builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on >> Linux-x64, and by running JCK Lang and VM tests on Linux-x64. >> >> Thanks, Harold >> From igor.ignatyev at oracle.com Wed Feb 20 03:32:24 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 19:32:24 -0800 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> <4f8405b2-0565-0d57-f330-075a919f183c@oracle.com> Message-ID: <42C0334A-09DA-48CD-962C-087C12970BD8@oracle.com> I've pushed the patch. for the reference, 8219408 [1] was filed to handle jdk tests which have ${; the only affected hotspot tests are vmTestbase tests, so 8219140 [2] covers all hotspot tests. [1] https://bugs.openjdk.java.net/browse/JDK-8219408 [2] https://bugs.openjdk.java.net/browse/JDK-8219140 Thanks, -- Igor > On Feb 19, 2019, at 5:06 PM, Igor Ignatyev wrote: > > Hi Erik, > > thanks for your review. > > we can't just bump the required version as it can introduce changes in tests' behavior. requiredVersion >= 4.2 b14 will enable allowSmartActionArgs[1], this will affect all the tests which have ${} in their @run directives, for example it will affect many vmTestbase tests which use PropertyResolvingWrapper. therefore, I suggest we bump requiredVersion after we clean up such tests and have filed 8219140[2] to deal w/ vmTestbase tests. I'll check if there are other tests which will be affected and will file RFE(s) to cover them as well. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902352 > [2] https://bugs.openjdk.java.net/browse/JDK-8219140 > > Thanks, > -- Igor > >> On Feb 19, 2019, at 5:01 PM, Erik Joelsson wrote: >> >> Looks good. >> >> Do we need to also bump the required version in the TEST.ROOT files? >> >> /Erik >> >> On 2019-02-19 16:34, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>>> 1 line changed: 0 ins; 0 del; 1 mod; >>> Hi all, >>> >>> could you please review this one-liner which switch jtreg version to jtreg4.2-b14? >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 >>> testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies >>> >>> Thanks, >>> -- Igor > From ChrisPhi at LGonQn.Org Tue Feb 19 13:55:23 2019 From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O) Date: Tue, 19 Feb 2019 08:55:23 -0500 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <558178e1-cc89-2026-58a5-0242c5ee0f7c@LGonQn.Org> Vote: yes Cheers! Chris From ChrisPhi at LGonQn.Org Tue Feb 19 15:59:34 2019 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Tue, 19 Feb 2019 10:59:34 -0500 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <8cd1cd5d-e4c1-9b95-c622-d9887f0c1f89@LGonQn.Org> Vote: yes Cheers! Chris From igor.ignatyev at oracle.com Wed Feb 20 05:53:14 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 21:53:14 -0800 Subject: RFR(S) : 8209807 : improve handling exception in requires.VMProps Message-ID: <46F68821-AB4B-4C07-9B19-AACA3C40D370@oracle.com> http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html > 122 lines changed: 30 ins; 25 del; 67 mod; Hi all, could you please review this patch which makes use of newly introduced error state of @requires properties[*] in jtreg? w/ this patch, we set a value w/ the well-known prefix in case any errors happen while we are getting property values. when jtreg sees this value, it set error statues to the test, which makes such cases more observable; simplifies root-cause analyze. and , arguably most importantly, jtreg now won't fail a whole test execution, and failure to get a property will affect only the tests which depend on that property. webrev: http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8209807 testing: tier[1-2] and manually verified that errors are reported when they should be and affect only certain tests [*] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 Thanks, -- Igor From igor.ignatyev at oracle.com Wed Feb 20 05:54:54 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 21:54:54 -0800 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path Message-ID: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html > 73 lines changed: 9 ins; 32 del; 32 mod; Hi all, could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth Thanks, -- Igor From david.holmes at oracle.com Wed Feb 20 06:07:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2019 16:07:20 +1000 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> Message-ID: <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> Hi Igor, On 20/02/2019 3:54 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >> 73 lines changed: 9 ins; 32 del; 32 mod; > > Hi all, > > could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. You will have to update the jtreg requiresVersion to b14 to use this, else it will fail for anyone not using b14. Thanks, David ---- > JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 > webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html > testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Wed Feb 20 06:24:02 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 22:24:02 -0800 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> Message-ID: <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> Hi David, you are right, I've filed 8219417 to do that in all test suites and sent RFR to jdk-dev alias. -- Igor > On Feb 19, 2019, at 10:07 PM, David Holmes wrote: > > Hi Igor, > > On 20/02/2019 3:54 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>> 73 lines changed: 9 ins; 32 del; 32 mod; >> Hi all, >> could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. > > You will have to update the jtreg requiresVersion to b14 to use this, else it will fail for anyone not using b14. > > Thanks, > David > ---- > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 >> webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >> testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth >> Thanks, >> -- Igor From david.holmes at oracle.com Wed Feb 20 06:48:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2019 16:48:58 +1000 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> Message-ID: Hi Igor, On 20/02/2019 4:24 pm, Igor Ignatyev wrote: > Hi David, > > you are right, I've filed 8219417 to do that in all test suites and sent RFR to jdk-dev alias. I responded to that RFR and I don't think it's the right approach. This bug should simply update the requiresVersion for the hotspot tests. Thanks, David > -- Igor > >> On Feb 19, 2019, at 10:07 PM, David Holmes wrote: >> >> Hi Igor, >> >> On 20/02/2019 3:54 pm, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>> 73 lines changed: 9 ins; 32 del; 32 mod; >>> Hi all, >>> could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. >> >> You will have to update the jtreg requiresVersion to b14 to use this, else it will fail for anyone not using b14. >> >> Thanks, >> David >> ---- >> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 >>> webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>> testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Wed Feb 20 07:05:07 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 19 Feb 2019 23:05:07 -0800 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> Message-ID: Hi David, Hi David, Hi David, http://cr.openjdk.java.net/~iignatyev//8219158/webrev.0-1/index.html is the incremental webrev w/ bumping requiredVersion only in hotspot. -- Igor > On Feb 19, 2019, at 10:48 PM, David Holmes wrote: > > Hi Igor, > > On 20/02/2019 4:24 pm, Igor Ignatyev wrote: >> Hi David, >> you are right, I've filed 8219417 to do that in all test suites and sent RFR to jdk-dev alias. > > I responded to that RFR and I don't think it's the right approach. This bug should simply update the requiresVersion for the hotspot tests. > > Thanks, > David > >> -- Igor >>> On Feb 19, 2019, at 10:07 PM, David Holmes wrote: >>> >>> Hi Igor, >>> >>> On 20/02/2019 3:54 pm, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>> 73 lines changed: 9 ins; 32 del; 32 mod; >>>> Hi all, >>>> could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. >>> >>> You will have to update the jtreg requiresVersion to b14 to use this, else it will fail for anyone not using b14. >>> >>> Thanks, >>> David >>> ---- >>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>> testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth >>>> Thanks, >>>> -- Igor From Alan.Bateman at oracle.com Wed Feb 20 07:08:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 Feb 2019 07:08:23 +0000 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> Message-ID: On 20/02/2019 00:34, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >> 1 line changed: 0 ins; 0 del; 1 mod; > Hi all, > > could you please review this one-liner which switch jtreg version to jtreg4.2-b14? > > webrev: http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219132 > testing: tier[1-5], client tests and jcstress test group testing showed no new failures; spot checking of .jtr files also didn't find any anomalies > I don't think we should rev this without also updating the `requiredVersion` key in the TEST.ROOT file at the top of each test suite. That is, I think we want everyone to use the same minimum version of jtreg, irrespective of how they run the tests. -Alan From david.holmes at oracle.com Wed Feb 20 08:40:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2019 18:40:29 +1000 Subject: RFR(T) : 8219132 : switch to jtreg4.2-b14 In-Reply-To: References: <1554FE12-7DFF-4D2F-A787-4B3256149800@oracle.com> Message-ID: <414e2516-f078-3437-f9e9-1705069a3435@oracle.com> Hi Alan, On 20/02/2019 5:08 pm, Alan Bateman wrote: > > > On 20/02/2019 00:34, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >>> 1 line changed: 0 ins; 0 del; 1 mod; >> Hi all, >> >> could you please review this one-liner which switch jtreg version to >> jtreg4.2-b14? >> >> webrev: >> http://cr.openjdk.java.net/~iignatyev//8219132/webrev.00/index.html >> JBS:? https://bugs.openjdk.java.net/browse/JDK-8219132 >> testing: tier[1-5], client tests and jcstress test group testing >> showed no new failures; spot checking of .jtr files also didn't find >> any anomalies >> > I don't think we should rev this without also updating the > `requiredVersion` key in the TEST.ROOT file at the top of each test > suite. That is, I think we want everyone to use the same minimum version > of jtreg, irrespective of how they run the tests. That's not how we've been doing things to-date. Some areas are still on 4.1. David > -Alan From david.holmes at oracle.com Wed Feb 20 08:41:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Feb 2019 18:41:07 +1000 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> Message-ID: <36719e40-ba77-c1ff-25b4-f87b5efef266@oracle.com> On 20/02/2019 5:05 pm, Igor Ignatyev wrote: > Hi David, > > Hi David, > > Hi David, > > http://cr.openjdk.java.net/~iignatyev//8219158/webrev.0-1/index.html?is > the incremental webrev w/ bumping ?requiredVersion only in hotspot. Looks good. Thanks, David > -- Igor > >> On Feb 19, 2019, at 10:48 PM, David Holmes > > wrote: >> >> Hi Igor, >> >> On 20/02/2019 4:24 pm, Igor Ignatyev wrote: >>> Hi David, >>> you are right, I've filed 8219417 to do that in all test suites and >>> sent RFR to jdk-dev alias. >> >> I responded to that RFR and I don't think it's the right approach. >> This bug should simply update the requiresVersion for the hotspot tests. >> >> Thanks, >> David >> >>> -- Igor >>>> On Feb 19, 2019, at 10:07 PM, David Holmes >>> > wrote: >>>> >>>> Hi Igor, >>>> >>>> On 20/02/2019 3:54 pm, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>> 73 lines changed: 9 ins; 32 del; 32 mod; >>>>> Hi all, >>>>> could you please review this trivial clean-up? jtreg4.2-b14 added a >>>>> new property 'test.root', this patches replaces all code in hotspot >>>>> testbase which determines the root directory w/ simple reading of >>>>> this property. >>>> >>>> You will have to update the jtreg requiresVersion to b14 to use >>>> this, else it will fail for anyone not using b14. >>>> >>>> Thanks, >>>> David >>>> ---- >>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>> testing: vmTestbase/gc/g1/unloading, >>>>> vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, >>>>> vmTestbase/vm/runtime/defmeth >>>>> Thanks, >>>>> -- Igor > From jesper.wilhelmsson at oracle.com Wed Feb 20 12:15:12 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 20 Feb 2019 13:15:12 +0100 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: Vote: Yes /Jesper > On 19 Feb 2019, at 08:17, Ioi Lam wrote: > > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > From harold.seigel at oracle.com Wed Feb 20 13:13:12 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 20 Feb 2019 08:13:12 -0500 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <1d9807b1-1ef3-e9da-68e9-19de4254d444@oracle.com> References: <4ca352aa-c4e5-be55-86fa-315d6617e994@oracle.com> <1d9807b1-1ef3-e9da-68e9-19de4254d444@oracle.com> Message-ID: Thanks David! Harold On 2/19/2019 9:43 PM, David Holmes wrote: > Hi Harold, > > That all looks fine to me. > > Thanks, > David > > On 20/02/2019 7:51 am, Harold Seigel wrote: >> Hi, >> >> Please review this updated webrev.? It has a modified warning message >> in arguments.cpp: >> >> http://cr.openjdk.java.net/~hseigel/bug_8214719.2/webrev/index.html >> >> Thanks, Harold >> >> On 2/6/2019 9:18 AM, Harold Seigel wrote: >>> Hi, >>> >>> Please review this change to deprecate the -Xverify:none and >>> -noverify options in JDK-13.? The following warning message will be >>> issued when these options are used: >>> >>> ??? ?warning: Options -Xverify:none and -noverify were deprecated in >>> ?? version 13.0 and will likely be removed in a future release. >>> >>> The options were removed from tests that no longer needed them or >>> the options were changed as needed. >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >>> >>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214719 >>> >>> The fix was regression tested by running Mach5 tiers 1 and 2 tests >>> and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on >>> Linux-x64, and by running JCK Lang and VM tests on Linux-x64. >>> >>> Thanks, Harold >>> From erik.joelsson at oracle.com Wed Feb 20 14:59:47 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Feb 2019 06:59:47 -0800 Subject: RFR(S) : 8219395 : integrate gcov w/ run-test In-Reply-To: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> References: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> Message-ID: <55d8c515-1aec-b65a-e114-0f3213642d92@oracle.com> Hello Igor, This looks pretty good. Just a few comments. In jib-profiles.js, the linux-x64 profile also builds docs-bundles, so if you base linux-x64-gcov on a clone of that there is some extra build work being done unnecessarily. I would recommend explicitly setting the default_make_targets (which would be product-bundles and test-bundles) for the new *-gcov profiles. On lines 795, 804 and 812 you seem to have left commented out code that should probably be removed. /Erik On 2019-02-19 17:26, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >> 65 lines changed: 59 ins; 0 del; 6 mod; > Hi all, > > could you please review the patch which makes it easy to run tests on the builds w/ native-code-coverage enabled? to do so the patch > - sets GCOV_PREFIX env. variable, so .gcda files will be stored in build/*/test-results/gcov-output directory, and makes jtreg to propagate this env. variable to JDK under test > - adds linux-x64-gcov and macosx-x64-gcov jib profiles > - changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if it's the tested profile is -gcov profile > > and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4. > > webrev: http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219395 > testing: > - :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov > - checked that *-gcov builds have .gcno files generated and stored in symbols bundle; and regular builds don't > - checked that *-gcov runs have .gcda files generated in test-results/gcov-output; and runs on regular builds don't > > Thanks, > -- Igor From matthias.baesken at sap.com Wed Feb 20 17:15:31 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 20 Feb 2019 17:15:31 +0000 Subject: RFR: [XS] 8219460: ppc: adjust NativeGeneralJump::insert_unconditional to stack allocated MacroAssembler -was RE: NativeGeneralJump::insert_unconditional ResourceMark Message-ID: Hi Martin, I followed your idea and use now a stack allocated MacroAssembler object In the ppc version of NativeGeneralJump::insert_unconditional . Please review . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219460 http://cr.openjdk.java.net/~mbaesken/webrevs/8219460.0/ Thanks, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 19. Februar 2019 13:09 > To: Baesken, Matthias ; Aleksey Shipilev > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: NativeGeneralJump::insert_unconditional ResourceMark - was : > RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 > miss ResourceMark > > Hi Matthias, > > aarch64 looks ok. The MacroAssembler is allocated on stack. So I can't find > anything which gets allocated in resource area. > Actually, I think this would be a better fix for PPC64 than adding a > ResourceMark (see below). > > Best regards, > Martin > > > > diff -r 140ecd460080 src/hotspot/cpu/ppc/nativeInst_ppc.cpp > --- a/src/hotspot/cpu/ppc/nativeInst_ppc.cpp Tue Feb 19 12:52:28 2019 > +0100 > +++ b/src/hotspot/cpu/ppc/nativeInst_ppc.cpp Tue Feb 19 12:56:50 2019 > +0100 > @@ -362,8 +362,8 @@ > > void NativeGeneralJump::insert_unconditional(address code_pos, address > entry) { > CodeBuffer cb(code_pos, BytesPerInstWord + 1); > - MacroAssembler* a = new MacroAssembler(&cb); > - a->b(entry); > + MacroAssembler a(&cb); > + a.b(entry); > ICache::ppc64_flush_icache_bytes(code_pos, > NativeGeneralJump::instruction_size); > } > > > > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 19. Februar 2019 09:47 > To: Doerr, Martin ; Aleksey Shipilev > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: NativeGeneralJump::insert_unconditional ResourceMark - was : RE: > RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss > ResourceMark > > Hi Martin, thanks for commenting . > > > > > In the example below (nativeInst_ppc.cpp), I think we should add one. At > > least, I couldn't find one at a good place. > > > > NativeGeneralJump::insert_unconditional for aarch64 looks similar to what > we see in nativeInst_ppc.cpp , should we add a ResourceMark here as > well ? > (maybe someone from the aarch64 developers could comment). > > > src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp > > 490void NativeGeneralJump::insert_unconditional(address code_pos, > address entry) { > 491 NativeGeneralJump* n_jump = (NativeGeneralJump*)code_pos; > 492 > 493 CodeBuffer cb(code_pos, instruction_size); > 494 MacroAssembler a(&cb); > 495 > 496 a.movptr(rscratch1, (uintptr_t)entry); > 497 a.br(rscratch1); > 498 > 499 ICache::invalidate_range(code_pos, instruction_size); > 500} > From martin.doerr at sap.com Wed Feb 20 17:24:13 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 20 Feb 2019 17:24:13 +0000 Subject: RFR [XS] 8219460: ppc: adjust NativeGeneralJump::insert_unconditional to stack allocated MacroAssembler -was RE: NativeGeneralJump::insert_unconditional ResourceMark Message-ID: Hi Matthias, looks good and trivial. Best regards, Martin -----Original Message----- From: Baesken, Matthias Sent: Mittwoch, 20. Februar 2019 18:16 To: Doerr, Martin ; Aleksey Shipilev ; 'hotspot-dev at openjdk.java.net' Subject: RFR: [XS] 8219460: ppc: adjust NativeGeneralJump::insert_unconditional to stack allocated MacroAssembler -was RE: NativeGeneralJump::insert_unconditional ResourceMark Hi Martin, I followed your idea and use now a stack allocated MacroAssembler object In the ppc version of NativeGeneralJump::insert_unconditional . Please review . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219460 http://cr.openjdk.java.net/~mbaesken/webrevs/8219460.0/ Thanks, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 19. Februar 2019 13:09 > To: Baesken, Matthias ; Aleksey Shipilev > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: NativeGeneralJump::insert_unconditional ResourceMark - was : > RE: RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 > miss ResourceMark > > Hi Matthias, > > aarch64 looks ok. The MacroAssembler is allocated on stack. So I can't find > anything which gets allocated in resource area. > Actually, I think this would be a better fix for PPC64 than adding a > ResourceMark (see below). > > Best regards, > Martin > > > > diff -r 140ecd460080 src/hotspot/cpu/ppc/nativeInst_ppc.cpp > --- a/src/hotspot/cpu/ppc/nativeInst_ppc.cpp Tue Feb 19 12:52:28 2019 > +0100 > +++ b/src/hotspot/cpu/ppc/nativeInst_ppc.cpp Tue Feb 19 12:56:50 2019 > +0100 > @@ -362,8 +362,8 @@ > > void NativeGeneralJump::insert_unconditional(address code_pos, address > entry) { > CodeBuffer cb(code_pos, BytesPerInstWord + 1); > - MacroAssembler* a = new MacroAssembler(&cb); > - a->b(entry); > + MacroAssembler a(&cb); > + a.b(entry); > ICache::ppc64_flush_icache_bytes(code_pos, > NativeGeneralJump::instruction_size); > } > > > > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 19. Februar 2019 09:47 > To: Doerr, Martin ; Aleksey Shipilev > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: NativeGeneralJump::insert_unconditional ResourceMark - was : RE: > RFR [XS] : 8219112: name_and_sig_as_C_string usages in frame_s390 miss > ResourceMark > > Hi Martin, thanks for commenting . > > > > > In the example below (nativeInst_ppc.cpp), I think we should add one. At > > least, I couldn't find one at a good place. > > > > NativeGeneralJump::insert_unconditional for aarch64 looks similar to what > we see in nativeInst_ppc.cpp , should we add a ResourceMark here as > well ? > (maybe someone from the aarch64 developers could comment). > > > src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp > > 490void NativeGeneralJump::insert_unconditional(address code_pos, > address entry) { > 491 NativeGeneralJump* n_jump = (NativeGeneralJump*)code_pos; > 492 > 493 CodeBuffer cb(code_pos, instruction_size); > 494 MacroAssembler a(&cb); > 495 > 496 a.movptr(rscratch1, (uintptr_t)entry); > 497 a.br(rscratch1); > 498 > 499 ICache::invalidate_range(code_pos, instruction_size); > 500} > From harold.seigel at oracle.com Wed Feb 20 18:14:26 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 20 Feb 2019 13:14:26 -0500 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: References: <4ca352aa-c4e5-be55-86fa-315d6617e994@oracle.com> Message-ID: Thanks Mikael! Harold On 2/20/2019 1:13 PM, Mikael Vidstedt wrote: > Looks good. > > Cheers, > Mikael > >> On Feb 19, 2019, at 1:51 PM, Harold Seigel wrote: >> >> Hi, >> >> Please review this updated webrev. It has a modified warning message in arguments.cpp: >> >> http://cr.openjdk.java.net/~hseigel/bug_8214719.2/webrev/index.html >> >> Thanks, Harold >> >> On 2/6/2019 9:18 AM, Harold Seigel wrote: >>> Hi, >>> >>> Please review this change to deprecate the -Xverify:none and -noverify options in JDK-13. The following warning message will be issued when these options are used: >>> >>> warning: Options -Xverify:none and -noverify were deprecated in >>> version 13.0 and will likely be removed in a future release. >>> >>> The options were removed from tests that no longer needed them or the options were changed as needed. >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8214719 >>> >>> The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on Linux-x64, and by running JCK Lang and VM tests on Linux-x64. >>> >>> Thanks, Harold >>> From mikael.vidstedt at oracle.com Wed Feb 20 18:13:49 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 20 Feb 2019 10:13:49 -0800 Subject: RFR 8214719: Deprecate -Xverify:none option In-Reply-To: <4ca352aa-c4e5-be55-86fa-315d6617e994@oracle.com> References: <4ca352aa-c4e5-be55-86fa-315d6617e994@oracle.com> Message-ID: Looks good. Cheers, Mikael > On Feb 19, 2019, at 1:51 PM, Harold Seigel wrote: > > Hi, > > Please review this updated webrev. It has a modified warning message in arguments.cpp: > > http://cr.openjdk.java.net/~hseigel/bug_8214719.2/webrev/index.html > > Thanks, Harold > > On 2/6/2019 9:18 AM, Harold Seigel wrote: >> Hi, >> >> Please review this change to deprecate the -Xverify:none and -noverify options in JDK-13. The following warning message will be issued when these options are used: >> >> warning: Options -Xverify:none and -noverify were deprecated in >> version 13.0 and will likely be removed in a future release. >> >> The options were removed from tests that no longer needed them or the options were changed as needed. >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8214719/webrev/index.html >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8214719 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on Linux-x64, and by running JCK Lang and VM tests on Linux-x64. >> >> Thanks, Harold >> From igor.ignatyev at oracle.com Wed Feb 20 18:27:26 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Feb 2019 10:27:26 -0800 Subject: RFR(S) : 8219395 : integrate gcov w/ run-test In-Reply-To: <55d8c515-1aec-b65a-e114-0f3213642d92@oracle.com> References: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> <55d8c515-1aec-b65a-e114-0f3213642d92@oracle.com> Message-ID: <56B47486-3BE5-47E2-9C8D-9DC1A3D1367A@oracle.com> Hi Erik, thanks for your review, I've removed the commented lines and changed default_make_targets, http://cr.openjdk.java.net/~iignatyev//8219395/webrev.0-1/index.html is incremental webrev. Thanks, -- Igor > On Feb 20, 2019, at 6:59 AM, Erik Joelsson wrote: > > Hello Igor, > > This looks pretty good. Just a few comments. > > In jib-profiles.js, the linux-x64 profile also builds docs-bundles, so if you base linux-x64-gcov on a clone of that there is some extra build work being done unnecessarily. I would recommend explicitly setting the default_make_targets (which would be product-bundles and test-bundles) for the new *-gcov profiles. > > On lines 795, 804 and 812 you seem to have left commented out code that should probably be removed. > > /Erik > > On 2019-02-19 17:26, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >>> 65 lines changed: 59 ins; 0 del; 6 mod; >> Hi all, >> >> could you please review the patch which makes it easy to run tests on the builds w/ native-code-coverage enabled? to do so the patch >> - sets GCOV_PREFIX env. variable, so .gcda files will be stored in build/*/test-results/gcov-output directory, and makes jtreg to propagate this env. variable to JDK under test >> - adds linux-x64-gcov and macosx-x64-gcov jib profiles >> - changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if it's the tested profile is -gcov profile >> >> and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219395 >> testing: >> - :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov >> - checked that *-gcov builds have .gcno files generated and stored in symbols bundle; and regular builds don't >> - checked that *-gcov runs have .gcda files generated in test-results/gcov-output; and runs on regular builds don't >> >> Thanks, >> -- Igor From erik.joelsson at oracle.com Wed Feb 20 18:44:09 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Feb 2019 10:44:09 -0800 Subject: RFR(S) : 8219395 : integrate gcov w/ run-test In-Reply-To: <56B47486-3BE5-47E2-9C8D-9DC1A3D1367A@oracle.com> References: <072FFA48-2587-42BD-9BF1-0B650F059AF6@oracle.com> <55d8c515-1aec-b65a-e114-0f3213642d92@oracle.com> <56B47486-3BE5-47E2-9C8D-9DC1A3D1367A@oracle.com> Message-ID: <0fcf4c3a-919a-618e-978f-196f127f8c44@oracle.com> Looks good. /Erik On 2019-02-20 10:27, Igor Ignatyev wrote: > Hi Erik, > > thanks for your review, I've removed the commented lines and changed > default_make_targets, > http://cr.openjdk.java.net/~iignatyev//8219395/webrev.0-1/index.html?is > incremental webrev. > > Thanks, > -- Igor > >> On Feb 20, 2019, at 6:59 AM, Erik Joelsson > > wrote: >> >> Hello Igor, >> >> This looks pretty good. Just a few comments. >> >> In jib-profiles.js, the linux-x64 profile also builds docs-bundles, >> so if you base linux-x64-gcov on a clone of that there is some extra >> build work being done unnecessarily. I would recommend explicitly >> setting the default_make_targets (which would be product-bundles and >> test-bundles) for the new *-gcov profiles. >> >> On lines 795, 804 and 812 you seem to have left commented out code >> that should probably be removed. >> >> /Erik >> >> On 2019-02-19 17:26, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >>>> 65 lines changed: 59 ins; 0 del; 6 mod; >>> Hi all, >>> >>> could you please review the patch which makes it easy to run tests >>> on the builds w/ native-code-coverage enabled? to do so the patch >>> ?- sets GCOV_PREFIX env. variable, so .gcda files will be stored in >>> build/*/test-results/gcov-output directory, and makes jtreg to >>> propagate this env. variable to JDK under test >>> ?- adds linux-x64-gcov and macosx-x64-gcov jib profiles >>> ?- changes 'run-test-prebuilt' profile to set GCOV_ENABLED=true if >>> it's the tested profile is -gcov profile >>> >>> and also fixes comment for JDKOPT_SETUP_CODE_COVERAGE in jdk-options.m4. >>> >>> webrev: >>> http://cr.openjdk.java.net/~iignatyev//8219395/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219395 >>> testing: >>> ?- :tier1 on {linux,macos}-x64 and {linux,macos}-x64-gcov >>> ?- checked that *-gcov builds have .gcno files generated and stored >>> in symbols bundle; and regular builds don't >>> ?- checked that *-gcov runs have .gcda files generated in >>> test-results/gcov-output; and runs on regular builds don't >>> >>> Thanks, >>> -- Igor > From igor.ignatyev at oracle.com Wed Feb 20 19:32:00 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Feb 2019 11:32:00 -0800 Subject: RFR(T) : 8219476 : cleanup hotspot ProblemList Message-ID: <594A2FBC-EF40-4A97-9BE3-3B73438987EC@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219476/webrev.00/index.html > 5 lines changed: 0 ins; 1 del; 4 mod; Hi all, could you please review this trivial clean up of hotspot ProblemList files? - 8189604 was incorrectly used instead of 8205016 by me in one of prev. cleanups (8218079) -=> s/8189604/8205016/ - 8195057 is resolved, so the test should be removed from the problem list - 8218698 got closed as dup of 8218074 (umbrella bug for Graal update) => s/8218698/8218074/ webrev: http://cr.openjdk.java.net/~iignatyev//8219476/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8219476 Thanks, -- Igor From jesper.wilhelmsson at oracle.com Wed Feb 20 19:40:38 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 20 Feb 2019 20:40:38 +0100 Subject: RFR(T) : 8219476 : cleanup hotspot ProblemList In-Reply-To: <594A2FBC-EF40-4A97-9BE3-3B73438987EC@oracle.com> References: <594A2FBC-EF40-4A97-9BE3-3B73438987EC@oracle.com> Message-ID: <353D19FC-2B97-4A13-9889-539EB96412D7@oracle.com> Looks good! /Jesper > On 20 Feb 2019, at 20:32, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8219476/webrev.00/index.html >> 5 lines changed: 0 ins; 1 del; 4 mod; > > Hi all, > > could you please review this trivial clean up of hotspot ProblemList files? > > - 8189604 was incorrectly used instead of 8205016 by me in one of prev. cleanups (8218079) -=> s/8189604/8205016/ > - 8195057 is resolved, so the test should be removed from the problem list > - 8218698 got closed as dup of 8218074 (umbrella bug for Graal update) => s/8218698/8218074/ > > webrev: http://cr.openjdk.java.net/~iignatyev//8219476/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219476 > > Thanks, > -- Igor > From igor.ignatyev at oracle.com Wed Feb 20 19:49:41 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Feb 2019 11:49:41 -0800 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: <36719e40-ba77-c1ff-25b4-f87b5efef266@oracle.com> References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> <36719e40-ba77-c1ff-25b4-f87b5efef266@oracle.com> Message-ID: <1AF2DEDC-D6DE-4DA9-B1A4-FE1082FA0202@oracle.com> David, I gave it a second though, and as this patch changes jdk/test/lib/Utils class, which potentially can be used by any of our test suites (and is already used by jdk and jaxp), it's safer to updated all TEST.ROOT files. this, as Alas mentioned in 8219417 RFR thread, requires some socialization and coordination. that's to say, I will hold pushing 8219158, till we get 8219417 integrated and/or come to another consensus. Cheers, -- Igor > On Feb 20, 2019, at 12:41 AM, David Holmes wrote: > > On 20/02/2019 5:05 pm, Igor Ignatyev wrote: >> Hi David, >> Hi David, >> Hi David, I don't know how this russian tradition to do things three times crept into my email ;) >> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.0-1/index.html is the incremental webrev w/ bumping requiredVersion only in hotspot. > > Looks good. > > Thanks, > David > >> -- Igor >>> On Feb 19, 2019, at 10:48 PM, David Holmes > wrote: >>> >>> Hi Igor, >>> >>> On 20/02/2019 4:24 pm, Igor Ignatyev wrote: >>>> Hi David, >>>> you are right, I've filed 8219417 to do that in all test suites and sent RFR to jdk-dev alias. >>> >>> I responded to that RFR and I don't think it's the right approach. This bug should simply update the requiresVersion for the hotspot tests. >>> >>> Thanks, >>> David >>> >>>> -- Igor >>>>> On Feb 19, 2019, at 10:07 PM, David Holmes > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> On 20/02/2019 3:54 pm, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>>> 73 lines changed: 9 ins; 32 del; 32 mod; >>>>>> Hi all, >>>>>> could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. >>>>> >>>>> You will have to update the jtreg requiresVersion to b14 to use this, else it will fail for anyone not using b14. >>>>> >>>>> Thanks, >>>>> David >>>>> ---- >>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 >>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>> testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth >>>>>> Thanks, >>>>>> -- Igor From igor.ignatyev at oracle.com Wed Feb 20 19:53:15 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Feb 2019 11:53:15 -0800 Subject: RFR(T) : 8219476 : cleanup hotspot ProblemList In-Reply-To: <353D19FC-2B97-4A13-9889-539EB96412D7@oracle.com> References: <594A2FBC-EF40-4A97-9BE3-3B73438987EC@oracle.com> <353D19FC-2B97-4A13-9889-539EB96412D7@oracle.com> Message-ID: <654A8782-4C76-4453-8392-1BA8B84543A5@oracle.com> Thanks Jesper, pushed. -- Igor > On Feb 20, 2019, at 11:40 AM, jesper.wilhelmsson at oracle.com wrote: > > Looks good! > /Jesper > >> On 20 Feb 2019, at 20:32, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8219476/webrev.00/index.html >>> 5 lines changed: 0 ins; 1 del; 4 mod; >> >> Hi all, >> >> could you please review this trivial clean up of hotspot ProblemList files? >> >> - 8189604 was incorrectly used instead of 8205016 by me in one of prev. cleanups (8218079) -=> s/8189604/8205016/ >> - 8195057 is resolved, so the test should be removed from the problem list >> - 8218698 got closed as dup of 8218074 (umbrella bug for Graal update) => s/8218698/8218074/ >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8219476/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219476 >> >> Thanks, >> -- Igor >> > From igor.ignatyev at oracle.com Thu Feb 21 05:19:58 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 20 Feb 2019 21:19:58 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm Message-ID: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html > 40 lines changed: 17 ins; 2 del; 21 mod; Hi all, could you please review this small patch which moves tests from test/jdk/vm? there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 testing: tier[1-2] (in progress), all the touched tests locally Thanks, -- Igor From david.holmes at oracle.com Thu Feb 21 08:11:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2019 18:11:30 +1000 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> Message-ID: <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> Hi Igor, On 21/02/2019 3:19 pm, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >> 40 lines changed: 17 ins; 2 del; 21 mod; > > Hi all, > > could you please review this small patch which moves tests from test/jdk/vm? I find some of these tests - the runtime ones at least - of extremely dubious value. They either cover basic functionality that is already well covered, or are regression tests for bugs in code that hasn't existed for many many years! BTW: test/hotspot/jtreg/runtime/ShiftTest.java is actually a jit test according to the test comment. > there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test No its a JNI invocation API test - nothing to do with our launcher. It belongs in runtime/jni. But we already have tests in runtime that use the JNI invocation API so this test adds no new coverage. I really think the value of these tests needs to be examined before they are brought over. Thanks, David ----- > and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. > > webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 > testing: tier[1-2] (in progress), all the touched tests locally > > Thanks, > -- Igor > From Alan.Bateman at oracle.com Thu Feb 21 08:19:56 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 08:19:56 +0000 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> Message-ID: On 21/02/2019 05:19, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >> 40 lines changed: 17 ins; 2 del; 21 mod; > Hi all, > > could you please review this small patch which moves tests from test/jdk/vm? > > there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. > > webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 > testing: tier[1-2] (in progress), all the touched tests locally > The tools/launcher directory is the tests for the java launcher, I don't think it's the right place for tests for the JNI invocation interface - I think that one is asking to be moved to be with the other JNI tests. -Alan From per.liden at oracle.com Thu Feb 21 08:36:22 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 21 Feb 2019 09:36:22 +0100 Subject: CFV: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <47839f61-b7f1-a073-7a20-f953dd692c63@oracle.com> Vote: yes /Per On 2/19/19 8:17 AM, Ioi Lam wrote: > Greetings, > > I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to > Membership in the HotSpot Group. > > Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK > Reviewer and has contributed over 100 changesets [3]. > > Votes are due by March 4, 2019, 11:30 PST. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thank you > Markus > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() > > From david.holmes at oracle.com Thu Feb 21 09:20:43 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2019 19:20:43 +1000 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: <1AF2DEDC-D6DE-4DA9-B1A4-FE1082FA0202@oracle.com> References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> <36719e40-ba77-c1ff-25b4-f87b5efef266@oracle.com> <1AF2DEDC-D6DE-4DA9-B1A4-FE1082FA0202@oracle.com> Message-ID: <373f5b00-3289-3840-874b-741cf8d0b470@oracle.com> On 21/02/2019 5:49 am, Igor Ignatyev wrote: > David, > > I gave it a second though, and as this patch changes jdk/test/lib/Utils class, which potentially can be used by any of our test suites (and is already used by jdk and jaxp), it's safer to updated all TEST.ROOT files. this, as Alas mentioned in 8219417 RFR thread, requires some socialization and coordination. that's to say, I will hold pushing 8219158, till we get 8219417 integrated and/or come to another consensus. The change to the Utils class doesn't affect any tests that don't try to use TEST.ROOT. The Utils class itself is not dependent on the jtreg version as if the property does not exist it just returns an empty string. Cheers, David > Cheers, > -- Igor > >> On Feb 20, 2019, at 12:41 AM, David Holmes wrote: >> >> On 20/02/2019 5:05 pm, Igor Ignatyev wrote: >>> Hi David, >>> Hi David, >>> Hi David, > I don't know how this russian tradition to do things three times crept into my email ;) >>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.0-1/index.html is the incremental webrev w/ bumping requiredVersion only in hotspot. >> >> Looks good. >> >> Thanks, >> David >> >>> -- Igor >>>> On Feb 19, 2019, at 10:48 PM, David Holmes > wrote: >>>> >>>> Hi Igor, >>>> >>>> On 20/02/2019 4:24 pm, Igor Ignatyev wrote: >>>>> Hi David, >>>>> you are right, I've filed 8219417 to do that in all test suites and sent RFR to jdk-dev alias. >>>> >>>> I responded to that RFR and I don't think it's the right approach. This bug should simply update the requiresVersion for the hotspot tests. >>>> >>>> Thanks, >>>> David >>>> >>>>> -- Igor >>>>>> On Feb 19, 2019, at 10:07 PM, David Holmes > wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> On 20/02/2019 3:54 pm, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>>>> 73 lines changed: 9 ins; 32 del; 32 mod; >>>>>>> Hi all, >>>>>>> could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. >>>>>> >>>>>> You will have to update the jtreg requiresVersion to b14 to use this, else it will fail for anyone not using b14. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ---- >>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 >>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>>> testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth >>>>>>> Thanks, >>>>>>> -- Igor > From david.holmes at oracle.com Thu Feb 21 09:26:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2019 19:26:50 +1000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: <3b65ddd4-c408-10f7-c0ab-9c256e2b42f6@oracle.com> Message-ID: <3941e839-c0ca-eef3-3291-f4ae823bd371@oracle.com> On 19/02/2019 6:31 pm, Baesken, Matthias wrote: > Hi David, thanks for the review . > > However I had to address an issue in src/hotspot/os/linux/perfMemory_linux.cpp . > There were some open calls that deal with ***directories*** , and there os::open cannot be used . Which ones? I can't readily compare the two webrevs. Thanks, David ----- > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.5/ > > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 19. Februar 2019 06:13 >> To: Baesken, Matthias ; Thomas St?fe >> >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: 8218811: replace open by os::open in hotspot coding - was : >> open-calls in hotspot code instead of os::open ? >> >> On 15/02/2019 1:44 am, Baesken, Matthias wrote: >>> Hello, here is the updated webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.4/ >> >> This seems okay to me. >> >> Thanks, >> David >> ----- >> >>> Best regards, Matthias >>> >>> >>> >>> From: Baesken, Matthias >>> Sent: Donnerstag, 14. Februar 2019 12:43 >>> To: 'Thomas St?fe' >>> Cc: Kim Barrett ; ioi.lam at oracle.com; hotspot- >> dev at openjdk.java.net >>> Subject: RE: 8218811: replace open by os::open in hotspot coding - was : >> open-calls in hotspot code instead of os::open ? >>> >>>> fdStream::fdStream(const char* file_name) >>>> >>>> bool _need_close; >>>> >>>> and the close() call in the constructor? >>> >>> Hi, this has nothing to do with this change. >>> I have very bad experience with bringing in unrelated cleanups into a >> change my request after request etc. >>> >>> Will remove the os::open from CompileLog::finish_log_on_error() and >> the whitespace stuff. >>> >>> Thanks, Matthias >>> > From matthias.baesken at sap.com Thu Feb 21 09:58:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 21 Feb 2019 09:58:51 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: <3941e839-c0ca-eef3-3291-f4ae823bd371@oracle.com> References: <3b65ddd4-c408-10f7-c0ab-9c256e2b42f6@oracle.com> <3941e839-c0ca-eef3-3291-f4ae823bd371@oracle.com> Message-ID: Hi David, the ones in open_directory_secure and open_directory_secure_cwd . Please see the diff of src/hotspot/os/linux/perfMemory_linux.cpp from webrev 4 vs. 5 . 320c320 < RESTARTABLE(os::open(dirname, O_RDONLY|O_NOFOLLOW, 0), result); --- > RESTARTABLE(::open(dirname, O_RDONLY|O_NOFOLLOW), result); 385c385 < RESTARTABLE(os::open(".", O_RDONLY, 0), result); --- > RESTARTABLE(::open(".", O_RDONLY), result); Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 21. Februar 2019 10:27 > To: Baesken, Matthias ; Thomas St?fe > > Cc: hotspot-dev at openjdk.java.net > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : > open-calls in hotspot code instead of os::open ? > > On 19/02/2019 6:31 pm, Baesken, Matthias wrote: > > Hi David, thanks for the review . > > > > However I had to address an issue in > src/hotspot/os/linux/perfMemory_linux.cpp . > > There were some open calls that deal with ***directories*** , and > there os::open cannot be used . > > Which ones? I can't readily compare the two webrevs. > > Thanks, > David > ----- > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.5/ > > > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Dienstag, 19. Februar 2019 06:13 > >> To: Baesken, Matthias ; Thomas St?fe > >> > >> Cc: hotspot-dev at openjdk.java.net > >> Subject: Re: 8218811: replace open by os::open in hotspot coding - was : > >> open-calls in hotspot code instead of os::open ? > >> > >> On 15/02/2019 1:44 am, Baesken, Matthias wrote: > >>> Hello, here is the updated webrev : > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.4/ > >> > >> This seems okay to me. > >> > >> Thanks, > >> David > >> ----- > >> > >>> Best regards, Matthias > >>> > >>> > >>> > >>> From: Baesken, Matthias > >>> Sent: Donnerstag, 14. Februar 2019 12:43 > >>> To: 'Thomas St?fe' > >>> Cc: Kim Barrett ; ioi.lam at oracle.com; > hotspot- > >> dev at openjdk.java.net > >>> Subject: RE: 8218811: replace open by os::open in hotspot coding - was : > >> open-calls in hotspot code instead of os::open ? > >>> > >>>> fdStream::fdStream(const char* file_name) > >>>> > >>>> bool _need_close; > >>>> > >>>> and the close() call in the constructor? > >>> > >>> Hi, this has nothing to do with this change. > >>> I have very bad experience with bringing in unrelated cleanups into a > >> change my request after request etc. > >>> > >>> Will remove the os::open from CompileLog::finish_log_on_error() > and > >> the whitespace stuff. > >>> > >>> Thanks, Matthias > >>> > > From david.holmes at oracle.com Thu Feb 21 10:25:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Feb 2019 20:25:30 +1000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: <3b65ddd4-c408-10f7-c0ab-9c256e2b42f6@oracle.com> <3941e839-c0ca-eef3-3291-f4ae823bd371@oracle.com> Message-ID: <6db98f9a-6a55-8a59-9376-f6e733deab66@oracle.com> Sorry I missed the obvious. That change seems fine. Thanks, David On 21/02/2019 7:58 pm, Baesken, Matthias wrote: > Hi David, the ones in open_directory_secure and open_directory_secure_cwd . > > Please see the diff of src/hotspot/os/linux/perfMemory_linux.cpp from webrev 4 vs. 5 . > > 320c320 > < RESTARTABLE(os::open(dirname, O_RDONLY|O_NOFOLLOW, 0), result); > --- >> RESTARTABLE(::open(dirname, O_RDONLY|O_NOFOLLOW), result); > 385c385 > < RESTARTABLE(os::open(".", O_RDONLY, 0), result); > --- >> RESTARTABLE(::open(".", O_RDONLY), result); > > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Donnerstag, 21. Februar 2019 10:27 >> To: Baesken, Matthias ; Thomas St?fe >> >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: 8218811: replace open by os::open in hotspot coding - was : >> open-calls in hotspot code instead of os::open ? >> >> On 19/02/2019 6:31 pm, Baesken, Matthias wrote: >>> Hi David, thanks for the review . >>> >>> However I had to address an issue in >> src/hotspot/os/linux/perfMemory_linux.cpp . >>> There were some open calls that deal with ***directories*** , and >> there os::open cannot be used . >> >> Which ones? I can't readily compare the two webrevs. >> >> Thanks, >> David >> ----- >> >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.5/ >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Dienstag, 19. Februar 2019 06:13 >>>> To: Baesken, Matthias ; Thomas St?fe >>>> >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: Re: 8218811: replace open by os::open in hotspot coding - was : >>>> open-calls in hotspot code instead of os::open ? >>>> >>>> On 15/02/2019 1:44 am, Baesken, Matthias wrote: >>>>> Hello, here is the updated webrev : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.4/ >>>> >>>> This seems okay to me. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>> From: Baesken, Matthias >>>>> Sent: Donnerstag, 14. Februar 2019 12:43 >>>>> To: 'Thomas St?fe' >>>>> Cc: Kim Barrett ; ioi.lam at oracle.com; >> hotspot- >>>> dev at openjdk.java.net >>>>> Subject: RE: 8218811: replace open by os::open in hotspot coding - was : >>>> open-calls in hotspot code instead of os::open ? >>>>> >>>>>> fdStream::fdStream(const char* file_name) >>>>>> >>>>>> bool _need_close; >>>>>> >>>>>> and the close() call in the constructor? >>>>> >>>>> Hi, this has nothing to do with this change. >>>>> I have very bad experience with bringing in unrelated cleanups into a >>>> change my request after request etc. >>>>> >>>>> Will remove the os::open from CompileLog::finish_log_on_error() >> and >>>> the whitespace stuff. >>>>> >>>>> Thanks, Matthias >>>>> >>> From matthias.baesken at sap.com Thu Feb 21 12:36:30 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 21 Feb 2019 12:36:30 +0000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: <6db98f9a-6a55-8a59-9376-f6e733deab66@oracle.com> References: <3b65ddd4-c408-10f7-c0ab-9c256e2b42f6@oracle.com> <3941e839-c0ca-eef3-3291-f4ae823bd371@oracle.com> <6db98f9a-6a55-8a59-9376-f6e733deab66@oracle.com> Message-ID: Thanks ! May I push it ? ( submit repo showed no errors) Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 21. Februar 2019 11:26 > To: Baesken, Matthias ; Thomas St?fe > > Cc: hotspot-dev at openjdk.java.net > Subject: Re: 8218811: replace open by os::open in hotspot coding - was : > open-calls in hotspot code instead of os::open ? > > Sorry I missed the obvious. > > That change seems fine. > > Thanks, > David > > > On 21/02/2019 7:58 pm, Baesken, Matthias wrote: > > Hi David, the ones in open_directory_secure and > open_directory_secure_cwd . > > > > Please see the diff of src/hotspot/os/linux/perfMemory_linux.cpp from > webrev 4 vs. 5 . > > > > 320c320 > > < RESTARTABLE(os::open(dirname, O_RDONLY|O_NOFOLLOW, 0), result); > > --- > >> RESTARTABLE(::open(dirname, O_RDONLY|O_NOFOLLOW), result); > > 385c385 > > < RESTARTABLE(os::open(".", O_RDONLY, 0), result); > > --- > >> RESTARTABLE(::open(".", O_RDONLY), result); > > > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Donnerstag, 21. Februar 2019 10:27 > >> To: Baesken, Matthias ; Thomas St?fe > >> > >> Cc: hotspot-dev at openjdk.java.net > >> Subject: Re: 8218811: replace open by os::open in hotspot coding - was : > >> open-calls in hotspot code instead of os::open ? > >> > >> On 19/02/2019 6:31 pm, Baesken, Matthias wrote: > >>> Hi David, thanks for the review . > >>> > >>> However I had to address an issue in > >> src/hotspot/os/linux/perfMemory_linux.cpp . > >>> There were some open calls that deal with ***directories*** , and > >> there os::open cannot be used . > >> > >> Which ones? I can't readily compare the two webrevs. > >> > >> Thanks, > >> David > >> ----- > >> > >>> New webrev : > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.5/ > >>> > >>> > >>> Best regards, Matthias > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes > >>>> Sent: Dienstag, 19. Februar 2019 06:13 > >>>> To: Baesken, Matthias ; Thomas St?fe > >>>> > >>>> Cc: hotspot-dev at openjdk.java.net > >>>> Subject: Re: 8218811: replace open by os::open in hotspot coding - was > : > >>>> open-calls in hotspot code instead of os::open ? > >>>> > >>>> On 15/02/2019 1:44 am, Baesken, Matthias wrote: > >>>>> Hello, here is the updated webrev : > >>>>> > >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.4/ > >>>> > >>>> This seems okay to me. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>>> Best regards, Matthias > >>>>> > >>>>> > >>>>> > >>>>> From: Baesken, Matthias > >>>>> Sent: Donnerstag, 14. Februar 2019 12:43 > >>>>> To: 'Thomas St?fe' > >>>>> Cc: Kim Barrett ; ioi.lam at oracle.com; > >> hotspot- > >>>> dev at openjdk.java.net > >>>>> Subject: RE: 8218811: replace open by os::open in hotspot coding - > was : > >>>> open-calls in hotspot code instead of os::open ? > >>>>> > >>>>>> fdStream::fdStream(const char* file_name) > >>>>>> > >>>>>> bool _need_close; > >>>>>> > >>>>>> and the close() call in the constructor? > >>>>> > >>>>> Hi, this has nothing to do with this change. > >>>>> I have very bad experience with bringing in unrelated cleanups into a > >>>> change my request after request etc. > >>>>> > >>>>> Will remove the os::open from CompileLog::finish_log_on_error() > >> and > >>>> the whitespace stuff. > >>>>> > >>>>> Thanks, Matthias > >>>>> > >>> From hohensee at amazon.com Thu Feb 21 17:20:39 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 21 Feb 2019 17:20:39 +0000 Subject: New HotSpot Group Member: Calvin Cheung In-Reply-To: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> References: <5cc54a8e-78cb-01ea-f077-e68440568f96@oracle.com> Message-ID: <65913222-CA9C-4436-9EF7-AFA1180314BF@amazon.com> Vote: yes ?On 2/18/19, 11:19 PM, "hotspot-dev on behalf of Ioi Lam" wrote: Greetings, I hereby nominate Calvin Cheung (OpenJDK user name: ccheung) to Membership in the HotSpot Group. Calvin is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 100 changesets [3]. Votes are due by March 4, 2019, 11:30 PST. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [1]http://openjdk.java.net/census#hotspot [2]http://openjdk.java.net/groups/#member-vote [3]http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(ccheung))+and+not+merge() From hohensee at amazon.com Thu Feb 21 17:22:22 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 21 Feb 2019 17:22:22 +0000 Subject: New HotSpot Group Member: Erik Gahlin In-Reply-To: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> References: <6b356b87-453a-4b46-ba6d-4e45ba1d58c8@default> Message-ID: Vote: yes ?On 2/15/19, 10:47 AM, "hotspot-dev on behalf of Markus Gronlund" wrote: Greetings, I hearby nominate Erik Gahlin (OpenJDK user name: egahlin) to Membership in the Hotspot Group. Erik is a member of the HotSpot Runtime group at Oracle, is a JDK Reviewer and has contributed over 60 changesets [3]. Votes are due by March 1, 2019, 20:00 CET. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thank you Markus [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(egahlin)+or+desc(%22erik.gahlin%40oracle.com%22))+and+not+merge() From hohensee at amazon.com Thu Feb 21 17:22:56 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 21 Feb 2019 17:22:56 +0000 Subject: New hotspot Group Member: Martin Doerr In-Reply-To: References: Message-ID: <817FE9B0-4416-4695-9D16-765A0176D87C@amazon.com> Vote: yes ?On 2/14/19, 5:26 AM, "hotspot-dev on behalf of Volker Simonis" wrote: I hereby nominate Martin Doerr (OpenJDK user name: mdoerr) to Membership in the HotSpot Group. Martin is one of the initial authors of the ppc64 port, a jdk project Reviewer and long term OpenJDK Contributor. Since 2014 he has contributed more than 112 changes [3] and reviewed more than 154 [4]. Votes are due by February 28, 2019, 18:00 CET. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. With best regards, Volker [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(mdoerr)&revcount=600 [4] hg log -r "grep('Reviewed-by:.*mdoerr')" | grep "Reviewed" | wc From hohensee at amazon.com Thu Feb 21 17:23:07 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 21 Feb 2019 17:23:07 +0000 Subject: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: Vote: yes ?On 2/14/19, 5:22 AM, "hotspot-dev on behalf of Volker Simonis" wrote: I hereby nominate Thomas Stuefe (OpenJDK user name: stuefe) to Membership in the HotSpot Group. Thomas is one of the initial authors of the AIX/OS400 port, a jdk project Reviewer and long term OpenJDK Contributor. Since 2015 he has contributed more than 140 changes [3] and reviewed more than 240 [4] mostly in the hotspot runtime area. Votes are due by February 28, 2019, 18:00 CET. Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. With best regards, Volker [1] http://openjdk.java.net/census#hotspot [2] http://openjdk.java.net/groups/#member-vote [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=author(stuefe)&revcount=600 [4] hg log -r "grep('Reviewed-by:.*stuefe')" | grep "Reviewed" | wc From igor.ignatyev at oracle.com Thu Feb 21 18:25:46 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Feb 2019 10:25:46 -0800 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: <373f5b00-3289-3840-874b-741cf8d0b470@oracle.com> References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> <36719e40-ba77-c1ff-25b4-f87b5efef266@oracle.com> <1AF2DEDC-D6DE-4DA9-B1A4-FE1082FA0202@oracle.com> <373f5b00-3289-3840-874b-741cf8d0b470@oracle.com> Message-ID: <944E04E7-08EB-4BD6-B522-F04957C6514B@oracle.com> > On Feb 21, 2019, at 1:20 AM, David Holmes wrote: > > On 21/02/2019 5:49 am, Igor Ignatyev wrote: >> David, >> I gave it a second though, and as this patch changes jdk/test/lib/Utils class, which potentially can be used by any of our test suites (and is already used by jdk and jaxp), it's safer to updated all TEST.ROOT files. this, as Alas mentioned in 8219417 RFR thread, requires some socialization and coordination. that's to say, I will hold pushing 8219158, till we get 8219417 integrated and/or come to another consensus. > > The change to the Utils class doesn't affect any tests that don't try to use TEST.ROOT. The Utils class itself is not dependent on the jtreg version as if the property does not exist it just returns an empty string. David, that's true, but my point was different. let's say someone is adding new tests which use this static field in jaxp test suite and we haven't updated requiredVersion there. so the person which adds new tests, tested them using jib, which means using jtreg4.2-b14, and the tests work as expected, and there is nothing in Utils which say "this property won't be available unless jtreg >= b14" (and I don't think we need such comment there), so this person doesn't have any reasons to update TEST.ROOT in jaxp test suite. however, next time someone who doesn't use jib or jtreg4.2-b14 runs jaxp test suites, all these tests fail. and, from my point of view, this case isn't much different from one you mentioned in this thread. therefore, I believe it'll be much safer/better if we update all TEST.ROOT files before we start to use any features from 4.2-b14 in shared classes. Thanks, -- Igor > Cheers, > David > >> Cheers, >> -- Igor >>> On Feb 20, 2019, at 12:41 AM, David Holmes wrote: >>> >>> On 20/02/2019 5:05 pm, Igor Ignatyev wrote: >>>> Hi David, >>>> Hi David, >>>> Hi David, >> I don't know how this russian tradition to do things three times crept into my email ;) >>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.0-1/index.html is the incremental webrev w/ bumping requiredVersion only in hotspot. >>> >>> Looks good. >>> >>> Thanks, >>> David >>> >>>> -- Igor >>>>> On Feb 19, 2019, at 10:48 PM, David Holmes > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> On 20/02/2019 4:24 pm, Igor Ignatyev wrote: >>>>>> Hi David, >>>>>> you are right, I've filed 8219417 to do that in all test suites and sent RFR to jdk-dev alias. >>>>> >>>>> I responded to that RFR and I don't think it's the right approach. This bug should simply update the requiresVersion for the hotspot tests. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> -- Igor >>>>>>> On Feb 19, 2019, at 10:07 PM, David Holmes > wrote: >>>>>>> >>>>>>> Hi Igor, >>>>>>> >>>>>>> On 20/02/2019 3:54 pm, Igor Ignatyev wrote: >>>>>>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>>>>> 73 lines changed: 9 ins; 32 del; 32 mod; >>>>>>>> Hi all, >>>>>>>> could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. >>>>>>> >>>>>>> You will have to update the jtreg requiresVersion to b14 to use this, else it will fail for anyone not using b14. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ---- >>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 >>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>>>> testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth >>>>>>>> Thanks, >>>>>>>> -- Igor From igor.ignatyev at oracle.com Thu Feb 21 19:53:10 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Feb 2019 11:53:10 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> Message-ID: > On Feb 21, 2019, at 12:11 AM, David Holmes wrote: > > Hi Igor, > > On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>> 40 lines changed: 17 ins; 2 del; 21 mod; >> Hi all, >> could you please review this small patch which moves tests from test/jdk/vm? > > I find some of these tests - the runtime ones at least - of extremely dubious value. They either cover basic functionality that is already well covered, or are regression tests for bugs in code that hasn't existed for many many years! as I wrote in another related email: "one of the reason I'm proposing this move is exactly questionable value of these tests, I want to believe that having these tests in hotspot/ test directories will bring more attention to them from corresponding component teams and hence they will be removed/reworked/re-whatever faster and better. and I also believe that one of the reason we got duplications exactly because these tests were located in jdk test suite." > BTW: > > test/hotspot/jtreg/runtime/ShiftTest.java > > is actually a jit test according to the test comment. sure, I will move it to hotspot/compiler. > >> there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test > > No its a JNI invocation API test - nothing to do with our launcher. It belongs in runtime/jni. But we already have tests in runtime that use the JNI invocation API so this test adds no new coverage. this is actually was my first reaction, and I even have the webrev which moves it to runtime/jni, but then I looked at the associated bug and it is filed against tools/launcher. and I even got a false (as I know by now) memory that I saw JLI_ method being called from the test. there is actually another test (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. > I really think the value of these tests needs to be examined before they are brought over. I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep jdk/vm directory the more tests can end up there and the more rotten these tests become. Thanks, -- Igor > > Thanks, > David > ----- > >> and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. >> webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >> testing: tier[1-2] (in progress), all the touched tests locally >> Thanks, >> -- Igor From igor.ignatyev at oracle.com Thu Feb 21 19:55:51 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 21 Feb 2019 11:55:51 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> Message-ID: > On Feb 21, 2019, at 12:19 AM, Alan Bateman wrote: > On 21/02/2019 05:19, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>> 40 lines changed: 17 ins; 2 del; 21 mod; >> Hi all, >> >> could you please review this small patch which moves tests from test/jdk/vm? >> >> there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >> testing: tier[1-2] (in progress), all the touched tests locally >> > The tools/launcher directory is the tests for the java launcher, I don't think it's the right place for tests for the JNI invocation interface - I think that one is asking to be moved to be with the other JNI tests. Alan, you are right, this test is a JNI test and should be moved to hotspot/runtime/jni. more details in my answer to the same comment in David's email. in two words, I accidentally looked at another test. -- Igor > > -Alan From Alan.Bateman at oracle.com Thu Feb 21 20:17:21 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Feb 2019 20:17:21 +0000 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> Message-ID: <0c282875-2f0b-ed17-4a05-621bd5e0d862@oracle.com> On 21/02/2019 19:55, Igor Ignatyev wrote: > : > Alan, you are right, this test is a JNI test and should be moved to hotspot/runtime/jni. more details in my answer to the same comment in David's email. in two words, I accidentally looked at another test. > Can you double check that it is actually using the JNI invocation interface directly? I don't think we were able to find anyone in Eclipse to explain what their launcher on macOS is doing. I suspect it may be directly (or indirectly) reading the CFBundleExecutable property from Info.plist and calling the JNI_CreateJavaVM function in libjli (not libjvm). We probably need more tests in this area and also a bit more archaeology to see whether this was a supported interface in Apple's JDK. -Alan From david.holmes at oracle.com Fri Feb 22 03:24:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2019 13:24:25 +1000 Subject: 8218811: replace open by os::open in hotspot coding - was : open-calls in hotspot code instead of os::open ? In-Reply-To: References: <3b65ddd4-c408-10f7-c0ab-9c256e2b42f6@oracle.com> <3941e839-c0ca-eef3-3291-f4ae823bd371@oracle.com> <6db98f9a-6a55-8a59-9376-f6e733deab66@oracle.com> Message-ID: You seem to have multiple reviews in place, so yes it can be pushed. David On 21/02/2019 10:36 pm, Baesken, Matthias wrote: > Thanks ! > > May I push it ? ( submit repo showed no errors) > > Best regards, Matthias > > >> -----Original Message----- >> From: David Holmes >> Sent: Donnerstag, 21. Februar 2019 11:26 >> To: Baesken, Matthias ; Thomas St?fe >> >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: 8218811: replace open by os::open in hotspot coding - was : >> open-calls in hotspot code instead of os::open ? >> >> Sorry I missed the obvious. >> >> That change seems fine. >> >> Thanks, >> David >> >> >> On 21/02/2019 7:58 pm, Baesken, Matthias wrote: >>> Hi David, the ones in open_directory_secure and >> open_directory_secure_cwd . >>> >>> Please see the diff of src/hotspot/os/linux/perfMemory_linux.cpp from >> webrev 4 vs. 5 . >>> >>> 320c320 >>> < RESTARTABLE(os::open(dirname, O_RDONLY|O_NOFOLLOW, 0), result); >>> --- >>>> RESTARTABLE(::open(dirname, O_RDONLY|O_NOFOLLOW), result); >>> 385c385 >>> < RESTARTABLE(os::open(".", O_RDONLY, 0), result); >>> --- >>>> RESTARTABLE(::open(".", O_RDONLY), result); >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Donnerstag, 21. Februar 2019 10:27 >>>> To: Baesken, Matthias ; Thomas St?fe >>>> >>>> Cc: hotspot-dev at openjdk.java.net >>>> Subject: Re: 8218811: replace open by os::open in hotspot coding - was : >>>> open-calls in hotspot code instead of os::open ? >>>> >>>> On 19/02/2019 6:31 pm, Baesken, Matthias wrote: >>>>> Hi David, thanks for the review . >>>>> >>>>> However I had to address an issue in >>>> src/hotspot/os/linux/perfMemory_linux.cpp . >>>>> There were some open calls that deal with ***directories*** , and >>>> there os::open cannot be used . >>>> >>>> Which ones? I can't readily compare the two webrevs. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> New webrev : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.5/ >>>>> >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Dienstag, 19. Februar 2019 06:13 >>>>>> To: Baesken, Matthias ; Thomas St?fe >>>>>> >>>>>> Cc: hotspot-dev at openjdk.java.net >>>>>> Subject: Re: 8218811: replace open by os::open in hotspot coding - was >> : >>>>>> open-calls in hotspot code instead of os::open ? >>>>>> >>>>>> On 15/02/2019 1:44 am, Baesken, Matthias wrote: >>>>>>> Hello, here is the updated webrev : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8218811.4/ >>>>>> >>>>>> This seems okay to me. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Best regards, Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: Baesken, Matthias >>>>>>> Sent: Donnerstag, 14. Februar 2019 12:43 >>>>>>> To: 'Thomas St?fe' >>>>>>> Cc: Kim Barrett ; ioi.lam at oracle.com; >>>> hotspot- >>>>>> dev at openjdk.java.net >>>>>>> Subject: RE: 8218811: replace open by os::open in hotspot coding - >> was : >>>>>> open-calls in hotspot code instead of os::open ? >>>>>>> >>>>>>>> fdStream::fdStream(const char* file_name) >>>>>>>> >>>>>>>> bool _need_close; >>>>>>>> >>>>>>>> and the close() call in the constructor? >>>>>>> >>>>>>> Hi, this has nothing to do with this change. >>>>>>> I have very bad experience with bringing in unrelated cleanups into a >>>>>> change my request after request etc. >>>>>>> >>>>>>> Will remove the os::open from CompileLog::finish_log_on_error() >>>> and >>>>>> the whitespace stuff. >>>>>>> >>>>>>> Thanks, Matthias >>>>>>> >>>>> From ChrisPhi at LGonQn.Org Fri Feb 22 03:31:46 2019 From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O) Date: Thu, 21 Feb 2019 22:31:46 -0500 Subject: CFV: New hotspot Group Member: Thomas Stuefe In-Reply-To: References: Message-ID: <112a5782-8874-4e04-021b-dbb431ff5044@LGonQn.Org> Vote: yes Cheers! Chris From david.holmes at oracle.com Fri Feb 22 03:54:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2019 13:54:49 +1000 Subject: RFR(S/T) : 8219158 : use 'test.root' property instead of traversing test-src path In-Reply-To: <944E04E7-08EB-4BD6-B522-F04957C6514B@oracle.com> References: <6DB6AB2B-4AF3-4605-AABA-D6EA088EB2D1@oracle.com> <3e57792e-1a41-c85a-3d94-bb04cd54d919@oracle.com> <4F54E082-1E76-4023-B105-8D4DF804F5D0@oracle.com> <36719e40-ba77-c1ff-25b4-f87b5efef266@oracle.com> <1AF2DEDC-D6DE-4DA9-B1A4-FE1082FA0202@oracle.com> <373f5b00-3289-3840-874b-741cf8d0b470@oracle.com> <944E04E7-08EB-4BD6-B522-F04957C6514B@oracle.com> Message-ID: <8f8f0880-510e-771b-53e2-c17d442f50c6@oracle.com> On 22/02/2019 4:25 am, Igor Ignatyev wrote: > > >> On Feb 21, 2019, at 1:20 AM, David Holmes wrote: >> >> On 21/02/2019 5:49 am, Igor Ignatyev wrote: >>> David, >>> I gave it a second though, and as this patch changes jdk/test/lib/Utils class, which potentially can be used by any of our test suites (and is already used by jdk and jaxp), it's safer to updated all TEST.ROOT files. this, as Alas mentioned in 8219417 RFR thread, requires some socialization and coordination. that's to say, I will hold pushing 8219158, till we get 8219417 integrated and/or come to another consensus. >> >> The change to the Utils class doesn't affect any tests that don't try to use TEST.ROOT. The Utils class itself is not dependent on the jtreg version as if the property does not exist it just returns an empty string. > > David, > > that's true, but my point was different. let's say someone is adding new tests which use this static field in jaxp test suite and we haven't updated requiredVersion there. so the person which adds new tests, tested them using jib, which means using jtreg4.2-b14, and the tests work as expected, and there is nothing in Utils which say "this property won't be available unless jtreg >= b14" (and I don't think we need such comment there), so this person doesn't have any reasons to update TEST.ROOT in jaxp test suite. however, next time someone who doesn't use jib or jtreg4.2-b14 runs jaxp test suites, all these tests fail. and, from my point of view, this case isn't much different from one you mentioned in this thread. therefore, I believe it'll be much safer/better if we update all TEST.ROOT files before we start to use any features from 4.2-b14 in shared classes. Okay. Thanks, David > Thanks, > -- Igor > >> Cheers, >> David >> >>> Cheers, >>> -- Igor >>>> On Feb 20, 2019, at 12:41 AM, David Holmes wrote: >>>> >>>> On 20/02/2019 5:05 pm, Igor Ignatyev wrote: >>>>> Hi David, >>>>> Hi David, >>>>> Hi David, >>> I don't know how this russian tradition to do things three times crept into my email ;) >>>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.0-1/index.html is the incremental webrev w/ bumping requiredVersion only in hotspot. >>>> >>>> Looks good. >>>> >>>> Thanks, >>>> David >>>> >>>>> -- Igor >>>>>> On Feb 19, 2019, at 10:48 PM, David Holmes > wrote: >>>>>> >>>>>> Hi Igor, >>>>>> >>>>>> On 20/02/2019 4:24 pm, Igor Ignatyev wrote: >>>>>>> Hi David, >>>>>>> you are right, I've filed 8219417 to do that in all test suites and sent RFR to jdk-dev alias. >>>>>> >>>>>> I responded to that RFR and I don't think it's the right approach. This bug should simply update the requiresVersion for the hotspot tests. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> -- Igor >>>>>>>> On Feb 19, 2019, at 10:07 PM, David Holmes > wrote: >>>>>>>> >>>>>>>> Hi Igor, >>>>>>>> >>>>>>>> On 20/02/2019 3:54 pm, Igor Ignatyev wrote: >>>>>>>>> http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>>>>>> 73 lines changed: 9 ins; 32 del; 32 mod; >>>>>>>>> Hi all, >>>>>>>>> could you please review this trivial clean-up? jtreg4.2-b14 added a new property 'test.root', this patches replaces all code in hotspot testbase which determines the root directory w/ simple reading of this property. >>>>>>>> >>>>>>>> You will have to update the jtreg requiresVersion to b14 to use this, else it will fail for anyone not using b14. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ---- >>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219158 >>>>>>>>> webrev: http://cr.openjdk.java.net/~iignatyev//8219158/webrev.00/index.html >>>>>>>>> testing: vmTestbase/gc/g1/unloading, vmTestbase/nsk/monitoring/stress, vmTestbase/vm/mlvm/, vmTestbase/vm/runtime/defmeth >>>>>>>>> Thanks, >>>>>>>>> -- Igor > From david.holmes at oracle.com Fri Feb 22 13:13:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Feb 2019 23:13:00 +1000 Subject: RFR: 8208278: [mlvm] Deadlocked threads are not always detected Message-ID: <9bf046e1-0198-6216-df16-9e152aa0b68e@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8208278/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8208278 The test was failing to find the expected deadlocks on OS X but it turns out that the test was simply racy and the race always lost on OS X. With logging enabled the test started failing on different platforms and in different ways. The main logic of the test is restructured so that we don't assume things will happen within a certain time but instead we loop (or block) until they do and rely on the overall test timeout to detect there may be a problem. Thanks, David From mikhailo.seledtsov at oracle.com Fri Feb 22 18:35:37 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 22 Feb 2019 10:35:37 -0800 Subject: RFR(S) : 8219139 : move hotspot tests from test/jdk/vm In-Reply-To: References: <036DE223-2FAB-43A4-BAC7-63A9BBFCA65D@oracle.com> <132812c3-56be-edfd-f812-78b30c75973b@oracle.com> Message-ID: ? Overall the change looks good; thank you Igor for doing this. I have couple of comments: ? - I am in favor of the approach where we move tests first under corresponding sub-component directories in ??? test/hotspot sub-tree, and then figure out whether to keep them. Even though in general I am in favor ??? of removing tests that are obsolete or of questionable value, this requires time, consideration and discussions. ??? Hence, I recommend filing an RFE for that, which can be addressed after the migration. ? - Runtime normally avoids tests directly in test/hotspot/jtreg/runtime ??? The tests should go into underlying sub-directories which best match functional area or topic of that test. ??? In most cases you did it in your change, but there are several tests that your change places directly under ???? test/hotspot/jtreg/runtime/: ???? ExplicitArithmeticCheck.java ???? MonitorCacheMaybeExpand_DeadLock.java ???? ReflectStackOverflow.java ???? ShiftTest.java - David commented this can go under compiler (a jit test) ???? WideStrictInline.java ???? Since we plan (as discussed) to follow up this work with an RFE to review and consider removal of old and ???? not-that-useful tests, you could place them under 'misc' for now. Alternatively, find the best match ???? or create new sub-directories under runtime/ if necessary. Thank you, Misha On 2/21/19 11:53 AM, Igor Ignatyev wrote: > >> On Feb 21, 2019, at 12:11 AM, David Holmes wrote: >> >> Hi Igor, >> >> On 21/02/2019 3:19 pm, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>>> 40 lines changed: 17 ins; 2 del; 21 mod; >>> Hi all, >>> could you please review this small patch which moves tests from test/jdk/vm? >> I find some of these tests - the runtime ones at least - of extremely dubious value. They either cover basic functionality that is already well covered, or are regression tests for bugs in code that hasn't existed for many many years! > as I wrote in another related email: "one of the reason I'm proposing this move is exactly questionable value of these tests, I want to believe that having these tests in hotspot/ test directories will bring more attention to them from corresponding component teams and hence they will be removed/reworked/re-whatever faster and better. and I also believe that one of the reason we got duplications exactly because these tests were located in jdk test suite." > >> BTW: >> >> test/hotspot/jtreg/runtime/ShiftTest.java >> >> is actually a jit test according to the test comment. > sure, I will move it to hotspot/compiler. >>> there are 16 tests in test/jdk/vm directory. all but JniInvocationTest are hotspot tests, so they are moved to test/hotspot test suite; JniInvocationTest is a launcher test >> No its a JNI invocation API test - nothing to do with our launcher. It belongs in runtime/jni. But we already have tests in runtime that use the JNI invocation API so this test adds no new coverage. > this is actually was my first reaction, and I even have the webrev which moves it to runtime/jni, but then I looked at the associated bug and it is filed against tools/launcher. and I even got a false (as I know by now) memory that I saw JLI_ method being called from the test. there is actually another test (dk/tools/launcher/exeJliLaunchTest.c) associated w/ this bug which calls JLI_Launch. anyhow, I'll move this test to hotspot/runtime/jni. > > >> I really think the value of these tests needs to be examined before they are brought over. > I'd prefer to have follow-up RFEs/tasks, b/c the longer we keep jdk/vm directory the more tests can end up there and the more rotten these tests become. > > Thanks, > -- Igor > >> Thanks, >> David >> ----- >> >>> and hence it's moved to test/jdk/tools/launcher. as hotspot/compiler and hotspot/gc tests use packages, the tests moved there have been updated to have a package statement. >>> webrev: http://cr.openjdk.java.net/~iignatyev//8219139/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8219139 >>> testing: tier[1-2] (in progress), all the touched tests locally >>> Thanks, >>> -- Igor From igor.ignatyev at oracle.com Fri Feb 22 19:04:11 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 22 Feb 2019 11:04:11 -0800 Subject: RFR: 8208278: [mlvm] Deadlocked threads are not always detected In-Reply-To: <9bf046e1-0198-6216-df16-9e152aa0b68e@oracle.com> References: <9bf046e1-0198-6216-df16-9e152aa0b68e@oracle.com> Message-ID: <8C1D089A-F421-4CD4-950B-5716A18724DC@oracle.com> Hi David, Overall looks reasonable. I have a couple of comments: - this INDIFY_Test.java was generated from INDIFY_Test.jmpp, so it'd be better to make changes in .jmpp file and regenerate .java - near L#18218, you changed for-loop to throw an exception as soon as we get 1st locked thread, this reduces amount of diagnostic information we would get in such failure scenarios, so I prefer checking _testFailed (or other bool) after the loop. > + // Sanity check that all the locks are available. > + for (int i = 0; i < THREAD_NUM; i++ ) { > + if (_locks[i].isLocked()) { > Env.getLog().complain("Lock " + i + " is still locked!"); > - _testFailed = true; > + throw new Exception("Some locks are still locked"); > } > } > > - if ( _testFailed ) > - throw new Exception("Some locks are still locked"); Thanks, -- Igor > On Feb 22, 2019, at 5:13 AM, David Holmes wrote: > > webrev: http://cr.openjdk.java.net/~dholmes/8208278/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8208278 > > The test was failing to find the expected deadlocks on OS X but it turns out that the test was simply racy and the race always lost on OS X. With logging enabled the test started failing on different platforms and in different ways. > > The main logic of the test is restructured so that we don't assume things will happen within a certain time but instead we loop (or block) until they do and rely on the overall test timeout to detect there may be a problem. > > Thanks, > David > > From igor.ignatyev at oracle.com Fri Feb 22 19:09:13 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 22 Feb 2019 11:09:13 -0800 Subject: RFR(S) : 8209807 : improve handling exception in requires.VMProps In-Reply-To: <46F68821-AB4B-4C07-9B19-AACA3C40D370@oracle.com> References: <46F68821-AB4B-4C07-9B19-AACA3C40D370@oracle.com> Message-ID: <8D5C895D-2BB8-43C1-8C18-D202E39AD2EA@oracle.com> ping > On Feb 19, 2019, at 9:53 PM, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html >> 122 lines changed: 30 ins; 25 del; 67 mod; > > Hi all, > > could you please review this patch which makes use of newly introduced error state of @requires properties[*] in jtreg? > > w/ this patch, we set a value w/ the well-known prefix in case any errors happen while we are getting property values. when jtreg sees this value, it set error statues to the test, which makes such cases more observable; simplifies root-cause analyze. and , arguably most importantly, jtreg now won't fail a whole test execution, and failure to get a property will affect only the tests which depend on that property. > > webrev: http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8209807 > testing: tier[1-2] and manually verified that errors are reported when they should be and affect only certain tests > > [*] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 > > Thanks, > -- Igor From mikhailo.seledtsov at oracle.com Fri Feb 22 22:08:38 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 22 Feb 2019 14:08:38 -0800 Subject: RFR(S) : 8209807 : improve handling exception in requires.VMProps In-Reply-To: <46F68821-AB4B-4C07-9B19-AACA3C40D370@oracle.com> References: <46F68821-AB4B-4C07-9B19-AACA3C40D370@oracle.com> Message-ID: Looks good, Misha On 2/19/19 9:53 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html >> 122 lines changed: 30 ins; 25 del; 67 mod; > Hi all, > > could you please review this patch which makes use of newly introduced error state of @requires properties[*] in jtreg? > > w/ this patch, we set a value w/ the well-known prefix in case any errors happen while we are getting property values. when jtreg sees this value, it set error statues to the test, which makes such cases more observable; simplifies root-cause analyze. and , arguably most importantly, jtreg now won't fail a whole test execution, and failure to get a property will affect only the tests which depend on that property. > > webrev: http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8209807 > testing: tier[1-2] and manually verified that errors are reported when they should be and affect only certain tests > > [*] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 > > Thanks, > -- Igor > From vladimir.x.ivanov at oracle.com Fri Feb 22 22:34:00 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 22 Feb 2019 14:34:00 -0800 Subject: RFR(S) : 8209807 : improve handling exception in requires.VMProps In-Reply-To: <46F68821-AB4B-4C07-9B19-AACA3C40D370@oracle.com> References: <46F68821-AB4B-4C07-9B19-AACA3C40D370@oracle.com> Message-ID: Looks good. Best regards, Vladimir Ivanov On 19/02/2019 21:53, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html >> 122 lines changed: 30 ins; 25 del; 67 mod; > > Hi all, > > could you please review this patch which makes use of newly introduced error state of @requires properties[*] in jtreg? > > w/ this patch, we set a value w/ the well-known prefix in case any errors happen while we are getting property values. when jtreg sees this value, it set error statues to the test, which makes such cases more observable; simplifies root-cause analyze. and , arguably most importantly, jtreg now won't fail a whole test execution, and failure to get a property will affect only the tests which depend on that property. > > webrev: http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8209807 > testing: tier[1-2] and manually verified that errors are reported when they should be and affect only certain tests > > [*] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 > > Thanks, > -- Igor > > From igor.ignatyev at oracle.com Fri Feb 22 22:45:08 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 22 Feb 2019 14:45:08 -0800 Subject: RFR(S) : 8209807 : improve handling exception in requires.VMProps In-Reply-To: References: <46F68821-AB4B-4C07-9B19-AACA3C40D370@oracle.com> Message-ID: <821025DA-5CE1-4195-8B0E-928DB51D2F5D@oracle.com> Vladimir, Misha thank you for the review, pushed. -- Igor > On Feb 22, 2019, at 2:34 PM, Vladimir Ivanov wrote: > > Looks good. > > Best regards, > Vladimir Ivanov > > On 19/02/2019 21:53, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html >>> 122 lines changed: 30 ins; 25 del; 67 mod; >> Hi all, >> could you please review this patch which makes use of newly introduced error state of @requires properties[*] in jtreg? >> w/ this patch, we set a value w/ the well-known prefix in case any errors happen while we are getting property values. when jtreg sees this value, it set error statues to the test, which makes such cases more observable; simplifies root-cause analyze. and , arguably most importantly, jtreg now won't fail a whole test execution, and failure to get a property will affect only the tests which depend on that property. >> webrev: http://cr.openjdk.java.net/~iignatyev//8209807/webrev.01/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209807 >> testing: tier[1-2] and manually verified that errors are reported when they should be and affect only certain tests >> [*] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 >> Thanks, >> -- Igor >> From david.holmes at oracle.com Fri Feb 22 23:16:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 Feb 2019 09:16:23 +1000 Subject: RFR: 8208278: [mlvm] Deadlocked threads are not always detected In-Reply-To: <8C1D089A-F421-4CD4-950B-5716A18724DC@oracle.com> References: <9bf046e1-0198-6216-df16-9e152aa0b68e@oracle.com> <8C1D089A-F421-4CD4-950B-5716A18724DC@oracle.com> Message-ID: Hi Igor, On 23/02/2019 5:04 am, Igor Ignatyev wrote: > Hi David, > > Overall looks reasonable. I have a couple of comments: > ?- this INDIFY_Test.java was generated from INDIFY_Test.jmpp, so it'd > be better to make changes in .jmpp file and regenerate .java Oh! Did not realize that. How do you regenerate the .java file ?? > ?- near L#18218, you changed for-loop to throw an exception as soon as > we get 1st locked thread, this reduces amount of diagnostic information > we would get in such failure scenarios, so I prefer checking _testFailed > (or other bool) after the loop. Note this loop is just a sanity check that the locks (not the threads) are not locked before we start - which should always be the case if we correctly join()'d all threads on previous iteration. There's very little diagnostic information here (it doesn't even try to tell you which thread owns the lock!) But I can move it back to after the loop. Thanks, David >> + // Sanity check that all the locks are available. >> + for (int i = 0; i < THREAD_NUM; i++ ) { >> + if (_locks[i].isLocked()) { >> Env.getLog().complain("Lock " + i + " is still locked!"); >> - _testFailed = true; >> + throw new Exception("Some locks are still locked"); >> } >> } >> >> - if ( _testFailed ) >> - throw new Exception("Some locks are still locked"); > > Thanks, > -- Igor > >> On Feb 22, 2019, at 5:13 AM, David Holmes > > wrote: >> >> webrev: http://cr.openjdk.java.net/~dholmes/8208278/webrev/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8208278 >> >> The test was failing to find the expected deadlocks on OS X but it >> turns out that the test was simply racy and the race always lost on OS >> X. With logging enabled the test started failing on different >> platforms and in different ways. >> >> The main logic of the test is restructured so that we don't assume >> things will happen within a certain time but instead we loop (or >> block) until they do and rely on the overall test timeout to detect >> there may be a problem. >> >> Thanks, >> David >> >> > From david.holmes at oracle.com Sat Feb 23 05:29:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 Feb 2019 15:29:50 +1000 Subject: RFR: 8208278: [mlvm] Deadlocked threads are not always detected In-Reply-To: References: <9bf046e1-0198-6216-df16-9e152aa0b68e@oracle.com> <8C1D089A-F421-4CD4-950B-5716A18724DC@oracle.com> Message-ID: Hi Igor, jmpp updated and java file regenerated: http://cr.openjdk.java.net/~dholmes/8208278/webrev.v2/ and _locks[i].isLocked() loop behaviour restored. Thanks, David On 23/02/2019 9:16 am, David Holmes wrote: > Hi Igor, > > On 23/02/2019 5:04 am, Igor Ignatyev wrote: >> Hi David, >> >> Overall looks reasonable. I have a couple of comments: >> ??- this INDIFY_Test.java was generated from INDIFY_Test.jmpp, so it'd >> be better to make changes in .jmpp file and regenerate .java > > Oh! Did not realize that. How do you regenerate the .java file ?? > >> ??- near L#18218, you changed for-loop to throw an exception as soon >> as we get 1st locked thread, this reduces amount of diagnostic >> information we would get in such failure scenarios, so I prefer >> checking _testFailed (or other bool) after the loop. > > Note this loop is just a sanity check that the locks (not the threads) > are not locked before we start - which should always be the case if we > correctly join()'d all threads on previous iteration. There's very > little diagnostic information here (it doesn't even try to tell you > which thread owns the lock!) But I can move it back to after the loop. > > Thanks, > David > >>> + // Sanity check that all the locks are available. >>> + for (int i = 0; i < THREAD_NUM; i++ ) { >>> + if (_locks[i].isLocked()) { >>> ????????????????? Env.getLog().complain("Lock " + i + " is still >>> locked!"); >>> - _testFailed = true; >>> + throw new Exception("Some locks are still locked"); >>> ????????????? } >>> ????????? } >>> - if ( _testFailed ) >>> - throw new Exception("Some locks are still locked"); >> >> Thanks, >> -- Igor >> >>> On Feb 22, 2019, at 5:13 AM, David Holmes >> > wrote: >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8208278/webrev/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8208278 >>> >>> The test was failing to find the expected deadlocks on OS X but it >>> turns out that the test was simply racy and the race always lost on >>> OS X. With logging enabled the test started failing on different >>> platforms and in different ways. >>> >>> The main logic of the test is restructured so that we don't assume >>> things will happen within a certain time but instead we loop (or >>> block) until they do and rely on the overall test timeout to detect >>> there may be a problem. >>> >>> Thanks, >>> David >>> >>> >> From igor.ignatyev at oracle.com Sat Feb 23 05:35:25 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 22 Feb 2019 21:35:25 -0800 Subject: RFR: 8208278: [mlvm] Deadlocked threads are not always detected In-Reply-To: References: <9bf046e1-0198-6216-df16-9e152aa0b68e@oracle.com> <8C1D089A-F421-4CD4-950B-5716A18724DC@oracle.com> Message-ID: Hi David, looks good to me. -- Igor > On Feb 22, 2019, at 9:29 PM, David Holmes wrote: > > Hi Igor, > > jmpp updated and java file regenerated: > > http://cr.openjdk.java.net/~dholmes/8208278/webrev.v2/ > > and _locks[i].isLocked() loop behaviour restored. > > Thanks, > David > > On 23/02/2019 9:16 am, David Holmes wrote: >> Hi Igor, >> On 23/02/2019 5:04 am, Igor Ignatyev wrote: >>> Hi David, >>> >>> Overall looks reasonable. I have a couple of comments: >>> - this INDIFY_Test.java was generated from INDIFY_Test.jmpp, so it'd be better to make changes in .jmpp file and regenerate .java >> Oh! Did not realize that. How do you regenerate the .java file ?? >>> - near L#18218, you changed for-loop to throw an exception as soon as we get 1st locked thread, this reduces amount of diagnostic information we would get in such failure scenarios, so I prefer checking _testFailed (or other bool) after the loop. >> Note this loop is just a sanity check that the locks (not the threads) are not locked before we start - which should always be the case if we correctly join()'d all threads on previous iteration. There's very little diagnostic information here (it doesn't even try to tell you which thread owns the lock!) But I can move it back to after the loop. >> Thanks, >> David >>>> + // Sanity check that all the locks are available. >>>> + for (int i = 0; i < THREAD_NUM; i++ ) { >>>> + if (_locks[i].isLocked()) { >>>> Env.getLog().complain("Lock " + i + " is still locked!"); >>>> - _testFailed = true; >>>> + throw new Exception("Some locks are still locked"); >>>> } >>>> } >>>> - if ( _testFailed ) >>>> - throw new Exception("Some locks are still locked"); >>> >>> Thanks, >>> -- Igor >>> >>>> On Feb 22, 2019, at 5:13 AM, David Holmes > wrote: >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8208278/webrev/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208278 >>>> >>>> The test was failing to find the expected deadlocks on OS X but it turns out that the test was simply racy and the race always lost on OS X. With logging enabled the test started failing on different platforms and in different ways. >>>> >>>> The main logic of the test is restructured so that we don't assume things will happen within a certain time but instead we loop (or block) until they do and rely on the overall test timeout to detect there may be a problem. >>>> >>>> Thanks, >>>> David >>>> >>>> >>> From david.holmes at oracle.com Sat Feb 23 05:52:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 Feb 2019 15:52:04 +1000 Subject: RFR: 8208278: [mlvm] Deadlocked threads are not always detected In-Reply-To: References: <9bf046e1-0198-6216-df16-9e152aa0b68e@oracle.com> <8C1D089A-F421-4CD4-950B-5716A18724DC@oracle.com> Message-ID: <8be55227-c56c-8786-cbed-0263e97a2974@oracle.com> Thanks Igor! I'll wait til Monday morning to see if anyone else comments, else I'll push this. David On 23/02/2019 3:35 pm, Igor Ignatyev wrote: > Hi David, > > looks good to me. > > -- Igor > >> On Feb 22, 2019, at 9:29 PM, David Holmes wrote: >> >> Hi Igor, >> >> jmpp updated and java file regenerated: >> >> http://cr.openjdk.java.net/~dholmes/8208278/webrev.v2/ >> >> and _locks[i].isLocked() loop behaviour restored. >> >> Thanks, >> David >> >> On 23/02/2019 9:16 am, David Holmes wrote: >>> Hi Igor, >>> On 23/02/2019 5:04 am, Igor Ignatyev wrote: >>>> Hi David, >>>> >>>> Overall looks reasonable. I have a couple of comments: >>>> - this INDIFY_Test.java was generated from INDIFY_Test.jmpp, so it'd be better to make changes in .jmpp file and regenerate .java >>> Oh! Did not realize that. How do you regenerate the .java file ?? >>>> - near L#18218, you changed for-loop to throw an exception as soon as we get 1st locked thread, this reduces amount of diagnostic information we would get in such failure scenarios, so I prefer checking _testFailed (or other bool) after the loop. >>> Note this loop is just a sanity check that the locks (not the threads) are not locked before we start - which should always be the case if we correctly join()'d all threads on previous iteration. There's very little diagnostic information here (it doesn't even try to tell you which thread owns the lock!) But I can move it back to after the loop. >>> Thanks, >>> David >>>>> + // Sanity check that all the locks are available. >>>>> + for (int i = 0; i < THREAD_NUM; i++ ) { >>>>> + if (_locks[i].isLocked()) { >>>>> Env.getLog().complain("Lock " + i + " is still locked!"); >>>>> - _testFailed = true; >>>>> + throw new Exception("Some locks are still locked"); >>>>> } >>>>> } >>>>> - if ( _testFailed ) >>>>> - throw new Exception("Some locks are still locked"); >>>> >>>> Thanks, >>>> -- Igor >>>> >>>>> On Feb 22, 2019, at 5:13 AM, David Holmes > wrote: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8208278/webrev/ >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208278 >>>>> >>>>> The test was failing to find the expected deadlocks on OS X but it turns out that the test was simply racy and the race always lost on OS X. With logging enabled the test started failing on different platforms and in different ways. >>>>> >>>>> The main logic of the test is restructured so that we don't assume things will happen within a certain time but instead we loop (or block) until they do and rely on the overall test timeout to detect there may be a problem. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>> > From christoph.langer at sap.com Mon Feb 25 14:26:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 25 Feb 2019 14:26:13 +0000 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" Message-ID: Hi, please review the following small test fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ JDK-8217994 introduced a new gtest "test_print_hex_dump". This test calls os::print_hex_dump on a potentially unaligned address because the array that is dumped in the test is just placed on the stack. I try to avoid that by mallocing and hence getting a better aligned placement. Another minor issue is that the test should be run as TEST_VM, because it uses VM facilities such as ResourceMark. We've observed a crash on a Solaris machine during jdk11u testing. I'll run the fix through our test system and if it passes and fixes the crash, I'll also request backporting to jdk12u and jdk11u. Thanks Christoph From erik.osterlund at oracle.com Mon Feb 25 14:28:08 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 25 Feb 2019 15:28:08 +0100 Subject: RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean In-Reply-To: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> References: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> Message-ID: <7a2714b0-71df-5c82-890c-39db6c4843f7@oracle.com> Hi, Ping. Thanks, /Erik On 2019-02-18 13:01, Erik ?sterlund wrote: > Hi, > > When transitioning CompiledICs to clean, we sometimes need to use > transitional states (using JIT-compiled ICStubs). > The trick is that today when we clean ICs, we atomically and logically > write NULL to the data section, and set the destination to some > resolve stub. In reality, the NULL gets translated to > Universe::non_oop_word. But the point is that in order to set both > data and destination atomically, we use an ICStub. > > ...but we don't need to set them both. > > When the inline cache is cleaned, the data part is no longer relevant, > and could really be set to any nonsense value, as long as subsequent > transitions away from that cleaned inline cache > (monomorphic/interpreted) uses a transitional state to do so. > I suspect that at some point in time, when inline caches pointed at > oops in perm gen or something, it was crucial that the data part of > the inline cache made sense to the GC. This is not the case today, and > we can just ignore the value pretending it doesn't exist instead. > > The benefit with deferring the use of transitional state to when > someone performs a subsequent transition away from clean > (set_to_monomorphic), is that all code paths where cleaning inline > caches fail can be removed. This in particular simplifies the sweeper > and ZGC nmethod unloading code, that needs to handle failures in > inline cache cleaning due to running out of ICStubs forcing us to > trigger safepoints to refill IC stubs. It should also reduce the > overall number of safepoints due to running out of ICStubs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219101 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8219101/webrev.00/ > > Testing: mach5 hs-tier1-5. > > Thanks, > /Erik From thomas.stuefe at gmail.com Mon Feb 25 14:32:22 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Feb 2019 15:32:22 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: References: Message-ID: Looks good. ..Thomas On Mon, Feb 25, 2019 at 3:26 PM Langer, Christoph wrote: > Hi, > > > > please review the following small test fix. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ > > > > JDK-8217994 introduced a new gtest ?test_print_hex_dump?. This test calls > os::print_hex_dump on a potentially unaligned address because the array > that is dumped in the test is just placed on the stack. I try to avoid that > by mallocing and hence getting a better aligned placement. Another minor > issue is that the test should be run as TEST_VM, because it uses VM > facilities such as ResourceMark. > > > > We?ve observed a crash on a Solaris machine during jdk11u testing. I?ll > run the fix through our test system and if it passes and fixes the crash, > I?ll also request backporting to jdk12u and jdk11u. > > > > Thanks > > Christoph > > > From shade at redhat.com Mon Feb 25 14:44:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Feb 2019 15:44:08 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: References: Message-ID: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> On 2/25/19 3:26 PM, Langer, Christoph wrote: > please review the following small test fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ Looks good to me. If you will, I'd prefer to allocate char* to guarantee the size of array. -Aleksey From shade at redhat.com Mon Feb 25 14:46:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Feb 2019 15:46:52 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> Message-ID: <4c47d099-94ec-4015-74b0-78650e9c4371@redhat.com> On 2/25/19 3:44 PM, Aleksey Shipilev wrote: > On 2/25/19 3:26 PM, Langer, Christoph wrote: >> please review the following small test fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ > > Looks good to me. > > If you will, I'd prefer to allocate char* to guarantee the size of array. I wonder, separately, if print_hex_dump should be resilient against unaligned addresses too, e.g. aligning the start by machine word width? It could be called from VM code with whatever start/end, I think. -Aleksey From shade at redhat.com Mon Feb 25 15:00:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Feb 2019 16:00:08 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: <4c47d099-94ec-4015-74b0-78650e9c4371@redhat.com> References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <4c47d099-94ec-4015-74b0-78650e9c4371@redhat.com> Message-ID: <06c3d2d9-2ca0-99b2-d6fc-7dc4086932bc@redhat.com> On 2/25/19 3:46 PM, Aleksey Shipilev wrote: > On 2/25/19 3:44 PM, Aleksey Shipilev wrote: >> On 2/25/19 3:26 PM, Langer, Christoph wrote: >>> please review the following small test fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ >> >> Looks good to me. >> >> If you will, I'd prefer to allocate char* to guarantee the size of array. > > I wonder, separately, if print_hex_dump should be resilient against unaligned addresses too, e.g. > aligning the start by machine word width? It could be called from VM code with whatever start/end, I > think. ...and print_hex_dump is supposed to be resilient, because I'd expect SafeFetch to handle SIGBUS from unaligned accesses too. I see the signal handler for linux_x86 and solaris_x86 handle all signals, not only SEGVs. So, why did the test SIGBUS'ed? What a rabbit hole. -Aleksey From christoph.langer at sap.com Mon Feb 25 15:23:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 25 Feb 2019 15:23:47 +0000 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: <06c3d2d9-2ca0-99b2-d6fc-7dc4086932bc@redhat.com> References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <4c47d099-94ec-4015-74b0-78650e9c4371@redhat.com> <06c3d2d9-2ca0-99b2-d6fc-7dc4086932bc@redhat.com> Message-ID: <9a6abe0b2f6744cb83b453e1f5989c12@sap.com> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 > >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ > >> > >> Looks good to me. > >> > >> If you will, I'd prefer to allocate char* to guarantee the size of array. > > > > I wonder, separately, if print_hex_dump should be resilient against > unaligned addresses too, e.g. > > aligning the start by machine word width? It could be called from VM code > with whatever start/end, I > > think. I discussed that with Thomas. Maybe we should align the start address down to unitsize in os::print_hex_dump, instead of asserting. > ...and print_hex_dump is supposed to be resilient, because I'd expect > SafeFetch to handle SIGBUS > from unaligned accesses too. I see the signal handler for linux_x86 and > solaris_x86 handle all > signals, not only SEGVs. So, why did the test SIGBUS'ed? What a rabbit hole. Good point, will see if we can figure out more. Interestingly, the test crashes on one Solaris machine (that tests jdk11u here), but not on another (where jdk/jdk is tested). From ralf.schmelter at sap.com Mon Feb 25 15:29:35 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Mon, 25 Feb 2019 15:29:35 +0000 Subject: RFR (S) 8219577: Returning NULL in a function which returns bools Message-ID: <1d4a36885dca45fea97221fe13910ba8@sap.com> Please review this change which replaces 2 'return NULL' with 'return false' in a method returning bools. Since this is in windows only code, the fix was only tested on windows. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8219577/webrev.0/ bug: https://bugs.openjdk.java.net/browse/JDK-8219577 Best regards, Ralf From shade at redhat.com Mon Feb 25 15:39:51 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Feb 2019 16:39:51 +0100 Subject: RFR (S) 8219577: Returning NULL in a function which returns bools In-Reply-To: <1d4a36885dca45fea97221fe13910ba8@sap.com> References: <1d4a36885dca45fea97221fe13910ba8@sap.com> Message-ID: <68740e70-eb9b-0861-29ac-147578841872@redhat.com> On 2/25/19 4:29 PM, Schmelter, Ralf wrote: > Please review this change which replaces 2 'return NULL' with 'return false' in a method returning bools. Since this is in windows only code, the fix was only tested on windows. > > webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8219577/webrev.0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8219577 Looks good to me. -Aleksey From shade at redhat.com Mon Feb 25 15:43:29 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Feb 2019 16:43:29 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: <9a6abe0b2f6744cb83b453e1f5989c12@sap.com> References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <4c47d099-94ec-4015-74b0-78650e9c4371@redhat.com> <06c3d2d9-2ca0-99b2-d6fc-7dc4086932bc@redhat.com> <9a6abe0b2f6744cb83b453e1f5989c12@sap.com> Message-ID: On 2/25/19 4:23 PM, Langer, Christoph wrote: > I discussed that with Thomas. Maybe we should align the start address down to unitsize in > os::print_hex_dump, instead of asserting. Yup. It is also arguably better UX: no matter what the start address is, we would always "granulate" the dumped memory the same way. >> ...and print_hex_dump is supposed to be resilient, because I'd expect SafeFetch to handle >> SIGBUS from unaligned accesses too. I see the signal handler for linux_x86 and solaris_x86 >> handle all signals, not only SEGVs. So, why did the test SIGBUS'ed? What a rabbit hole. > > Good point, will see if we can figure out more. Interestingly, the test crashes on one Solaris > machine (that tests jdk11u here), but not on another (where jdk/jdk is tested). Also, Oracle testing presumably builds/runs/tests Solaris, and there were no bug reports about it. It looks that test had caught a legit problem, and as such does not look like a testbug. -Aleksey From zgu at redhat.com Mon Feb 25 15:44:32 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Mon, 25 Feb 2019 10:44:32 -0500 Subject: RFR (S) 8219577: Returning NULL in a function which returns bools In-Reply-To: <1d4a36885dca45fea97221fe13910ba8@sap.com> References: <1d4a36885dca45fea97221fe13910ba8@sap.com> Message-ID: <1551109472.18805.7.camel@redhat.com> Looks good. -Zhengyu On Mon, 2019-02-25 at 15:29 +0000, Schmelter, Ralf wrote: > Please review this change which replaces 2 'return NULL' with 'return > false' in a method returning bools. Since this is in windows only > code, the fix was only tested on windows. > > webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8219577/webrev > .0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8219577 > > Best regards, > Ralf From christoph.langer at sap.com Mon Feb 25 15:52:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 25 Feb 2019 15:52:46 +0000 Subject: RFR (S) 8219577: Returning NULL in a function which returns bools In-Reply-To: <1d4a36885dca45fea97221fe13910ba8@sap.com> References: <1d4a36885dca45fea97221fe13910ba8@sap.com> Message-ID: Hi Ralf, looks good. I'll sponsor it. Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Schmelter, Ralf > Sent: Montag, 25. Februar 2019 16:30 > To: HotSpot Open Source Developers > Subject: RFR (S) 8219577: Returning NULL in a function which returns bools > > Please review this change which replaces 2 'return NULL' with 'return false' in > a method returning bools. Since this is in windows only code, the fix was only > tested on windows. > > webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8219577/webrev.0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8219577 > > Best regards, > Ralf From thomas.stuefe at gmail.com Mon Feb 25 15:53:27 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 Feb 2019 16:53:27 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <4c47d099-94ec-4015-74b0-78650e9c4371@redhat.com> <06c3d2d9-2ca0-99b2-d6fc-7dc4086932bc@redhat.com> <9a6abe0b2f6744cb83b453e1f5989c12@sap.com> Message-ID: On Mon, Feb 25, 2019 at 4:43 PM Aleksey Shipilev wrote: > On 2/25/19 4:23 PM, Langer, Christoph wrote: > > I discussed that with Thomas. Maybe we should align the start address > down to unitsize in > > os::print_hex_dump, instead of asserting. > > Yup. It is also arguably better UX: no matter what the start address is, > we would always "granulate" > the dumped memory the same way. > Yes. > > >> ...and print_hex_dump is supposed to be resilient, because I'd expect > SafeFetch to handle > >> SIGBUS from unaligned accesses too. I see the signal handler for > linux_x86 and solaris_x86 > >> handle all signals, not only SEGVs. So, why did the test SIGBUS'ed? > What a rabbit hole. > > > It does, but not in a TEST since there no signal handler are installed. In TEST_VM, VM is initialized, signal handler installed, is_readable_pointer would work and the output would be empty. > > Good point, will see if we can figure out more. Interestingly, the test > crashes on one Solaris > > machine (that tests jdk11u here), but not on another (where jdk/jdk is > tested). > > Also, Oracle testing presumably builds/runs/tests Solaris, and there were > no bug reports about it. > > Note that this bug depends on the location of your stack local test array. If C++ compiler happens to put it onto a quadword aligned address, error is hidden. > It looks that test had caught a legit problem, and as such does not look > like a testbug. > > Well, using TEST_VM instead of TEST is. The alignment stuff is not. > -Aleksey > > From shade at redhat.com Mon Feb 25 15:57:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 Feb 2019 16:57:59 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <4c47d099-94ec-4015-74b0-78650e9c4371@redhat.com> <06c3d2d9-2ca0-99b2-d6fc-7dc4086932bc@redhat.com> <9a6abe0b2f6744cb83b453e1f5989c12@sap.com> Message-ID: On 2/25/19 4:53 PM, Thomas St?fe wrote: > On Mon, Feb 25, 2019 at 4:43 PM Aleksey Shipilev > wrote: > It looks that test had caught a legit problem, and as such does not look like a testbug. > > Well, using TEST_VM instead of TEST is. The alignment stuff is not. Right, right. So let's keep the stack allocation intact, and just change TEST -> TEST_VM? Does that help to resolve the crash on that Solaris machine where 11u is failing for you? -Aleksey From christoph.langer at sap.com Mon Feb 25 16:34:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 25 Feb 2019 16:34:30 +0000 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <4c47d099-94ec-4015-74b0-78650e9c4371@redhat.com> <06c3d2d9-2ca0-99b2-d6fc-7dc4086932bc@redhat.com> <9a6abe0b2f6744cb83b453e1f5989c12@sap.com> Message-ID: > Right, right. So let's keep the stack allocation intact, and just change TEST -> > TEST_VM? Does that > help to resolve the crash on that Solaris machine where 11u is failing for you? I'll check that. Then this would be the least invasive test fix. And I'd open another issue for making print_hex_dump even more resilient and maybe improving the test to check the results and test unaligned addresses specifically. But that'll be a jdk/jdk follow up then... /Christoph From dean.long at oracle.com Tue Feb 26 07:29:51 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 25 Feb 2019 23:29:51 -0800 Subject: RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean In-Reply-To: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> References: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> Message-ID: <65c8cd8f-7ac9-da33-9a84-254a0699fbb5@oracle.com> Is there any need for is_safe_for_patching() anymore? entry_point == _call->get_resolve_call_stub(is_optimized() is used in several places.? Can we refactor it into something like is_clean()? (I realize that name is taken.) Undoing an ICStub (it appears this happens in ICStub::finalize) also sets both data and destination, so it needs to be done at a safepoint.? Can we add an assert there to document that? Unrelated to your change, but the comment "called when a method is removed" for ICStub::finalize in icBuffer.hpp doesn't sound right to me. Also, not part of your change, but in CompiledIC::internal_set_ic_destination(), don't we need a memory barrier between setting the entry point and setting the data? In CompiledIC::set_to_monomorphic(), why is the following transition safe?? I would think we need a transition stub here: 446 } else if (!is_in_transition_state() && get_data() == Universe::non_oop_word()) { 447 set_ic_destination_and_value(info.entry(), info.cached_metadata()); I would feel better if there was a complete state diagram that captured all the important details.? There is a small one in compiledIC.hpp but it doesn't capture everything, especially ICStub transitions and safepoints. dl On 2/18/19 4:01 AM, Erik ?sterlund wrote: > Hi, > > When transitioning CompiledICs to clean, we sometimes need to use > transitional states (using JIT-compiled ICStubs). > The trick is that today when we clean ICs, we atomically and logically > write NULL to the data section, and set the destination to some > resolve stub. In reality, the NULL gets translated to > Universe::non_oop_word. But the point is that in order to set both > data and destination atomically, we use an ICStub. > > ...but we don't need to set them both. > > When the inline cache is cleaned, the data part is no longer relevant, > and could really be set to any nonsense value, as long as subsequent > transitions away from that cleaned inline cache > (monomorphic/interpreted) uses a transitional state to do so. > I suspect that at some point in time, when inline caches pointed at > oops in perm gen or something, it was crucial that the data part of > the inline cache made sense to the GC. This is not the case today, and > we can just ignore the value pretending it doesn't exist instead. > > The benefit with deferring the use of transitional state to when > someone performs a subsequent transition away from clean > (set_to_monomorphic), is that all code paths where cleaning inline > caches fail can be removed. This in particular simplifies the sweeper > and ZGC nmethod unloading code, that needs to handle failures in > inline cache cleaning due to running out of ICStubs forcing us to > trigger safepoints to refill IC stubs. It should also reduce the > overall number of safepoints due to running out of ICStubs. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8219101 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8219101/webrev.00/ > > Testing: mach5 hs-tier1-5. > > Thanks, > /Erik From matthias.baesken at sap.com Tue Feb 26 08:01:35 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Feb 2019 08:01:35 +0000 Subject: RFR [XS]: 8219630: cleanup hotspot ostream.cpp Message-ID: Hello, please review this small patch . In the review process of 8218811 it has been noticed that ostream.cpp can be cleaned up a bit ; I want to address the cleanups with this change . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219630 http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.0/ Thanks, Matthias From thomas.stuefe at gmail.com Tue Feb 26 08:13:14 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 26 Feb 2019 09:13:14 +0100 Subject: RFR [XS]: 8219630: cleanup hotspot ostream.cpp In-Reply-To: References: Message-ID: Looks good. Good as it is, but since you are touching the code: - you could use initializer list instead in the ctor: fdStream(int fd = -1) : _fd(fd) {} - you could remove the whole destructor, since it does nothing of value anymore. Cheers Thomas On Tue, Feb 26, 2019 at 9:02 AM Baesken, Matthias wrote: > Hello, please review this small patch . > > In the review process of 8218811 it has been noticed that ostream.cpp > can be cleaned up a bit ; I want to address the cleanups with this change > . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8219630 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.0/ > > > Thanks, Matthias > > From matthias.baesken at sap.com Tue Feb 26 08:47:40 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Feb 2019 08:47:40 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 Message-ID: Hello , please review the following change. It provides basic virtualization related information in the hs_error file on linux/windows x86_64. We use cpuid to get the information (detection of VMWare, Xen, KVM and HyperV is included). Some info about how to detect the virtualization info can be found here : https://kb.vmware.com/s/article/1009458 (it is VMware related but can be applied for other virtualization technologies as well) An overview of the ID strings can be found here as well : https://en.wikipedia.org/wiki/CPUID The following are known ID strings from virtual machines: ... bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219241 http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.1/ Thanks, Matthias From matthias.baesken at sap.com Tue Feb 26 09:05:14 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Feb 2019 09:05:14 +0000 Subject: RFR [XS]: 8219630: cleanup hotspot ostream.cpp In-Reply-To: References: Message-ID: Hi Thomas, thanks for the review ! > >- you could remove the whole destructor, since it does nothing of value anymore. >- you could use initializer list instead in the ctor: > fdStream(int fd = -1) : _fd(fd) {} Sure, new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.1/ Best regards, Matthias From: Thomas St?fe Sent: Dienstag, 26. Februar 2019 09:13 To: Baesken, Matthias Cc: hotspot-dev at openjdk.java.net Subject: Re: RFR [XS]: 8219630: cleanup hotspot ostream.cpp Looks good. Good as it is, but since you are touching the code: - you could use initializer list instead in the ctor: fdStream(int fd = -1) : _fd(fd) {} - you could remove the whole destructor, since it does nothing of value anymore. Cheers Thomas On Tue, Feb 26, 2019 at 9:02 AM Baesken, Matthias > wrote: Hello, please review this small patch . In the review process of 8218811 it has been noticed that ostream.cpp can be cleaned up a bit ; I want to address the cleanups with this change . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219630 http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.0/ Thanks, Matthias From thomas.stuefe at gmail.com Tue Feb 26 09:12:25 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 26 Feb 2019 10:12:25 +0100 Subject: RFR [XS]: 8219630: cleanup hotspot ostream.cpp In-Reply-To: References: Message-ID: all good now :) On Tue, Feb 26, 2019 at 10:05 AM Baesken, Matthias wrote: > Hi Thomas, thanks for the review ! > > > > > > > >- you could remove the whole destructor, since it does nothing of value > anymore. > > >- you could use initializer list instead in the ctor: > > > fdStream(int fd = -1) : _fd(fd) {} > > > > Sure, new webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.1/ > > > > > > Best regards, Matthias > > > > > > *From:* Thomas St?fe > *Sent:* Dienstag, 26. Februar 2019 09:13 > *To:* Baesken, Matthias > *Cc:* hotspot-dev at openjdk.java.net > *Subject:* Re: RFR [XS]: 8219630: cleanup hotspot ostream.cpp > > > > Looks good. > > > > Good as it is, but since you are touching the code: > > > > - you could use initializer list instead in the ctor: > > fdStream(int fd = -1) : _fd(fd) {} > > > > - you could remove the whole destructor, since it does nothing of value > anymore. > > > > Cheers Thomas > > > > > > > > On Tue, Feb 26, 2019 at 9:02 AM Baesken, Matthias < > matthias.baesken at sap.com> wrote: > > Hello, please review this small patch . > > In the review process of 8218811 it has been noticed that ostream.cpp > can be cleaned up a bit ; I want to address the cleanups with this change > . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8219630 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.0/ > > > Thanks, Matthias > > From ralf.schmelter at sap.com Tue Feb 26 11:24:29 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 26 Feb 2019 11:24:29 +0000 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs Message-ID: <960a11003daa403fbc8bb841206b8853@sap.com> Please review the following small patch. It increases the code_size2 constant by 1000 bytes, since it was too small when doing a Windows slowdebug build on my Skylake based system. I've increased code_isze2 in 500 bytes increments and 1000 additional bytes was need to avoid the assertion indicating we are exceeding the reserved code space. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.0/ bug: https://bugs.openjdk.java.net/browse/JDK-8219712 Best regards, Ralf From matthias.baesken at sap.com Tue Feb 26 11:51:44 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 26 Feb 2019 11:51:44 +0000 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs Message-ID: Hi Ralf, looks good to me (not a Reviewer however). I wonder - do you see the issue only in the debug builds ? (if yes , one could maybe consider adding some constant in " code_size2 = 36300 LP64_ONLY(+10000) " for debug builds in the same way we do already for 64bit ) Best regards, Matthias > Date: Tue, 26 Feb 2019 11:24:29 +0000 > From: "Schmelter, Ralf" > To: HotSpot Open Source Developers > Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs > Message-ID: <960a11003daa403fbc8bb841206b8853 at sap.com> > Content-Type: text/plain; charset="us-ascii" > > Please review the following small patch. It increases the code_size2 constant > by 1000 bytes, since it was too small when doing a Windows slowdebug build > on my Skylake based system. > > I've increased code_isze2 in 500 bytes increments and 1000 additional bytes > was need to avoid the assertion indicating we are exceeding the reserved > code space. > > webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8219712 > > Best regards, > Ralf > From david.holmes at oracle.com Tue Feb 26 13:16:38 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Feb 2019 23:16:38 +1000 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs In-Reply-To: <960a11003daa403fbc8bb841206b8853@sap.com> References: <960a11003daa403fbc8bb841206b8853@sap.com> Message-ID: Hi Ralf, On 26/02/2019 9:24 pm, Schmelter, Ralf wrote: > Please review the following small patch. It increases the code_size2 constant by 1000 bytes, since it was too small when doing a Windows slowdebug build on my Skylake based system. > > I've increased code_isze2 in 500 bytes increments and 1000 additional bytes was need to avoid the assertion indicating we are exceeding the reserved code space. I agree with Matthias: can this be a DEBUG_ONLY change? Further is the problem with 32-bit and 64-bit or only 64-bit? Your change affects 32-bit. Finally what is the impact of changing this value? What exactly gets sized by this constant, and how might its increase affect other things? Thanks, David > webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.0/ > bug: https://bugs.openjdk.java.net/browse/JDK-8219712 > > Best regards, > Ralf > From christoph.langer at sap.com Tue Feb 26 13:52:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 26 Feb 2019 13:52:11 +0000 Subject: RFR [XS]: 8219630: cleanup hotspot ostream.cpp In-Reply-To: References: Message-ID: <6f7e7b71043d40afb0ee9b7e31669bb6@sap.com> +1 > -----Original Message----- > From: hotspot-dev On Behalf Of > Thomas St?fe > Sent: Dienstag, 26. Februar 2019 10:12 > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR [XS]: 8219630: cleanup hotspot ostream.cpp > > all good now :) > > On Tue, Feb 26, 2019 at 10:05 AM Baesken, Matthias > > wrote: > > > Hi Thomas, thanks for the review ! > > > > > > > > > > > > > >- you could remove the whole destructor, since it does nothing of value > > anymore. > > > > >- you could use initializer list instead in the ctor: > > > > > fdStream(int fd = -1) : _fd(fd) {} > > > > > > > > Sure, new webrev : > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.1/ > > > > > > > > > > > > Best regards, Matthias > > > > > > > > > > > > *From:* Thomas St?fe > > *Sent:* Dienstag, 26. Februar 2019 09:13 > > *To:* Baesken, Matthias > > *Cc:* hotspot-dev at openjdk.java.net > > *Subject:* Re: RFR [XS]: 8219630: cleanup hotspot ostream.cpp > > > > > > > > Looks good. > > > > > > > > Good as it is, but since you are touching the code: > > > > > > > > - you could use initializer list instead in the ctor: > > > > fdStream(int fd = -1) : _fd(fd) {} > > > > > > > > - you could remove the whole destructor, since it does nothing of value > > anymore. > > > > > > > > Cheers Thomas > > > > > > > > > > > > > > > > On Tue, Feb 26, 2019 at 9:02 AM Baesken, Matthias < > > matthias.baesken at sap.com> wrote: > > > > Hello, please review this small patch . > > > > In the review process of 8218811 it has been noticed that ostream.cpp > > can be cleaned up a bit ; I want to address the cleanups with this change > > . > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8219630 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.0/ > > > > > > Thanks, Matthias > > > > From ralf.schmelter at sap.com Tue Feb 26 15:50:31 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 26 Feb 2019 15:50:31 +0000 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs In-Reply-To: References: <960a11003daa403fbc8bb841206b8853@sap.com> Message-ID: <860c3fcdf7da4af58add6bf1af290ff4@sap.com> Hi David, > I agree with Matthias: can this be a DEBUG_ONLY change? code_size2 is the size of the BufferBlob which is allocated to contain the "stub routines 2" created by StubGenerator. And in the debug build we check via assertions, that we don't overwrite the buffer. In the optimized version, we would later just overwrite part of the stub routines. So making it DEBUG_ONLY defeats the purpose of the change. > Further is the problem with 32-bit and 64-bit or only 64-bit? Your change affects 32-bit. Since I only build the 64bit VM, I've changed the webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.1/ It should now only increase the 64 bit version. In the end, it would be nice if the initial BufferBlob size could be more generous and then later adjusted to the really needed space, since it is really not easy to get a tight upper bound reliably, with it being dependent on the OS, GC, CPU features and other flags. Best regards, Ralf From tobias.hartmann at oracle.com Tue Feb 26 16:39:26 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 26 Feb 2019 17:39:26 +0100 Subject: [13] RFR(M): 8163511: Allocation of compile task fails with assert: "Leaking compilation tasks?" Message-ID: Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8163511 http://cr.openjdk.java.net/~thartmann/8163511/webrev.00/ We hit an assert while trying to allocate a compile task because the compile queue already contains 10.000 tasks. The root cause is that the compiler threads are not able to keep up with the high number of compilation requests. The (internal) test that triggers this runs many different tests in the same VM by using different class loaders. Many of these tests use the same framework and therefore the same methods are enqueued for compilation again and again (up to 100x). The bug shows up more often when running with -XX:-TieredCompilation which is due to a lower number of compiler threads and a different threshold policy that does not remove stale (unused) methods from the compile queue. But the same problem can and does happen with TieredCompilation enabled (for example, we never remove "old" methods that were executed a lot, even if they are stale). After a test has been executed, the class loader becomes dead and therefore all test classes/methods should be unloaded. However, a compile task in the queue keeps the referenced method alive through a global handle (see CompileTask::initialize -> JNIHandles::make_global) until compilation finished or the task was removed from the queue for another reason. This causes compilation of thousands of dead methods. The regression test TestOverloadCompileQueues.java triggers this reliably for the C1 and C2 compile queues. The blue lines show the growth of the number of tasks in the queue until we hit the assert, the red lines show the growth with the fix: http://cr.openjdk.java.net/~thartmann/8163511/8163511_results.pdf The proposed fix uses weak handles for the compile tasks that don't prevent unloading but can be used to check if the referenced method is still alive (CompileTask::is_unloaded()). Unloaded tasks are aggressively removed with both threshold policies. If the method is still alive when the task is selected for compilation, the weak references are replaced by strong references (to avoid unloading during compilation which would crash the compiler). Of course, overloading the queue is still possible if classes are not unloaded fast enough or not at all (in the regression test, simply remove the System.gc() call). But I think this is very unlikely for real world applications and this assert does not affect product builds. The fix also changes the printing of compile tasks such that the time when they were enqueued and the time when compilation started is shown in the hs_err file: Threads with active compile tasks: C2 CompilerThread0 22446 18824 200 5372 4 java.lang.reflect.Method:: (68 bytes) C1 CompilerThread0 22446 21474 199 3377 2 jdk.internal.loader.URLClassPath$3::run (172 bytes) I'm currently running extended testing. Thanks, Tobias From vladimir.kozlov at oracle.com Tue Feb 26 17:13:54 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Feb 2019 09:13:54 -0800 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs In-Reply-To: <860c3fcdf7da4af58add6bf1af290ff4@sap.com> References: <960a11003daa403fbc8bb841206b8853@sap.com> <860c3fcdf7da4af58add6bf1af290ff4@sap.com> Message-ID: Looks good. David, this is usual way we handle buffer's size for stubs generation (usually for JIT intrinsics) when we add new code or previous code increased in size due to using new set of instructions. Ralf, there was discussion about automating calculation of these buffers sizes but we decided to not do that since we change it very rare. Thanks, Vladimir On 2/26/19 7:50 AM, Schmelter, Ralf wrote: > Hi David, > >> I agree with Matthias: can this be a DEBUG_ONLY change? > > code_size2 is the size of the BufferBlob which is allocated to contain the "stub routines 2" created by StubGenerator. And in the debug build we check via assertions, that we don't overwrite the buffer. In the optimized version, we would later just overwrite part of the stub routines. So making it DEBUG_ONLY defeats the purpose of the change. > >> Further is the problem with 32-bit and 64-bit or only 64-bit? Your > change affects 32-bit. > > Since I only build the 64bit VM, I've changed the webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.1/ > It should now only increase the 64 bit version. > > In the end, it would be nice if the initial BufferBlob size could be more generous and then later adjusted to the really needed space, since it is really not easy to get a tight upper bound reliably, with it being dependent on the OS, GC, CPU features and other flags. > > Best regards, > Ralf > From vladimir.kozlov at oracle.com Tue Feb 26 18:36:57 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 26 Feb 2019 10:36:57 -0800 Subject: [13] RFR(M): 8163511: Allocation of compile task fails with assert: "Leaking compilation tasks?" In-Reply-To: References: Message-ID: <8476ab17-665a-383a-8dc3-bf5fb69fc746@oracle.com> Very good. My only concern is CompileTask::select_for_compilation() where you may have small window between releasing weak reference and adding strong. Can we add strong reference fist before removing weak? With concurrent class unloading we may hit the assert in select_for_compilation() I think. May be make the method get task as argument and return NULL if is_unloaded() is true. What do you think? Do you kept output format for flag -XX:+PrintCompilation and changed only hs_err output? Or you changed both? Thanks, Vladimir On 2/26/19 8:39 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8163511 > http://cr.openjdk.java.net/~thartmann/8163511/webrev.00/ > > We hit an assert while trying to allocate a compile task because the compile queue already contains > 10.000 tasks. The root cause is that the compiler threads are not able to keep up with the high > number of compilation requests. The (internal) test that triggers this runs many different tests in > the same VM by using different class loaders. Many of these tests use the same framework and > therefore the same methods are enqueued for compilation again and again (up to 100x). > > The bug shows up more often when running with -XX:-TieredCompilation which is due to a lower number > of compiler threads and a different threshold policy that does not remove stale (unused) methods > from the compile queue. But the same problem can and does happen with TieredCompilation enabled (for > example, we never remove "old" methods that were executed a lot, even if they are stale). > > After a test has been executed, the class loader becomes dead and therefore all test classes/methods > should be unloaded. However, a compile task in the queue keeps the referenced method alive through a > global handle (see CompileTask::initialize -> JNIHandles::make_global) until compilation finished or > the task was removed from the queue for another reason. This causes compilation of thousands of dead > methods. > > The regression test TestOverloadCompileQueues.java triggers this reliably for the C1 and C2 compile > queues. The blue lines show the growth of the number of tasks in the queue until we hit the assert, > the red lines show the growth with the fix: > http://cr.openjdk.java.net/~thartmann/8163511/8163511_results.pdf > > The proposed fix uses weak handles for the compile tasks that don't prevent unloading but can be > used to check if the referenced method is still alive (CompileTask::is_unloaded()). Unloaded tasks > are aggressively removed with both threshold policies. If the method is still alive when the task is > selected for compilation, the weak references are replaced by strong references (to avoid unloading > during compilation which would crash the compiler). > > Of course, overloading the queue is still possible if classes are not unloaded fast enough or not at > all (in the regression test, simply remove the System.gc() call). But I think this is very unlikely > for real world applications and this assert does not affect product builds. > > The fix also changes the printing of compile tasks such that the time when they were enqueued and > the time when compilation started is shown in the hs_err file: > > Threads with active compile tasks: > C2 CompilerThread0 22446 18824 200 5372 4 java.lang.reflect.Method:: (68 bytes) > C1 CompilerThread0 22446 21474 199 3377 2 jdk.internal.loader.URLClassPath$3::run (172 bytes) > > I'm currently running extended testing. > > Thanks, > Tobias > From gerard.ziemski at oracle.com Tue Feb 26 18:39:58 2019 From: gerard.ziemski at oracle.com (gerard ziemski) Date: Tue, 26 Feb 2019 12:39:58 -0600 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs In-Reply-To: References: <960a11003daa403fbc8bb841206b8853@sap.com> <860c3fcdf7da4af58add6bf1af290ff4@sap.com> Message-ID: On 2/26/19 11:13 AM, Vladimir Kozlov wrote: > Ralf, there was discussion about automating calculation of these > buffers sizes but we decided to not do that since we change it very rare. One bug issue tracking this is https://bugs.openjdk.java.net/browse/JDK-8131167 From erik.osterlund at oracle.com Tue Feb 26 20:19:39 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 26 Feb 2019 21:19:39 +0100 Subject: RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean In-Reply-To: <65c8cd8f-7ac9-da33-9a84-254a0699fbb5@oracle.com> References: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> <65c8cd8f-7ac9-da33-9a84-254a0699fbb5@oracle.com> Message-ID: <6E9387A0-B1F9-4A12-877D-3435F5C90172@oracle.com> Hi Dean, > On 26 Feb 2019, at 08:29, dean.long at oracle.com wrote: > > Is there any need for is_safe_for_patching() anymore? Probably not! > entry_point == _call->get_resolve_call_stub(is_optimized() is used in several places. Can we refactor it into something like is_clean()? (I realize that name is taken.) Sure. > Undoing an ICStub (it appears this happens in ICStub::finalize) also sets both data and destination, so it needs to be done at a safepoint. Can we add an assert there to document that? I?m currently working on reclaiming these concurrently so I don?t think I would like to add that assert if that is okay. I really don?t like safepoints, what can I say... > Unrelated to your change, but the comment "called when a method is removed" for ICStub::finalize in icBuffer.hpp doesn't sound right to me. Yeah that comment is wrong. > Also, not part of your change, but in CompiledIC::internal_set_ic_destination(), don't we need a memory barrier between setting the entry point and setting the data? That is a long story. The short story is that all patching calls wrote() which performs mfence/isb/isync and invalidates instruction caches. There is another much much longer story, that I really have to refrain from telling yet. > In CompiledIC::set_to_monomorphic(), why is the following transition safe? I would think we need a transition stub here: > > 446 } else if (!is_in_transition_state() && get_data() == Universe::non_oop_word()) { > 447 set_ic_destination_and_value(info.entry(), info.cached_metadata()); The thought has been thst all interleavings have a happy ending. Any execution that sees the old value will miss in the unverified entry, regardless of destination. And whatever data was observed, executions with the old destination will call a resolution handler. Only executions observing the new data and new destination will get past the unverified entry. > I would feel better if there was a complete state diagram that captured all the important details. There is a small one in compiledIC.hpp but it doesn't capture everything, especially ICStub transitions and safepoints. Agreed. I will try to address this. I am out of office until tuesday next week though. But thank you for the review! Thanks, /Erik > dl > > >> On 2/18/19 4:01 AM, Erik ?sterlund wrote: >> Hi, >> >> When transitioning CompiledICs to clean, we sometimes need to use transitional states (using JIT-compiled ICStubs). >> The trick is that today when we clean ICs, we atomically and logically write NULL to the data section, and set the destination to some resolve stub. In reality, the NULL gets translated to Universe::non_oop_word. But the point is that in order to set both data and destination atomically, we use an ICStub. >> >> ...but we don't need to set them both. >> >> When the inline cache is cleaned, the data part is no longer relevant, and could really be set to any nonsense value, as long as subsequent transitions away from that cleaned inline cache (monomorphic/interpreted) uses a transitional state to do so. >> I suspect that at some point in time, when inline caches pointed at oops in perm gen or something, it was crucial that the data part of the inline cache made sense to the GC. This is not the case today, and we can just ignore the value pretending it doesn't exist instead. >> >> The benefit with deferring the use of transitional state to when someone performs a subsequent transition away from clean (set_to_monomorphic), is that all code paths where cleaning inline caches fail can be removed. This in particular simplifies the sweeper and ZGC nmethod unloading code, that needs to handle failures in inline cache cleaning due to running out of ICStubs forcing us to trigger safepoints to refill IC stubs. It should also reduce the overall number of safepoints due to running out of ICStubs. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8219101 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8219101/webrev.00/ >> >> Testing: mach5 hs-tier1-5. >> >> Thanks, >> /Erik > From david.holmes at oracle.com Tue Feb 26 21:32:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2019 07:32:40 +1000 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs In-Reply-To: <860c3fcdf7da4af58add6bf1af290ff4@sap.com> References: <960a11003daa403fbc8bb841206b8853@sap.com> <860c3fcdf7da4af58add6bf1af290ff4@sap.com> Message-ID: <6f1b7776-1f52-00a6-4d35-859bb90b907c@oracle.com> Hi Ralf, webrev.1 looks good. Thanks, David On 27/02/2019 1:50 am, Schmelter, Ralf wrote: > Hi David, > >> I agree with Matthias: can this be a DEBUG_ONLY change? > > code_size2 is the size of the BufferBlob which is allocated to contain the "stub routines 2" created by StubGenerator. And in the debug build we check via assertions, that we don't overwrite the buffer. In the optimized version, we would later just overwrite part of the stub routines. So making it DEBUG_ONLY defeats the purpose of the change. > >> Further is the problem with 32-bit and 64-bit or only 64-bit? Your > change affects 32-bit. > > Since I only build the 64bit VM, I've changed the webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.1/ > It should now only increase the 64 bit version. > > In the end, it would be nice if the initial BufferBlob size could be more generous and then later adjusted to the really needed space, since it is really not easy to get a tight upper bound reliably, with it being dependent on the OS, GC, CPU features and other flags. > > Best regards, > Ralf > From david.holmes at oracle.com Tue Feb 26 21:37:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2019 07:37:32 +1000 Subject: RFR [XS]: 8219630: cleanup hotspot ostream.cpp In-Reply-To: References: Message-ID: +1 (if you need it :) ) Thanks, David On 26/02/2019 7:12 pm, Thomas St?fe wrote: > all good now :) > > On Tue, Feb 26, 2019 at 10:05 AM Baesken, Matthias > wrote: > >> Hi Thomas, thanks for the review ! >> >> >> >>> >> >>> - you could remove the whole destructor, since it does nothing of value >> anymore. >> >>> - you could use initializer list instead in the ctor: >> >>> fdStream(int fd = -1) : _fd(fd) {} >> >> >> >> Sure, new webrev : >> >> >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.1/ >> >> >> >> >> >> Best regards, Matthias >> >> >> >> >> >> *From:* Thomas St?fe >> *Sent:* Dienstag, 26. Februar 2019 09:13 >> *To:* Baesken, Matthias >> *Cc:* hotspot-dev at openjdk.java.net >> *Subject:* Re: RFR [XS]: 8219630: cleanup hotspot ostream.cpp >> >> >> >> Looks good. >> >> >> >> Good as it is, but since you are touching the code: >> >> >> >> - you could use initializer list instead in the ctor: >> >> fdStream(int fd = -1) : _fd(fd) {} >> >> >> >> - you could remove the whole destructor, since it does nothing of value >> anymore. >> >> >> >> Cheers Thomas >> >> >> >> >> >> >> >> On Tue, Feb 26, 2019 at 9:02 AM Baesken, Matthias < >> matthias.baesken at sap.com> wrote: >> >> Hello, please review this small patch . >> >> In the review process of 8218811 it has been noticed that ostream.cpp >> can be cleaned up a bit ; I want to address the cleanups with this change >> . >> >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8219630 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8219630.0/ >> >> >> Thanks, Matthias >> >> From david.holmes at oracle.com Wed Feb 27 04:17:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2019 14:17:19 +1000 Subject: RFR: 8219233: 3x performance drop for some Clojure applications Message-ID: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ bug: https://bugs.openjdk.java.net/browse/JDK-8219233 We had a bug whereby the callsite to a static method was resolved as soon as it was executed, allowing other threads to execute the same code and skip the class initialization check. The fix to that was to not do the resolution if the target class was not fully initialized. This has a consequence that calls to static methods of the current class from the (including transitively) can't be resolved and effectively compiled and so we can take a huge performance hit for those cases (which is a rare case and regular benchmarking showed no issue). Clojure unfortunately uses a style of coding that is significantly impacted by this. There is a simple fix for the direct case of calling a static method from : when we are dealing with the same class then it's okay to do the resolution as the current thread must have on its callstack. No other thread can execute the code being resolved until the initial thread completes the static initialization. Unfortunately that doesn't address the main pattern used by Clojure, but we have a subtask open where Vladimir Ivanov continues to look into that case. And Claes Redestad has also given coding advice on how to avoid the problem in the first place. Testing: tier 1-3 Microbenchmarking - see bug report. Thanks, David ----- From claes.redestad at oracle.com Wed Feb 27 07:56:36 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 Feb 2019 08:56:36 +0100 Subject: RFR: 8219233: 3x performance drop for some Clojure applications In-Reply-To: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> Message-ID: <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> Hi David, On 2019-02-27 05:17, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ patch looks good to me. > bug: https://bugs.openjdk.java.net/browse/JDK-8219233 As this is only a partial fix (about a 10% improvement in the clojure startup repro), I'd suggest moving it to a subtask and leaving JDK-8219233 open for the time being - if only to not give the false impression the issue is resolved in its entirety. I've verified this recuperates performance completely in cases where we're calling into static methods from the class itself, e.g., "Bad"[1], and also that it doesn't help in cases where call are routed back via another class, e.g., "AlsoBad". Thanks! /Claes [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html > > We had a bug whereby the callsite to a static method was resolved as > soon as it was executed, allowing other threads to execute the same code > and skip the class initialization check. The fix to that was to not do > the resolution if the target class was not fully initialized. This has a > consequence that calls to static methods of the current class from the > (including transitively) can't be resolved and effectively > compiled and so we can take a huge performance hit for those cases > (which is a rare case and regular benchmarking showed no issue). Clojure > unfortunately uses a style of coding that is significantly impacted by > this. > > There is a simple fix for the direct case of calling a static method > from : when we are dealing with the same class then it's okay to > do the resolution as the current thread must have on its > callstack. No other thread can execute the code being resolved until the > initial thread completes the static initialization. > > Unfortunately that doesn't address the main pattern used by Clojure, but > we have a subtask open where Vladimir Ivanov continues to look into that > case. And Claes Redestad has also given coding advice on how to avoid > the problem in the first place. > > Testing: tier 1-3 > Microbenchmarking - see bug report. > > Thanks, > David > ----- From fujie at loongson.cn Wed Feb 27 08:23:15 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 27 Feb 2019 16:23:15 +0800 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost Message-ID: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> Hi all, Bug:??? https://bugs.openjdk.java.net/browse/JDK-8219814 Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ When debug the VM in gdb and perform "call help()", the help-info for pns(...) on Linux/mips is lost. However, it exists in jdk8. To support debugging on as many platforms as possible, it would be better to keep it. The patch has been tested on Linux/x86-64 and Loongson's Linux/mips64-port. Could you please review it? Thanks a lot. Best regards, Jie From aoqi at loongson.cn Wed Feb 27 08:40:47 2019 From: aoqi at loongson.cn (Ao Qi) Date: Wed, 27 Feb 2019 16:40:47 +0800 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> Message-ID: Hi, Looks good to me, but I am not a reviewer. This patch is used in the Loongson's jdk8u mips port for more than one year [1], and it seem it works. Cheers, Ao Qi [1] http://hg.loongnix.org/jdk8-mips64-public/hotspot/rev/4eda64738f6a On Wed, Feb 27, 2019 at 4:23 PM Jie Fu wrote: > > Hi all, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219814 > Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ > > When debug the VM in gdb and perform "call help()", the help-info for > pns(...) on Linux/mips is lost. > However, it exists in jdk8. > > To support debugging on as many platforms as possible, it would be > better to keep it. > > The patch has been tested on Linux/x86-64 and Loongson's Linux/mips64-port. > Could you please review it? > Thanks a lot. > > Best regards, > Jie > > From shade at redhat.com Wed Feb 27 08:47:05 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Feb 2019 09:47:05 +0100 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> Message-ID: On 2/27/19 9:23 AM, Jie Fu wrote: > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8219814 > Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ Looks good and trivial. Do you need a sponsor for this? -Aleksey From per.liden at oracle.com Wed Feb 27 08:53:16 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 27 Feb 2019 09:53:16 +0100 Subject: RFR: 8219816: Add IsArray/RemoveArray type traits utilities Message-ID: Add IsArray/RemoveArray to our collection of type traits metaprogramming utilities. This patch only adds the IsArray/RemoveArray utilities and their respective tests. A later patch I have in my queue that will actually make use of these. Bug: https://bugs.openjdk.java.net/browse/JDK-8219816 Webrev: http://cr.openjdk.java.net/~pliden/8219816/webrev.0 /Per From fujie at loongson.cn Wed Feb 27 09:01:24 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 27 Feb 2019 17:01:24 +0800 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> Message-ID: Yes, I need. Thank you so much Aleksey. On 2019/2/27 ??4:47, Aleksey Shipilev wrote: > On 2/27/19 9:23 AM, Jie Fu wrote: >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8219814 >> Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ > Looks good and trivial. Do you need a sponsor for this? > > -Aleksey > From shade at redhat.com Wed Feb 27 09:16:05 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Feb 2019 10:16:05 +0100 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> Message-ID: <2678ef30-9ece-8874-6e9d-87dda5a63e77@redhat.com> No problem: http://hg.openjdk.java.net/jdk/jdk/rev/33839b74e47c -Aleksey On 2/27/19 10:01 AM, Jie Fu wrote: > Yes, I need. > > Thank you so much Aleksey. > > On 2019/2/27 ??4:47, Aleksey Shipilev wrote: >> On 2/27/19 9:23 AM, Jie Fu wrote: >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8219814 >>> Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ >> Looks good and trivial. Do you need a sponsor for this? >> >> -Aleksey >> > From fujie at loongson.cn Wed Feb 27 09:24:11 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 27 Feb 2019 17:24:11 +0800 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: <2678ef30-9ece-8874-6e9d-87dda5a63e77@redhat.com> References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> <2678ef30-9ece-8874-6e9d-87dda5a63e77@redhat.com> Message-ID: <0fb134b6-d78c-1047-eb36-b4b4778c77c7@loongson.cn> Thanks a lot. On 2019/2/27 ??5:16, Aleksey Shipilev wrote: > No problem: > http://hg.openjdk.java.net/jdk/jdk/rev/33839b74e47c > > -Aleksey > > On 2/27/19 10:01 AM, Jie Fu wrote: >> Yes, I need. >> >> Thank you so much Aleksey. >> >> On 2019/2/27 ??4:47, Aleksey Shipilev wrote: >>> On 2/27/19 9:23 AM, Jie Fu wrote: >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8219814 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ >>> Looks good and trivial. Do you need a sponsor for this? >>> >>> -Aleksey >>> > From david.holmes at oracle.com Wed Feb 27 11:37:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2019 21:37:34 +1000 Subject: RFR: 8219233: 3x performance drop for some Clojure applications In-Reply-To: <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> Message-ID: Hi Claes, On 27/02/2019 5:56 pm, Claes Redestad wrote: > Hi David, > > On 2019-02-27 05:17, David Holmes wrote: >> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ > > patch looks good to me. Thanks for looking at this. >> bug: https://bugs.openjdk.java.net/browse/JDK-8219233 > > As this is only a partial fix (about a 10% improvement in the clojure > startup repro), I'd suggest moving it to a subtask and leaving > JDK-8219233 open for the time being - if only to not give the false > impression the issue is resolved in its entirety. Yes I can do that. Though I may use the existing sub-task for this part and let the main bug become the C1/C2 issue that Vladimir is working on - the discussion is all in the comments of the main bug anyway. Thanks, David > I've verified this recuperates performance completely in cases where > we're calling into static methods from the class itself, e.g., "Bad"[1], > and also that it doesn't help in cases where call are routed back via > another class, e.g., "AlsoBad". > > Thanks! > > /Claes > > [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html > >> >> We had a bug whereby the callsite to a static method was resolved as >> soon as it was executed, allowing other threads to execute the same >> code and skip the class initialization check. The fix to that was to >> not do the resolution if the target class was not fully initialized. >> This has a consequence that calls to static methods of the current >> class from the (including transitively) can't be resolved and >> effectively compiled and so we can take a huge performance hit for >> those cases (which is a rare case and regular benchmarking showed no >> issue). Clojure unfortunately uses a style of coding that is >> significantly impacted by this. >> >> There is a simple fix for the direct case of calling a static method >> from : when we are dealing with the same class then it's okay >> to do the resolution as the current thread must have on its >> callstack. No other thread can execute the code being resolved until >> the initial thread completes the static initialization. >> >> Unfortunately that doesn't address the main pattern used by Clojure, >> but we have a subtask open where Vladimir Ivanov continues to look >> into that case. And Claes Redestad has also given coding advice on how >> to avoid the problem in the first place. >> >> Testing: tier 1-3 >> Microbenchmarking - see bug report. >> >> Thanks, >> David >> ----- From david.holmes at oracle.com Wed Feb 27 11:47:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Feb 2019 21:47:04 +1000 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> Message-ID: On 27/02/2019 6:23 pm, Jie Fu wrote: > Hi all, > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8219814 > Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ > > When debug the VM in gdb and perform "call help()", the help-info for > pns(...) on Linux/mips is lost. > However, it exists in jdk8. That's because there was some support for an active MIPS port in JDK 8 but that no longer exists. This change may be trivial but it belongs in a project providing a MIPS port until such time as a MIPS port becomes mainline. David ----- > To support debugging on as many platforms as possible, it would be > better to keep it. > > The patch has been tested on Linux/x86-64 and Loongson's Linux/mips64-port. > Could you please review it? > Thanks a lot. > > Best regards, > Jie > > From tobias.hartmann at oracle.com Wed Feb 27 12:13:50 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 27 Feb 2019 13:13:50 +0100 Subject: [13] RFR(M): 8163511: Allocation of compile task fails with assert: "Leaking compilation tasks?" In-Reply-To: <8476ab17-665a-383a-8dc3-bf5fb69fc746@oracle.com> References: <8476ab17-665a-383a-8dc3-bf5fb69fc746@oracle.com> Message-ID: <9159da86-8330-24b6-b783-6dbfdad2fe87@oracle.com> Hi Vladimir, thanks for the review! On 26.02.19 19:36, Vladimir Kozlov wrote: > My only concern is CompileTask::select_for_compilation() where you may have small window between > releasing weak reference and adding strong. Can we add strong reference fist before removing weak? > > With concurrent class unloading we may hit the assert in select_for_compilation() I think. May be > make the method get task as argument and return NULL if is_unloaded() is true. What do you think? I thought we should be safe because we can't have a safepoint after the is_unloaded() check in CompilationPolicy::policy()->select_task() and this assert (there is a NoSafepointVerifier in the caller). But I'm not sure what the guarantees are with concurrent class unloading. I've changed the code to create the (local) handle before removing the weak handles: http://cr.openjdk.java.net/~thartmann/8163511/webrev.01/ Now I'm wondering what will happen if concurrent class unloading kicks in right after the is_unloaded() check and before we create the method_holder handle. I think someone from GC/runtime (Erik ?sterlund?) should have a look at this. > Do you kept output format for flag -XX:+PrintCompilation and changed only hs_err output? Or you > changed both? I've changed both because both are using CompileTask::print -> CompileTask::print_impl. What about guarding the additional output by -XX:+Verbose (see new webrev)? Best regards, Tobias P.S. I'll be out until Wednesday next week. > On 2/26/19 8:39 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8163511 >> http://cr.openjdk.java.net/~thartmann/8163511/webrev.00/ >> >> We hit an assert while trying to allocate a compile task because the compile queue already contains >> 10.000 tasks. The root cause is that the compiler threads are not able to keep up with the high >> number of compilation requests. The (internal) test that triggers this runs many different tests in >> the same VM by using different class loaders. Many of these tests use the same framework and >> therefore the same methods are enqueued for compilation again and again (up to 100x). >> >> The bug shows up more often when running with -XX:-TieredCompilation which is due to a lower number >> of compiler threads and a different threshold policy that does not remove stale (unused) methods >> from the compile queue. But the same problem can and does happen with TieredCompilation enabled (for >> example, we never remove "old" methods that were executed a lot, even if they are stale). >> >> After a test has been executed, the class loader becomes dead and therefore all test classes/methods >> should be unloaded. However, a compile task in the queue keeps the referenced method alive through a >> global handle (see CompileTask::initialize -> JNIHandles::make_global) until compilation finished or >> the task was removed from the queue for another reason. This causes compilation of thousands of dead >> methods. >> >> The regression test TestOverloadCompileQueues.java triggers this reliably for the C1 and C2 compile >> queues. The blue lines show the growth of the number of tasks in the queue until we hit the assert, >> the red lines show the growth with the fix: >> http://cr.openjdk.java.net/~thartmann/8163511/8163511_results.pdf >> >> The proposed fix uses weak handles for the compile tasks that don't prevent unloading but can be >> used to check if the referenced method is still alive (CompileTask::is_unloaded()). Unloaded tasks >> are aggressively removed with both threshold policies. If the method is still alive when the task is >> selected for compilation, the weak references are replaced by strong references (to avoid unloading >> during compilation which would crash the compiler). >> >> Of course, overloading the queue is still possible if classes are not unloaded fast enough or not at >> all (in the regression test, simply remove the System.gc() call). But I think this is very unlikely >> for real world applications and this assert does not affect product builds. >> >> The fix also changes the printing of compile tasks such that the time when they were enqueued and >> the time when compilation started is shown in the hs_err file: >> >> Threads with active compile tasks: >> C2 CompilerThread0??? 22446 18824 200 5372?? 4?? java.lang.reflect.Method:: (68 bytes) >> C1 CompilerThread0??? 22446 21474 199 3377?? 2?? jdk.internal.loader.URLClassPath$3::run (172 bytes) >> >> I'm currently running extended testing. >> >> Thanks, >> Tobias >> From fujie at loongson.cn Wed Feb 27 14:06:37 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 27 Feb 2019 22:06:37 +0800 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> Message-ID: Hi David, Thanks for your attention to MIPS-port of OpenJDK. As a matter of fact, we have maintained the MIPS-port of jdk8 for over 6 years for Loongson CPU which is MIPS-compatible. And now we are porting the latest OpenJDK to MIPS as well with the increasing demand of Loongson processors. We sincerely hope that the MIPS-port can be merged into the mainline. Is there anything we can do to make it as soon as possible? Thank you very much. Best regards, Jie On 2019?02?27? 19:47, David Holmes wrote: > On 27/02/2019 6:23 pm, Jie Fu wrote: >> Hi all, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219814 >> Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ >> >> When debug the VM in gdb and perform "call help()", the help-info for >> pns(...) on Linux/mips is lost. >> However, it exists in jdk8. > > That's because there was some support for an active MIPS port in JDK 8 > but that no longer exists. This change may be trivial but it belongs > in a project providing a MIPS port until such time as a MIPS port > becomes mainline. > > David > ----- > >> To support debugging on as many platforms as possible, it would be >> better to keep it. >> >> The patch has been tested on Linux/x86-64 and Loongson's >> Linux/mips64-port. >> Could you please review it? >> Thanks a lot. >> >> Best regards, >> Jie >> >> From kim.barrett at oracle.com Wed Feb 27 15:08:02 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 27 Feb 2019 10:08:02 -0500 Subject: RFR: 8219816: Add IsArray/RemoveArray type traits utilities In-Reply-To: References: Message-ID: <8FDD08D8-6187-41DB-8773-8921A9DFF0E5@oracle.com> > On Feb 27, 2019, at 3:53 AM, Per Liden wrote: > > Add IsArray/RemoveArray to our collection of type traits metaprogramming utilities. > > This patch only adds the IsArray/RemoveArray utilities and their respective tests. A later patch I have in my queue that will actually make use of these. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219816 > Webrev: http://cr.openjdk.java.net/~pliden/8219816/webrev.0 > > /Per For completeness, there should probably be IsArray test cases for const/volatile with size. Otherwise, looks good. I don't need another webrev for those additional test cases. From coleen.phillimore at oracle.com Wed Feb 27 16:25:02 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 27 Feb 2019 11:25:02 -0500 Subject: [13] RFR(M): 8163511: Allocation of compile task fails with assert: "Leaking compilation tasks?" In-Reply-To: <9159da86-8330-24b6-b783-6dbfdad2fe87@oracle.com> References: <8476ab17-665a-383a-8dc3-bf5fb69fc746@oracle.com> <9159da86-8330-24b6-b783-6dbfdad2fe87@oracle.com> Message-ID: <7f975ada-a265-533e-e9a9-e90b2e2121a4@oracle.com> On 2/27/19 7:13 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 26.02.19 19:36, Vladimir Kozlov wrote: >> My only concern is CompileTask::select_for_compilation() where you may have small window between >> releasing weak reference and adding strong. Can we add strong reference fist before removing weak? >> >> With concurrent class unloading we may hit the assert in select_for_compilation() I think. May be >> make the method get task as argument and return NULL if is_unloaded() is true. What do you think? > I thought we should be safe because we can't have a safepoint after the is_unloaded() check in > CompilationPolicy::policy()->select_task() and this assert (there is a NoSafepointVerifier in the > caller). But I'm not sure what the guarantees are with concurrent class unloading. > > I've changed the code to create the (local) handle before removing the weak handles: > http://cr.openjdk.java.net/~thartmann/8163511/webrev.01/ > > Now I'm wondering what will happen if concurrent class unloading kicks in right after the > is_unloaded() check and before we create the method_holder handle. > > I think someone from GC/runtime (Erik ?sterlund?) should have a look at this. I don't know for sure (wait for Erik!) but it should be ok because we have other places where we make objects alive with a Handle to klass_holder(). http://cr.openjdk.java.net/~thartmann/8163511/webrev.01/src/hotspot/share/compiler/compileTask.cpp.udiff.html Nit, can you use // comments. Also, there should be a HandleMark here. I think this method also needs to check for is_unloading() before touching method(). // RedefineClasses support void CompileTask::metadata_do(void f(Metadata*)) { ? f(method()); ? if (hot_method() != NULL && hot_method() != method()) { ??? f(hot_method()); ? } } This change makes sense to me.? It would be nice if these were in VM mode, if you could use WeakHandles instead of JNI, but you would need your own weak handle area.? For future consideration, anyway. Thanks, Coleen > >> Do you kept output format for flag -XX:+PrintCompilation and changed only hs_err output? Or you >> changed both? > I've changed both because both are using CompileTask::print -> CompileTask::print_impl. What about > guarding the additional output by -XX:+Verbose (see new webrev)? > > Best regards, > Tobias > > P.S. I'll be out until Wednesday next week. > > >> On 2/26/19 8:39 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8163511 >>> http://cr.openjdk.java.net/~thartmann/8163511/webrev.00/ >>> >>> We hit an assert while trying to allocate a compile task because the compile queue already contains >>> 10.000 tasks. The root cause is that the compiler threads are not able to keep up with the high >>> number of compilation requests. The (internal) test that triggers this runs many different tests in >>> the same VM by using different class loaders. Many of these tests use the same framework and >>> therefore the same methods are enqueued for compilation again and again (up to 100x). >>> >>> The bug shows up more often when running with -XX:-TieredCompilation which is due to a lower number >>> of compiler threads and a different threshold policy that does not remove stale (unused) methods >>> from the compile queue. But the same problem can and does happen with TieredCompilation enabled (for >>> example, we never remove "old" methods that were executed a lot, even if they are stale). >>> >>> After a test has been executed, the class loader becomes dead and therefore all test classes/methods >>> should be unloaded. However, a compile task in the queue keeps the referenced method alive through a >>> global handle (see CompileTask::initialize -> JNIHandles::make_global) until compilation finished or >>> the task was removed from the queue for another reason. This causes compilation of thousands of dead >>> methods. >>> >>> The regression test TestOverloadCompileQueues.java triggers this reliably for the C1 and C2 compile >>> queues. The blue lines show the growth of the number of tasks in the queue until we hit the assert, >>> the red lines show the growth with the fix: >>> http://cr.openjdk.java.net/~thartmann/8163511/8163511_results.pdf >>> >>> The proposed fix uses weak handles for the compile tasks that don't prevent unloading but can be >>> used to check if the referenced method is still alive (CompileTask::is_unloaded()). Unloaded tasks >>> are aggressively removed with both threshold policies. If the method is still alive when the task is >>> selected for compilation, the weak references are replaced by strong references (to avoid unloading >>> during compilation which would crash the compiler). >>> >>> Of course, overloading the queue is still possible if classes are not unloaded fast enough or not at >>> all (in the regression test, simply remove the System.gc() call). But I think this is very unlikely >>> for real world applications and this assert does not affect product builds. >>> >>> The fix also changes the printing of compile tasks such that the time when they were enqueued and >>> the time when compilation started is shown in the hs_err file: >>> >>> Threads with active compile tasks: >>> C2 CompilerThread0??? 22446 18824 200 5372?? 4?? java.lang.reflect.Method:: (68 bytes) >>> C1 CompilerThread0??? 22446 21474 199 3377?? 2?? jdk.internal.loader.URLClassPath$3::run (172 bytes) >>> >>> I'm currently running extended testing. >>> >>> Thanks, >>> Tobias >>> From matthias.baesken at sap.com Wed Feb 27 16:59:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 27 Feb 2019 16:59:08 +0000 Subject: RFR : 8219746: Provide virtualization related info in the hs_error file on linux ppc64 / ppc64le Message-ID: Hello, please review the following change ; it adds virtualization related info in the hs_error file on linux ppc64 / ppc64le . On linux ppc64 / ppc64le , we often run in virtualized environments (Power KVM / Power VM ... ). It is helpful for instance in support cases to get some information about the virtualized environment in the hs_error file . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219746 http://cr.openjdk.java.net/~mbaesken/webrevs/8219746.0/ Thanks , Matthias From vladimir.kozlov at oracle.com Wed Feb 27 17:21:46 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 27 Feb 2019 09:21:46 -0800 Subject: [13] RFR(M): 8163511: Allocation of compile task fails with assert: "Leaking compilation tasks?" In-Reply-To: <9159da86-8330-24b6-b783-6dbfdad2fe87@oracle.com> References: <8476ab17-665a-383a-8dc3-bf5fb69fc746@oracle.com> <9159da86-8330-24b6-b783-6dbfdad2fe87@oracle.com> Message-ID: <784b2fc7-6038-53d3-9bab-09482b0a887c@oracle.com> On 2/27/19 4:13 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 26.02.19 19:36, Vladimir Kozlov wrote: >> My only concern is CompileTask::select_for_compilation() where you may have small window between >> releasing weak reference and adding strong. Can we add strong reference fist before removing weak? >> >> With concurrent class unloading we may hit the assert in select_for_compilation() I think. May be >> make the method get task as argument and return NULL if is_unloaded() is true. What do you think? > > I thought we should be safe because we can't have a safepoint after the is_unloaded() check in > CompilationPolicy::policy()->select_task() and this assert (there is a NoSafepointVerifier in the > caller). But I'm not sure what the guarantees are with concurrent class unloading. > > I've changed the code to create the (local) handle before removing the weak handles: > http://cr.openjdk.java.net/~thartmann/8163511/webrev.01/ > > Now I'm wondering what will happen if concurrent class unloading kicks in right after the > is_unloaded() check and before we create the method_holder handle. > > I think someone from GC/runtime (Erik ?sterlund?) should have a look at this. Yes, this is better. Lets see what Erik will say. > >> Do you kept output format for flag -XX:+PrintCompilation and changed only hs_err output? Or you >> changed both? > > I've changed both because both are using CompileTask::print -> CompileTask::print_impl. What about > guarding the additional output by -XX:+Verbose (see new webrev)? I am fine with Verbose flag if you are also fine that it is debug flag - you will get this output only with debug VM. Thanks, Vladimir > > Best regards, > Tobias > > P.S. I'll be out until Wednesday next week. > > >> On 2/26/19 8:39 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8163511 >>> http://cr.openjdk.java.net/~thartmann/8163511/webrev.00/ >>> >>> We hit an assert while trying to allocate a compile task because the compile queue already contains >>> 10.000 tasks. The root cause is that the compiler threads are not able to keep up with the high >>> number of compilation requests. The (internal) test that triggers this runs many different tests in >>> the same VM by using different class loaders. Many of these tests use the same framework and >>> therefore the same methods are enqueued for compilation again and again (up to 100x). >>> >>> The bug shows up more often when running with -XX:-TieredCompilation which is due to a lower number >>> of compiler threads and a different threshold policy that does not remove stale (unused) methods >>> from the compile queue. But the same problem can and does happen with TieredCompilation enabled (for >>> example, we never remove "old" methods that were executed a lot, even if they are stale). >>> >>> After a test has been executed, the class loader becomes dead and therefore all test classes/methods >>> should be unloaded. However, a compile task in the queue keeps the referenced method alive through a >>> global handle (see CompileTask::initialize -> JNIHandles::make_global) until compilation finished or >>> the task was removed from the queue for another reason. This causes compilation of thousands of dead >>> methods. >>> >>> The regression test TestOverloadCompileQueues.java triggers this reliably for the C1 and C2 compile >>> queues. The blue lines show the growth of the number of tasks in the queue until we hit the assert, >>> the red lines show the growth with the fix: >>> http://cr.openjdk.java.net/~thartmann/8163511/8163511_results.pdf >>> >>> The proposed fix uses weak handles for the compile tasks that don't prevent unloading but can be >>> used to check if the referenced method is still alive (CompileTask::is_unloaded()). Unloaded tasks >>> are aggressively removed with both threshold policies. If the method is still alive when the task is >>> selected for compilation, the weak references are replaced by strong references (to avoid unloading >>> during compilation which would crash the compiler). >>> >>> Of course, overloading the queue is still possible if classes are not unloaded fast enough or not at >>> all (in the regression test, simply remove the System.gc() call). But I think this is very unlikely >>> for real world applications and this assert does not affect product builds. >>> >>> The fix also changes the printing of compile tasks such that the time when they were enqueued and >>> the time when compilation started is shown in the hs_err file: >>> >>> Threads with active compile tasks: >>> C2 CompilerThread0??? 22446 18824 200 5372?? 4?? java.lang.reflect.Method:: (68 bytes) >>> C1 CompilerThread0??? 22446 21474 199 3377?? 2?? jdk.internal.loader.URLClassPath$3::run (172 bytes) >>> >>> I'm currently running extended testing. >>> >>> Thanks, >>> Tobias >>> From per.liden at oracle.com Wed Feb 27 19:24:20 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 27 Feb 2019 20:24:20 +0100 Subject: RFR: 8219816: Add IsArray/RemoveArray type traits utilities In-Reply-To: <8FDD08D8-6187-41DB-8773-8921A9DFF0E5@oracle.com> References: <8FDD08D8-6187-41DB-8773-8921A9DFF0E5@oracle.com> Message-ID: On 2019-02-27 16:08, Kim Barrett wrote: >> On Feb 27, 2019, at 3:53 AM, Per Liden wrote: >> >> Add IsArray/RemoveArray to our collection of type traits metaprogramming utilities. >> >> This patch only adds the IsArray/RemoveArray utilities and their respective tests. A later patch I have in my queue that will actually make use of these. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219816 >> Webrev: http://cr.openjdk.java.net/~pliden/8219816/webrev.0 >> >> /Per > > For completeness, there should probably be IsArray test cases for > const/volatile with size. > > Otherwise, looks good. I don't need another webrev for those > additional test cases. Thanks for reviewing, Kim. I'll add the additional tests before pushing. /Per From kim.barrett at oracle.com Wed Feb 27 20:21:22 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 27 Feb 2019 15:21:22 -0500 Subject: RFR: 8219816: Add IsArray/RemoveArray type traits utilities In-Reply-To: <8FDD08D8-6187-41DB-8773-8921A9DFF0E5@oracle.com> References: <8FDD08D8-6187-41DB-8773-8921A9DFF0E5@oracle.com> Message-ID: <387BFF37-0572-4341-BA12-BC0857D55ABA@oracle.com> > On Feb 27, 2019, at 10:08 AM, Kim Barrett wrote: > >> On Feb 27, 2019, at 3:53 AM, Per Liden wrote: >> >> Add IsArray/RemoveArray to our collection of type traits metaprogramming utilities. >> >> This patch only adds the IsArray/RemoveArray utilities and their respective tests. A later patch I have in my queue that will actually make use of these. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8219816 >> Webrev: http://cr.openjdk.java.net/~pliden/8219816/webrev.0 >> >> /Per > > For completeness, there should probably be IsArray test cases for > const/volatile with size. > > Otherwise, looks good. I don't need another webrev for those > additional test cases. HotSpot's metaprogramming utilities have been intentionally modelled on those from , both in naming and (with some limitations in a few cases) behavior. The C++11 type trait for removing array dimensions from an array type is "remove_extent" (and "remove_all_extents" to remove all of them from a multi-dimensional array type). So what this change calls RemoveArray ought to be called RemoveExtent. Sorry that I forgot to check on this earlier. From dean.long at oracle.com Wed Feb 27 22:21:35 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 27 Feb 2019 14:21:35 -0800 Subject: RFR: 8219101: Stop using ICStubs for CompiledIC transitions to clean In-Reply-To: <6E9387A0-B1F9-4A12-877D-3435F5C90172@oracle.com> References: <7ffd39b7-e78f-a23a-f11f-b71f8101728f@oracle.com> <65c8cd8f-7ac9-da33-9a84-254a0699fbb5@oracle.com> <6E9387A0-B1F9-4A12-877D-3435F5C90172@oracle.com> Message-ID: On 2/26/19 12:19 PM, Erik Osterlund wrote: >> In CompiledIC::set_to_monomorphic(), why is the following transition safe? I would think we need a transition stub here: >> >> 446 } else if (!is_in_transition_state() && get_data() == Universe::non_oop_word()) { >> 447 set_ic_destination_and_value(info.entry(), info.cached_metadata()); > The thought has been thst all interleavings have a happy ending. Any execution that sees the old value will miss in the unverified entry, regardless of destination. And whatever data was observed, executions with the old destination will call a resolution handler. Only executions observing the new data and new destination will get past the unverified entry. > I'm almost convinced, but if seeing the old value is OK, then why check for non_oop_word()? dl From david.holmes at oracle.com Wed Feb 27 22:31:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Feb 2019 08:31:15 +1000 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> Message-ID: <9ba866f6-9ad1-7fd1-238c-a1275bcc7b85@oracle.com> Hi Jie, On 28/02/2019 12:06 am, Jie Fu wrote: > Hi David, > > Thanks for your attention to MIPS-port of OpenJDK. > > As a matter of fact, we have maintained the MIPS-port of jdk8 for over 6 > years for Loongson CPU which is MIPS-compatible. > And now we are porting the latest OpenJDK to MIPS as well with the > increasing demand of Loongson processors. > We sincerely hope that the MIPS-port can be merged into the mainline. > > Is there anything we can do to make it as soon as possible? If a MIPS port is to be brought into mainline it will need a JEP so that its inclusion, and ongoing support, can be properly evaluated. Please see the s390 JEP for reference: https://bugs.openjdk.java.net/browse/JDK-8166730 The JEP process is described from: http://openjdk.java.net/jeps/0 David ----- > Thank you very much. > > Best regards, > Jie > > > On 2019?02?27? 19:47, David Holmes wrote: >> On 27/02/2019 6:23 pm, Jie Fu wrote: >>> Hi all, >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8219814 >>> Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ >>> >>> When debug the VM in gdb and perform "call help()", the help-info for >>> pns(...) on Linux/mips is lost. >>> However, it exists in jdk8. >> >> That's because there was some support for an active MIPS port in JDK 8 >> but that no longer exists. This change may be trivial but it belongs >> in a project providing a MIPS port until such time as a MIPS port >> becomes mainline. >> >> David >> ----- >> >>> To support debugging on as many platforms as possible, it would be >>> better to keep it. >>> >>> The patch has been tested on Linux/x86-64 and Loongson's >>> Linux/mips64-port. >>> Could you please review it? >>> Thanks a lot. >>> >>> Best regards, >>> Jie >>> >>> > > From fujie at loongson.cn Thu Feb 28 01:01:40 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 28 Feb 2019 09:01:40 +0800 Subject: RFR (trivial): 8219814: Help-info for pns(...) on Linux/mips lost In-Reply-To: <9ba866f6-9ad1-7fd1-238c-a1275bcc7b85@oracle.com> References: <178df74e-57f6-9436-f99d-229fb1bddf19@loongson.cn> <9ba866f6-9ad1-7fd1-238c-a1275bcc7b85@oracle.com> Message-ID: Great! We will propose a JEP as soon as possible. Thanks David. On 2019/2/28 ??6:31, David Holmes wrote: > Hi Jie, > > On 28/02/2019 12:06 am, Jie Fu wrote: >> Hi David, >> >> Thanks for your attention to MIPS-port of OpenJDK. >> >> As a matter of fact, we have maintained the MIPS-port of jdk8 for >> over 6 years for Loongson CPU which is MIPS-compatible. >> And now we are porting the latest OpenJDK to MIPS as well with the >> increasing demand of Loongson processors. >> We sincerely hope that the MIPS-port can be merged into the mainline. >> >> Is there anything we can do to make it as soon as possible? > > If a MIPS port is to be brought into mainline it will need a JEP so > that its inclusion, and ongoing support, can be properly evaluated. > Please see the s390 JEP for reference: > > https://bugs.openjdk.java.net/browse/JDK-8166730 > > The JEP process is described from: > > http://openjdk.java.net/jeps/0 > > David > ----- > >> Thank you very much. >> >> Best regards, >> Jie >> >> >> On 2019?02?27? 19:47, David Holmes wrote: >>> On 27/02/2019 6:23 pm, Jie Fu wrote: >>>> Hi all, >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8219814 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8219814/webrev.00/ >>>> >>>> When debug the VM in gdb and perform "call help()", the help-info >>>> for pns(...) on Linux/mips is lost. >>>> However, it exists in jdk8. >>> >>> That's because there was some support for an active MIPS port in JDK >>> 8 but that no longer exists. This change may be trivial but it >>> belongs in a project providing a MIPS port until such time as a MIPS >>> port becomes mainline. >>> >>> David >>> ----- >>> >>>> To support debugging on as many platforms as possible, it would be >>>> better to keep it. >>>> >>>> The patch has been tested on Linux/x86-64 and Loongson's >>>> Linux/mips64-port. >>>> Could you please review it? >>>> Thanks a lot. >>>> >>>> Best regards, >>>> Jie >>>> >>>> >> >> From david.holmes at oracle.com Thu Feb 28 05:25:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Feb 2019 15:25:31 +1000 Subject: RFR : 8219746: Provide virtualization related info in the hs_error file on linux ppc64 / ppc64le In-Reply-To: References: Message-ID: <6428bf20-da6d-a70d-8dc9-be02ce0b2468@oracle.com> Hi Matthias, On 28/02/2019 2:59 am, Baesken, Matthias wrote: > Hello, > please review the following change ; it adds virtualization related info in the hs_error file on linux ppc64 / ppc64le . Changes seem okay. I'm a little surprised this is architecture specific, but it's not something I'm familiar with. If we get another variant of this for another arch it will be time to move it into the arch specific files. Thanks, David > On linux ppc64 / ppc64le , we often run in virtualized environments (Power KVM / Power VM ... ). > It is helpful for instance in support cases to get some information about the virtualized environment in the hs_error file . > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8219746 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219746.0/ > > > Thanks , > Matthias > From david.holmes at oracle.com Thu Feb 28 07:19:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Feb 2019 17:19:02 +1000 Subject: RFR 8219492: Restore static callsite resolution for the current class (was: RFR: 8219233: 3x performance drop for some Clojure applications In-Reply-To: References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> Message-ID: <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> I switched the bug ids round so that this small fix is the subtask - 8219492. Please find the webrev at: http://cr.openjdk.java.net/~dholmes/8219492/webrev/ Thanks, David On 27/02/2019 9:37 pm, David Holmes wrote: > Hi Claes, > > On 27/02/2019 5:56 pm, Claes Redestad wrote: >> Hi David, >> >> On 2019-02-27 05:17, David Holmes wrote: >>> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ >> >> patch looks good to me. > > Thanks for looking at this. > >>> bug: https://bugs.openjdk.java.net/browse/JDK-8219233 >> >> As this is only a partial fix (about a 10% improvement in the clojure >> startup repro), I'd suggest moving it to a subtask and leaving >> JDK-8219233 open for the time being - if only to not give the false >> impression the issue is resolved in its entirety. > > Yes I can do that. Though I may use the existing sub-task for this part > and let the main bug become the C1/C2 issue that Vladimir is working on > - the discussion is all in the comments of the main bug anyway. > > Thanks, > David > >> I've verified this recuperates performance completely in cases where >> we're calling into static methods from the class itself, e.g., "Bad"[1], >> and also that it doesn't help in cases where call are routed back via >> another class, e.g., "AlsoBad". >> >> Thanks! >> >> /Claes >> >> [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html >> >>> >>> We had a bug whereby the callsite to a static method was resolved as >>> soon as it was executed, allowing other threads to execute the same >>> code and skip the class initialization check. The fix to that was to >>> not do the resolution if the target class was not fully initialized. >>> This has a consequence that calls to static methods of the current >>> class from the (including transitively) can't be resolved >>> and effectively compiled and so we can take a huge performance hit >>> for those cases (which is a rare case and regular benchmarking showed >>> no issue). Clojure unfortunately uses a style of coding that is >>> significantly impacted by this. >>> >>> There is a simple fix for the direct case of calling a static method >>> from : when we are dealing with the same class then it's okay >>> to do the resolution as the current thread must have on its >>> callstack. No other thread can execute the code being resolved until >>> the initial thread completes the static initialization. >>> >>> Unfortunately that doesn't address the main pattern used by Clojure, >>> but we have a subtask open where Vladimir Ivanov continues to look >>> into that case. And Claes Redestad has also given coding advice on >>> how to avoid the problem in the first place. >>> >>> Testing: tier 1-3 >>> Microbenchmarking - see bug report. >>> >>> Thanks, >>> David >>> ----- From matthias.baesken at sap.com Thu Feb 28 08:14:25 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 28 Feb 2019 08:14:25 +0000 Subject: RFR : 8219746: Provide virtualization related info in the hs_error file on linux ppc64 / ppc64le In-Reply-To: <6428bf20-da6d-a70d-8dc9-be02ce0b2468@oracle.com> References: <6428bf20-da6d-a70d-8dc9-be02ce0b2468@oracle.com> Message-ID: Hi David, thanks for the review . > Changes seem okay. I'm a little surprised this is architecture specific, I do not see the file lparcfg on our x86_64 and s390 Linux machines. And https://manpages.debian.org/testing/powerpc-ibm-utils/lparcfg.5.en.html states : "The lparcfg file is a virtual file which contains information related to an IBM Power Logical Partition." So it seems that it is really (IBM) Power (ppc64) specific . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 28. Februar 2019 06:26 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: Steiner, Andreas > Subject: Re: RFR : 8219746: Provide virtualization related info in the hs_error > file on linux ppc64 / ppc64le > > Hi Matthias, > > On 28/02/2019 2:59 am, Baesken, Matthias wrote: > > Hello, > > please review the following change ; it adds virtualization related info in > the hs_error file on linux ppc64 / ppc64le . > > Changes seem okay. I'm a little surprised this is architecture specific, > but it's not something I'm familiar with. If we get another variant of > this for another arch it will be time to move it into the arch specific > files. > > Thanks, > David > > > On linux ppc64 / ppc64le , we often run in virtualized environments > (Power KVM / Power VM ... ). > > It is helpful for instance in support cases to get some information about the > virtualized environment in the hs_error file . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8219746 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219746.0/ > > From lutz.schmidt at sap.com Thu Feb 28 08:39:28 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 28 Feb 2019 08:39:28 +0000 Subject: RFR : 8219746: Provide virtualization related info in the hs_error file on linux ppc64 / ppc64le In-Reply-To: References: <6428bf20-da6d-a70d-8dc9-be02ce0b2468@oracle.com> Message-ID: <7F7B8E1F-EE11-4B5E-9049-BD884D56A3D0@sap.com> Hi Matthias, your change looks good to me. I'm not a reviewer, though. Thanks for improving the virtualization info. It will be very helpful in understanding why a system is not performing the way it is expected to. Regards, Lutz ?On 28.02.19, 09:14, "hotspot-dev on behalf of Baesken, Matthias" wrote: Hi David, thanks for the review . > Changes seem okay. I'm a little surprised this is architecture specific, I do not see the file lparcfg on our x86_64 and s390 Linux machines. And https://manpages.debian.org/testing/powerpc-ibm-utils/lparcfg.5.en.html states : "The lparcfg file is a virtual file which contains information related to an IBM Power Logical Partition." So it seems that it is really (IBM) Power (ppc64) specific . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 28. Februar 2019 06:26 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: Steiner, Andreas > Subject: Re: RFR : 8219746: Provide virtualization related info in the hs_error > file on linux ppc64 / ppc64le > > Hi Matthias, > > On 28/02/2019 2:59 am, Baesken, Matthias wrote: > > Hello, > > please review the following change ; it adds virtualization related info in > the hs_error file on linux ppc64 / ppc64le . > > Changes seem okay. I'm a little surprised this is architecture specific, > but it's not something I'm familiar with. If we get another variant of > this for another arch it will be time to move it into the arch specific > files. > > Thanks, > David > > > On linux ppc64 / ppc64le , we often run in virtualized environments > (Power KVM / Power VM ... ). > > It is helpful for instance in support cases to get some information about the > virtualized environment in the hs_error file . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8219746 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219746.0/ > > From martin.doerr at sap.com Thu Feb 28 09:00:01 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 28 Feb 2019 09:00:01 +0000 Subject: RFR : 8219746: Provide virtualization related info in the hs_error file on linux ppc64 / ppc64le In-Reply-To: <7F7B8E1F-EE11-4B5E-9049-BD884D56A3D0@sap.com> References: <6428bf20-da6d-a70d-8dc9-be02ce0b2468@oracle.com> <7F7B8E1F-EE11-4B5E-9049-BD884D56A3D0@sap.com> Message-ID: Hi Matthias, looks good. Please remove the whitespaces between "!" and "print_matching_lines_from_file" before pushing. Can you add an example output to the bug, please? Thanks for contributing this enhancement. I think it will be helpful. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Schmidt, Lutz Sent: Donnerstag, 28. Februar 2019 09:39 To: Baesken, Matthias ; David Holmes ; 'hotspot-dev at openjdk.java.net' Cc: Steiner, Andreas Subject: Re: RFR : 8219746: Provide virtualization related info in the hs_error file on linux ppc64 / ppc64le Hi Matthias, your change looks good to me. I'm not a reviewer, though. Thanks for improving the virtualization info. It will be very helpful in understanding why a system is not performing the way it is expected to. Regards, Lutz ?On 28.02.19, 09:14, "hotspot-dev on behalf of Baesken, Matthias" wrote: Hi David, thanks for the review . > Changes seem okay. I'm a little surprised this is architecture specific, I do not see the file lparcfg on our x86_64 and s390 Linux machines. And https://manpages.debian.org/testing/powerpc-ibm-utils/lparcfg.5.en.html states : "The lparcfg file is a virtual file which contains information related to an IBM Power Logical Partition." So it seems that it is really (IBM) Power (ppc64) specific . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 28. Februar 2019 06:26 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: Steiner, Andreas > Subject: Re: RFR : 8219746: Provide virtualization related info in the hs_error > file on linux ppc64 / ppc64le > > Hi Matthias, > > On 28/02/2019 2:59 am, Baesken, Matthias wrote: > > Hello, > > please review the following change ; it adds virtualization related info in > the hs_error file on linux ppc64 / ppc64le . > > Changes seem okay. I'm a little surprised this is architecture specific, > but it's not something I'm familiar with. If we get another variant of > this for another arch it will be time to move it into the arch specific > files. > > Thanks, > David > > > On linux ppc64 / ppc64le , we often run in virtualized environments > (Power KVM / Power VM ... ). > > It is helpful for instance in support cases to get some information about the > virtualized environment in the hs_error file . > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8219746 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219746.0/ > > From claes.redestad at oracle.com Thu Feb 28 11:49:29 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 28 Feb 2019 12:49:29 +0100 Subject: RFR 8219492: Restore static callsite resolution for the current class In-Reply-To: <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> Message-ID: Hi, patch still looks good, thanks for moving this to a sub-task! /Claes On 2019-02-28 08:19, David Holmes wrote: > I switched the bug ids round so that this small fix is the subtask - > 8219492. Please find the webrev at: > > http://cr.openjdk.java.net/~dholmes/8219492/webrev/ > > Thanks, > David > > On 27/02/2019 9:37 pm, David Holmes wrote: >> Hi Claes, >> >> On 27/02/2019 5:56 pm, Claes Redestad wrote: >>> Hi David, >>> >>> On 2019-02-27 05:17, David Holmes wrote: >>>> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ >>> >>> patch looks good to me. >> >> Thanks for looking at this. >> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8219233 >>> >>> As this is only a partial fix (about a 10% improvement in the clojure >>> startup repro), I'd suggest moving it to a subtask and leaving >>> JDK-8219233 open for the time being - if only to not give the false >>> impression the issue is resolved in its entirety. >> >> Yes I can do that. Though I may use the existing sub-task for this >> part and let the main bug become the C1/C2 issue that Vladimir is >> working on - the discussion is all in the comments of the main bug >> anyway. >> >> Thanks, >> David >> >>> I've verified this recuperates performance completely in cases where >>> we're calling into static methods from the class itself, e.g., "Bad"[1], >>> and also that it doesn't help in cases where call are routed back via >>> another class, e.g., "AlsoBad". >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html >>> >>>> >>>> We had a bug whereby the callsite to a static method was resolved as >>>> soon as it was executed, allowing other threads to execute the same >>>> code and skip the class initialization check. The fix to that was to >>>> not do the resolution if the target class was not fully initialized. >>>> This has a consequence that calls to static methods of the current >>>> class from the (including transitively) can't be resolved >>>> and effectively compiled and so we can take a huge performance hit >>>> for those cases (which is a rare case and regular benchmarking >>>> showed no issue). Clojure unfortunately uses a style of coding that >>>> is significantly impacted by this. >>>> >>>> There is a simple fix for the direct case of calling a static method >>>> from : when we are dealing with the same class then it's >>>> okay to do the resolution as the current thread must have >>>> on its callstack. No other thread can execute the code being >>>> resolved until the initial thread completes the static initialization. >>>> >>>> Unfortunately that doesn't address the main pattern used by Clojure, >>>> but we have a subtask open where Vladimir Ivanov continues to look >>>> into that case. And Claes Redestad has also given coding advice on >>>> how to avoid the problem in the first place. >>>> >>>> Testing: tier 1-3 >>>> Microbenchmarking - see bug report. >>>> >>>> Thanks, >>>> David >>>> ----- From david.holmes at oracle.com Thu Feb 28 12:00:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 Feb 2019 22:00:41 +1000 Subject: RFR 8219492: Restore static callsite resolution for the current class In-Reply-To: References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> Message-ID: <0d233f22-3abb-3bc5-3620-e4a68152ef3a@oracle.com> Thanks Claes! David On 28/02/2019 9:49 pm, Claes Redestad wrote: > Hi, > > patch still looks good, thanks for moving this to a sub-task! > > /Claes > > On 2019-02-28 08:19, David Holmes wrote: >> I switched the bug ids round so that this small fix is the subtask - >> 8219492. Please find the webrev at: >> >> http://cr.openjdk.java.net/~dholmes/8219492/webrev/ >> >> Thanks, >> David >> >> On 27/02/2019 9:37 pm, David Holmes wrote: >>> Hi Claes, >>> >>> On 27/02/2019 5:56 pm, Claes Redestad wrote: >>>> Hi David, >>>> >>>> On 2019-02-27 05:17, David Holmes wrote: >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ >>>> >>>> patch looks good to me. >>> >>> Thanks for looking at this. >>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8219233 >>>> >>>> As this is only a partial fix (about a 10% improvement in the clojure >>>> startup repro), I'd suggest moving it to a subtask and leaving >>>> JDK-8219233 open for the time being - if only to not give the false >>>> impression the issue is resolved in its entirety. >>> >>> Yes I can do that. Though I may use the existing sub-task for this >>> part and let the main bug become the C1/C2 issue that Vladimir is >>> working on - the discussion is all in the comments of the main bug >>> anyway. >>> >>> Thanks, >>> David >>> >>>> I've verified this recuperates performance completely in cases where >>>> we're calling into static methods from the class itself, e.g., >>>> "Bad"[1], >>>> and also that it doesn't help in cases where call are routed back via >>>> another class, e.g., "AlsoBad". >>>> >>>> Thanks! >>>> >>>> /Claes >>>> >>>> [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html >>>> >>>>> >>>>> We had a bug whereby the callsite to a static method was resolved >>>>> as soon as it was executed, allowing other threads to execute the >>>>> same code and skip the class initialization check. The fix to that >>>>> was to not do the resolution if the target class was not fully >>>>> initialized. This has a consequence that calls to static methods of >>>>> the current class from the (including transitively) can't >>>>> be resolved and effectively compiled and so we can take a huge >>>>> performance hit for those cases (which is a rare case and regular >>>>> benchmarking showed no issue). Clojure unfortunately uses a style >>>>> of coding that is significantly impacted by this. >>>>> >>>>> There is a simple fix for the direct case of calling a static >>>>> method from : when we are dealing with the same class then >>>>> it's okay to do the resolution as the current thread must have >>>>> on its callstack. No other thread can execute the code >>>>> being resolved until the initial thread completes the static >>>>> initialization. >>>>> >>>>> Unfortunately that doesn't address the main pattern used by >>>>> Clojure, but we have a subtask open where Vladimir Ivanov continues >>>>> to look into that case. And Claes Redestad has also given coding >>>>> advice on how to avoid the problem in the first place. >>>>> >>>>> Testing: tier 1-3 >>>>> Microbenchmarking - see bug report. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- From lois.foltan at oracle.com Thu Feb 28 12:18:24 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 28 Feb 2019 07:18:24 -0500 Subject: RFR 8219492: Restore static callsite resolution for the current class In-Reply-To: <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> Message-ID: <4a652591-06b4-bb54-131e-2896b2daa76a@oracle.com> Looks good. Lois On 2/28/2019 2:19 AM, David Holmes wrote: > I switched the bug ids round so that this small fix is the subtask - > 8219492. Please find the webrev at: > > http://cr.openjdk.java.net/~dholmes/8219492/webrev/ > > Thanks, > David > > On 27/02/2019 9:37 pm, David Holmes wrote: >> Hi Claes, >> >> On 27/02/2019 5:56 pm, Claes Redestad wrote: >>> Hi David, >>> >>> On 2019-02-27 05:17, David Holmes wrote: >>>> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ >>> >>> patch looks good to me. >> >> Thanks for looking at this. >> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8219233 >>> >>> As this is only a partial fix (about a 10% improvement in the clojure >>> startup repro), I'd suggest moving it to a subtask and leaving >>> JDK-8219233 open for the time being - if only to not give the false >>> impression the issue is resolved in its entirety. >> >> Yes I can do that. Though I may use the existing sub-task for this >> part and let the main bug become the C1/C2 issue that Vladimir is >> working on - the discussion is all in the comments of the main bug >> anyway. >> >> Thanks, >> David >> >>> I've verified this recuperates performance completely in cases where >>> we're calling into static methods from the class itself, e.g., >>> "Bad"[1], >>> and also that it doesn't help in cases where call are routed back via >>> another class, e.g., "AlsoBad". >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html >>> >>>> >>>> We had a bug whereby the callsite to a static method was resolved >>>> as soon as it was executed, allowing other threads to execute the >>>> same code and skip the class initialization check. The fix to that >>>> was to not do the resolution if the target class was not fully >>>> initialized. This has a consequence that calls to static methods of >>>> the current class from the (including transitively) can't >>>> be resolved and effectively compiled and so we can take a huge >>>> performance hit for those cases (which is a rare case and regular >>>> benchmarking showed no issue). Clojure unfortunately uses a style >>>> of coding that is significantly impacted by this. >>>> >>>> There is a simple fix for the direct case of calling a static >>>> method from : when we are dealing with the same class then >>>> it's okay to do the resolution as the current thread must have >>>> on its callstack. No other thread can execute the code >>>> being resolved until the initial thread completes the static >>>> initialization. >>>> >>>> Unfortunately that doesn't address the main pattern used by >>>> Clojure, but we have a subtask open where Vladimir Ivanov continues >>>> to look into that case. And Claes Redestad has also given coding >>>> advice on how to avoid the problem in the first place. >>>> >>>> Testing: tier 1-3 >>>> Microbenchmarking - see bug report. >>>> >>>> Thanks, >>>> David >>>> ----- From goetz.lindenmaier at sap.com Thu Feb 28 13:05:12 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 28 Feb 2019 13:05:12 +0000 Subject: 8219918: ProblemList tests failing in SAP testing. Message-ID: Hi, in our testing we see a few tests failing at least since the jdk 11 release. I opened bugs for these issues and would like to add them to the ProblemLists for now: http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/01/ I don't think any of these issues are critical. runtime/ErrorHandling/ErrorHandler.java fails only in a single test case, thus I would like to only exclude this one subtest and edited the test. Best regards, Goetz. From Alan.Bateman at oracle.com Thu Feb 28 13:36:26 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Feb 2019 13:36:26 +0000 Subject: 8219918: ProblemList tests failing in SAP testing. In-Reply-To: References: Message-ID: <7c80c989-48cd-3689-36ff-cdc0f2ac6003@oracle.com> On 28/02/2019 13:05, Lindenmaier, Goetz wrote: > Hi, > > in our testing we see a few tests failing at least since the jdk 11 release. > I opened bugs for these issues and would like to add them to > the ProblemLists for now: > > http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/01/ > > I don't think any of these issues are critical. > This excludes the the CopyAndMove.java test which is critical to testing the Files.copy/move APIs. Can you start a discussion on nio-dev with info about the test environment rather than excluding this really important test. -Alan From christoph.langer at sap.com Thu Feb 28 15:14:38 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 28 Feb 2019 15:14:38 +0000 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs In-Reply-To: <6f1b7776-1f52-00a6-4d35-859bb90b907c@oracle.com> References: <960a11003daa403fbc8bb841206b8853@sap.com> <860c3fcdf7da4af58add6bf1af290ff4@sap.com> <6f1b7776-1f52-00a6-4d35-859bb90b907c@oracle.com> Message-ID: <3eb93f5bd5ad44c4860e46434c2142e1@sap.com> Hi, I've pushed Ralf's fix today after running it through the submit repo. As it seems to relate to JDK-8214074 (Optimize Ghash using AVX instructions) and this one is in jdk12, I guess it is quite urgent to bring this fix to jdk12 as well. We see the assertion in debug builds. And in the opt builds, I guess the memory would potentially be overwritten. How would you assess the urgency? Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > David Holmes > Sent: Dienstag, 26. Februar 2019 22:33 > To: Schmelter, Ralf ; HotSpot Open Source > Developers > Subject: Re: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs > > Hi Ralf, > > webrev.1 looks good. > > Thanks, > David > > On 27/02/2019 1:50 am, Schmelter, Ralf wrote: > > Hi David, > > > >> I agree with Matthias: can this be a DEBUG_ONLY change? > > > > code_size2 is the size of the BufferBlob which is allocated to contain the > "stub routines 2" created by StubGenerator. And in the debug build we > check via assertions, that we don't overwrite the buffer. In the optimized > version, we would later just overwrite part of the stub routines. So making it > DEBUG_ONLY defeats the purpose of the change. > > > >> Further is the problem with 32-bit and 64-bit or only 64-bit? Your > > change affects 32-bit. > > > > Since I only build the 64bit VM, I've changed the webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.1/ > > It should now only increase the 64 bit version. > > > > In the end, it would be nice if the initial BufferBlob size could be more > generous and then later adjusted to the really needed space, since it is really > not easy to get a tight upper bound reliably, with it being dependent on the > OS, GC, CPU features and other flags. > > > > Best regards, > > Ralf > > From thomas.stuefe at gmail.com Thu Feb 28 15:21:02 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Feb 2019 16:21:02 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> Message-ID: Took this over from Christoph since he is busy with other stuff. http://cr.openjdk.java.net/~stuefe/webrevs/8219650-shade-print-hex/webrev.00/webrev/ New webrev. I changed: - Fixed alignment issue in os::print_hex_dump - the test now explicitly tests bad alignment Note that the reason is_readable_pointer() did not catch the SIGBUS was that is_readable_pointer() does a SafeFetch32 on the address; so, it just requires 32bit alignment. In the crash case, we had 32bit aligned pointer and tried to load a 64bit valute (unitsize=8). ..Thomas On Mon, Feb 25, 2019 at 3:44 PM Aleksey Shipilev wrote: > On 2/25/19 3:26 PM, Langer, Christoph wrote: > > please review the following small test fix. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ > > Looks good to me. > > If you will, I'd prefer to allocate char* to guarantee the size of array. > > -Aleksey > > From christoph.langer at sap.com Thu Feb 28 15:38:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 28 Feb 2019 15:38:27 +0000 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> Message-ID: <1926250756b14e17b2dbc22eef40520e@sap.com> Hi Thomas, thanks for taking this on. It looks good to me, let?s wait for tonight?s results? Best regards Christoph From: Thomas St?fe Sent: Donnerstag, 28. Februar 2019 16:21 To: Aleksey Shipilev Cc: Langer, Christoph ; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" Took this over from Christoph since he is busy with other stuff. http://cr.openjdk.java.net/~stuefe/webrevs/8219650-shade-print-hex/webrev.00/webrev/ New webrev. I changed: - Fixed alignment issue in os::print_hex_dump - the test now explicitly tests bad alignment Note that the reason is_readable_pointer() did not catch the SIGBUS was that is_readable_pointer() does a SafeFetch32 on the address; so, it just requires 32bit alignment. In the crash case, we had 32bit aligned pointer and tried to load a 64bit valute (unitsize=8). ..Thomas On Mon, Feb 25, 2019 at 3:44 PM Aleksey Shipilev > wrote: On 2/25/19 3:26 PM, Langer, Christoph wrote: > please review the following small test fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ Looks good to me. If you will, I'd prefer to allocate char* to guarantee the size of array. -Aleksey From daniel.daugherty at oracle.com Thu Feb 28 15:47:56 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 28 Feb 2019 10:47:56 -0500 Subject: 8219918: ProblemList tests failing in SAP testing. In-Reply-To: <7c80c989-48cd-3689-36ff-cdc0f2ac6003@oracle.com> References: <7c80c989-48cd-3689-36ff-cdc0f2ac6003@oracle.com> Message-ID: <50a7ad12-9d70-c838-1baa-5d0ee6337c85@oracle.com> On 2/28/19 8:36 AM, Alan Bateman wrote: > On 28/02/2019 13:05, Lindenmaier, Goetz wrote: >> Hi, >> >> in our testing we see a few tests failing at least since the jdk 11 >> release. >> I opened bugs for these issues and would like to add them to >> the ProblemLists for now: >> >> http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/01/ >> >> I don't think any of these issues are critical. >> > > This excludes the the CopyAndMove.java test which is critical to > testing the Files.copy/move APIs. Can you start a discussion on > nio-dev with info about the test environment rather than excluding > this really important test. > > -Alan In the bug there is a mix of hotspot and jdk tests and this review request was only sent to hotspot-dev at ... I think trying to do this in one bug is not quite appropriate for review purposes. Perhaps an umbrella bug with subtasks? Dunno... Dan From shade at redhat.com Thu Feb 28 15:58:56 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 Feb 2019 16:58:56 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> Message-ID: <04555104-3ad3-0135-e45c-2ae4e0a621bd@redhat.com> On 2/28/19 4:21 PM, Thomas St?fe wrote: > Took this over from Christoph since he is busy with other stuff. > > http://cr.openjdk.java.net/~stuefe/webrevs/8219650-shade-print-hex/webrev.00/webrev/ Looks okay. Do we really need to change stack alloc to malloc now, though? For any char*, either the char* itself, or (char*) + 1 would be misaligned for any unit size greater than 1. > Note that the reason is_readable_pointer() did not catch the SIGBUS was that is_readable_pointer() > does a SafeFetch32 on the address; so, it just requires 32bit alignment. In the crash case, we had > 32bit aligned pointer and tried to load a 64bit valute (unitsize=8). Dang. That's a problem for is_readable_pointer, is it not? It should be doing native-width access? -Aleksey From matthias.baesken at sap.com Thu Feb 28 16:04:44 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 28 Feb 2019 16:04:44 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: Hello, I provided a second version . The x86_64 assembler code was simplified (thanks to Martin for the hint) ; additionally some comments were adjusted . http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.2/ Best regards , Matthias Hello , please review the following change. It provides basic virtualization related information in the hs_error file on linux/windows x86_64. We use cpuid to get the information (detection of VMWare, Xen, KVM and HyperV is included). Some info about how to detect the virtualization info can be found here : https://kb.vmware.com/s/article/1009458 (it is VMware related but can be applied for other virtualization technologies as well) An overview of the ID strings can be found here as well : https://en.wikipedia.org/wiki/CPUID The following are known ID strings from virtual machines: ... bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219241 http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.1/ Thanks, Matthias From martin.doerr at sap.com Thu Feb 28 16:17:42 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 28 Feb 2019 16:17:42 +0000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: Hi Matthias, thanks for simplifying the assembler parts a little bit (as discussed offline). Looks good to me. I think this is a helpful feature because virtualization can cause strange performance effects which may be hard to identify otherwise. Best regards, Martin From: Baesken, Matthias Sent: Donnerstag, 28. Februar 2019 17:05 To: 'hotspot-dev at openjdk.java.net' Cc: Doerr, Martin Subject: RE: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 Hello, I provided a second version . The x86_64 assembler code was simplified (thanks to Martin for the hint) ; additionally some comments were adjusted . http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.2/ Best regards , Matthias Hello , please review the following change. It provides basic virtualization related information in the hs_error file on linux/windows x86_64. We use cpuid to get the information (detection of VMWare, Xen, KVM and HyperV is included). Some info about how to detect the virtualization info can be found here : https://kb.vmware.com/s/article/1009458 (it is VMware related but can be applied for other virtualization technologies as well) An overview of the ID strings can be found here as well : https://en.wikipedia.org/wiki/CPUID The following are known ID strings from virtual machines: ... bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219241 http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.1/ Thanks, Matthias From goetz.lindenmaier at sap.com Thu Feb 28 17:11:34 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 28 Feb 2019 17:11:34 +0000 Subject: 8219918: ProblemList tests failing in SAP testing. In-Reply-To: <50a7ad12-9d70-c838-1baa-5d0ee6337c85@oracle.com> References: <7c80c989-48cd-3689-36ff-cdc0f2ac6003@oracle.com> <50a7ad12-9d70-c838-1baa-5d0ee6337c85@oracle.com> Message-ID: I'll split it ... will be stuck with jdk / CopyAndMove anyways :) Best regards, Goetz. > -----Original Message----- > From: Daniel D. Daugherty > Sent: Donnerstag, 28. Februar 2019 16:48 > To: Alan Bateman ; Lindenmaier, Goetz > ; hotspot-dev at openjdk.java.net > Subject: Re: 8219918: ProblemList tests failing in SAP testing. > > On 2/28/19 8:36 AM, Alan Bateman wrote: > > On 28/02/2019 13:05, Lindenmaier, Goetz wrote: > >> Hi, > >> > >> in our testing we see a few tests failing at least since the jdk 11 > >> release. > >> I opened bugs for these issues and would like to add them to > >> the ProblemLists for now: > >> > >> http://cr.openjdk.java.net/~goetz/wr19/8219918-problemList/01/ > >> > >> I don't think any of these issues are critical. > >> > > > > This excludes the the CopyAndMove.java test which is critical to > > testing the Files.copy/move APIs. Can you start a discussion on > > nio-dev with info about the test environment rather than excluding > > this really important test. > > > > -Alan > > In the bug there is a mix of hotspot and jdk tests and this review > request was only sent to hotspot-dev at ... I think trying to do this > in one bug is not quite appropriate for review purposes. Perhaps > an umbrella bug with subtasks? Dunno... > > Dan From vladimir.x.ivanov at oracle.com Thu Feb 28 18:01:06 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 28 Feb 2019 10:01:06 -0800 Subject: RFR 8219492: Restore static callsite resolution for the current class In-Reply-To: <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> Message-ID: <76aeaa88-45c0-232d-b450-f2906b8ed69a@oracle.com> > I switched the bug ids round so that this small fix is the subtask - > 8219492. Please find the webrev at: > > http://cr.openjdk.java.net/~dholmes/8219492/webrev/ Looks good. Best regards, Vladimir Ivanov > On 27/02/2019 9:37 pm, David Holmes wrote: >> Hi Claes, >> >> On 27/02/2019 5:56 pm, Claes Redestad wrote: >>> Hi David, >>> >>> On 2019-02-27 05:17, David Holmes wrote: >>>> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ >>> >>> patch looks good to me. >> >> Thanks for looking at this. >> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8219233 >>> >>> As this is only a partial fix (about a 10% improvement in the clojure >>> startup repro), I'd suggest moving it to a subtask and leaving >>> JDK-8219233 open for the time being - if only to not give the false >>> impression the issue is resolved in its entirety. >> >> Yes I can do that. Though I may use the existing sub-task for this >> part and let the main bug become the C1/C2 issue that Vladimir is >> working on - the discussion is all in the comments of the main bug >> anyway. >> >> Thanks, >> David >> >>> I've verified this recuperates performance completely in cases where >>> we're calling into static methods from the class itself, e.g., "Bad"[1], >>> and also that it doesn't help in cases where call are routed back via >>> another class, e.g., "AlsoBad". >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html >>> >>>> >>>> We had a bug whereby the callsite to a static method was resolved as >>>> soon as it was executed, allowing other threads to execute the same >>>> code and skip the class initialization check. The fix to that was to >>>> not do the resolution if the target class was not fully initialized. >>>> This has a consequence that calls to static methods of the current >>>> class from the (including transitively) can't be resolved >>>> and effectively compiled and so we can take a huge performance hit >>>> for those cases (which is a rare case and regular benchmarking >>>> showed no issue). Clojure unfortunately uses a style of coding that >>>> is significantly impacted by this. >>>> >>>> There is a simple fix for the direct case of calling a static method >>>> from : when we are dealing with the same class then it's >>>> okay to do the resolution as the current thread must have >>>> on its callstack. No other thread can execute the code being >>>> resolved until the initial thread completes the static initialization. >>>> >>>> Unfortunately that doesn't address the main pattern used by Clojure, >>>> but we have a subtask open where Vladimir Ivanov continues to look >>>> into that case. And Claes Redestad has also given coding advice on >>>> how to avoid the problem in the first place. >>>> >>>> Testing: tier 1-3 >>>> Microbenchmarking - see bug report. >>>> >>>> Thanks, >>>> David >>>> ----- From thomas.stuefe at gmail.com Thu Feb 28 18:21:21 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Feb 2019 19:21:21 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: <04555104-3ad3-0135-e45c-2ae4e0a621bd@redhat.com> References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <04555104-3ad3-0135-e45c-2ae4e0a621bd@redhat.com> Message-ID: On Thu, Feb 28, 2019 at 4:59 PM Aleksey Shipilev wrote: > On 2/28/19 4:21 PM, Thomas St?fe wrote: > > Took this over from Christoph since he is busy with other stuff. > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8219650-shade-print-hex/webrev.00/webrev/ > > Looks okay. > thanks! > > Do we really need to change stack alloc to malloc now, though? For any > char*, either the char* > itself, or (char*) + 1 would be misaligned for any unit size greater than > 1. > > Yeah.. thats maybe me being a bit anal. I like having a confirmed aligned case first. Unless it really irks you, lets keep it that way. We all spent way too much time on this thing, and while it is a really fascinating topic... :) > Note that the reason is_readable_pointer() did not catch the SIGBUS was > that is_readable_pointer() > > does a SafeFetch32 on the address; so, it just requires 32bit alignment. > In the crash case, we had > > 32bit aligned pointer and tried to load a 64bit valute (unitsize=8). > > Dang. That's a problem for is_readable_pointer, is it not? It should be > doing native-width access? > I think is_readable_pointer makes no promises about the alignment, just that if you access that location it you wont access unmapped memory. Otherwise, what would be the right way? is_readable_pointer() cannot know what I plan to do with the pointer. I might plan to load a single byte from it. ..Thomas > -Aleksey > > From thomas.stuefe at gmail.com Thu Feb 28 18:21:46 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 28 Feb 2019 19:21:46 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: <1926250756b14e17b2dbc22eef40520e@sap.com> References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <1926250756b14e17b2dbc22eef40520e@sap.com> Message-ID: Thanks, Christoph! On Thu, Feb 28, 2019 at 4:38 PM Langer, Christoph wrote: > Hi Thomas, > > > > thanks for taking this on. > > > > It looks good to me, let?s wait for tonight?s results? > > > > Best regards > > Christoph > > > > *From:* Thomas St?fe > *Sent:* Donnerstag, 28. Februar 2019 16:21 > *To:* Aleksey Shipilev > *Cc:* Langer, Christoph ; > hotspot-dev at openjdk.java.net > *Subject:* Re: RFR(S): 8219650: [Testbug] Fix potential crashes in new > test hotspot gtest "test_print_hex_dump" > > > > Took this over from Christoph since he is busy with other stuff. > > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8219650-shade-print-hex/webrev.00/webrev/ > > > > New webrev. > > > > I changed: > > > > - Fixed alignment issue in os::print_hex_dump > > - the test now explicitly tests bad alignment > > > > Note that the reason is_readable_pointer() did not catch the SIGBUS was > that is_readable_pointer() does a SafeFetch32 on the address; so, it just > requires 32bit alignment. In the crash case, we had 32bit aligned pointer > and tried to load a 64bit valute (unitsize=8). > > > > > > ..Thomas > > > > > > > > > > On Mon, Feb 25, 2019 at 3:44 PM Aleksey Shipilev wrote: > > On 2/25/19 3:26 PM, Langer, Christoph wrote: > > please review the following small test fix. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219650 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8219650.0/ > > Looks good to me. > > If you will, I'd prefer to allocate char* to guarantee the size of array. > > -Aleksey > > From shade at redhat.com Thu Feb 28 18:26:51 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 Feb 2019 19:26:51 +0100 Subject: RFR(S): 8219650: [Testbug] Fix potential crashes in new test hotspot gtest "test_print_hex_dump" In-Reply-To: References: <19194f67-ed19-0031-e1a9-e79b56a777f0@redhat.com> <04555104-3ad3-0135-e45c-2ae4e0a621bd@redhat.com> Message-ID: <33b1d1bb-3837-40e3-08f7-313be235c213@redhat.com> On 2/28/19 7:21 PM, Thomas St?fe wrote: > On Thu, Feb 28, 2019 at 4:59 PM Aleksey Shipilev > wrote: > Do we really need to change stack alloc to malloc now, though? For any char*, either the char* > itself, or (char*) + 1 would be misaligned for any unit size greater than 1. > > Yeah.. thats maybe me being a bit anal. I like having a confirmed aligned case first. > > Unless it really irks you, lets keep it that way. We all spent way too much time on this thing, and > while it is a really fascinating topic... :) Yeah, no reason to sink more time into it. Let's move on! > > Note that the reason is_readable_pointer() did not catch the SIGBUS was that is_readable_pointer() > > does a SafeFetch32 on the address; so, it just requires 32bit alignment. In the crash case, we had > > 32bit aligned pointer and tried to load a 64bit valute (unitsize=8). > > Dang. That's a problem for is_readable_pointer, is it not? It should be doing native-width access? > > I think is_readable_pointer makes no promises about the alignment, just that if you access that > location it you wont access unmapped memory.? > > Otherwise, what would be the right way? is_readable_pointer() cannot know what I plan to do with the > pointer. I might plan to load a single byte from it. Right. The responsibility of proper alignment is on caller anyway, and print_hex_dump now does it properly. -Aleksey From vladimir.kozlov at oracle.com Thu Feb 28 19:32:30 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 28 Feb 2019 11:32:30 -0800 Subject: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs In-Reply-To: <3eb93f5bd5ad44c4860e46434c2142e1@sap.com> References: <960a11003daa403fbc8bb841206b8853@sap.com> <860c3fcdf7da4af58add6bf1af290ff4@sap.com> <6f1b7776-1f52-00a6-4d35-859bb90b907c@oracle.com> <3eb93f5bd5ad44c4860e46434c2142e1@sap.com> Message-ID: <408b4714-8204-0540-0aff-dfaeb6a73464@oracle.com> Since it is seen only in debug build it is not urgent. I agree to fix it in 12 update - I approved request. Thanks, Vladimir On 2/28/19 7:14 AM, Langer, Christoph wrote: > Hi, > > I've pushed Ralf's fix today after running it through the submit repo. > > As it seems to relate to JDK-8214074 (Optimize Ghash using AVX instructions) and this one is in jdk12, I guess it is quite urgent to bring this fix to jdk12 as well. We see the assertion in debug builds. And in the opt builds, I guess the memory would potentially be overwritten. How would you assess the urgency? > > Best regards > Christoph > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> David Holmes >> Sent: Dienstag, 26. Februar 2019 22:33 >> To: Schmelter, Ralf ; HotSpot Open Source >> Developers >> Subject: Re: RFR (S) 8219712: code_size2 is too small on new Skylake CPUs >> >> Hi Ralf, >> >> webrev.1 looks good. >> >> Thanks, >> David >> >> On 27/02/2019 1:50 am, Schmelter, Ralf wrote: >>> Hi David, >>> >>>> I agree with Matthias: can this be a DEBUG_ONLY change? >>> >>> code_size2 is the size of the BufferBlob which is allocated to contain the >> "stub routines 2" created by StubGenerator. And in the debug build we >> check via assertions, that we don't overwrite the buffer. In the optimized >> version, we would later just overwrite part of the stub routines. So making it >> DEBUG_ONLY defeats the purpose of the change. >>> >>>> Further is the problem with 32-bit and 64-bit or only 64-bit? Your >>> change affects 32-bit. >>> >>> Since I only build the 64bit VM, I've changed the webrev: >> http://cr.openjdk.java.net/~rschmelter/webrevs/8219712/webrev.1/ >>> It should now only increase the 64 bit version. >>> >>> In the end, it would be nice if the initial BufferBlob size could be more >> generous and then later adjusted to the really needed space, since it is really >> not easy to get a tight upper bound reliably, with it being dependent on the >> OS, GC, CPU features and other flags. >>> >>> Best regards, >>> Ralf >>> From harold.seigel at oracle.com Thu Feb 28 20:22:58 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 28 Feb 2019 15:22:58 -0500 Subject: RFR 8191278: MappedByteBuffer bulk access memory failures are not handled gracefully Message-ID: <8ecf4f01-b7e2-c1a7-921d-51aee6e49777@oracle.com> Hi, Please review this fix for JDK-8191278.? The fix uses the GuardUnsafeAccess class in unsafe.cpp so that the signal handler will know to convert SIGBUS signals to exceptions. The compiler related changes and much of the test were written by Jamsheesh (jcm). Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8191278/webrev/index.html JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8191278 The fix was tested on Linux x64, Mac OS, Solaris Sparc, and Windows.? Testing was not done on the other platforms changed by this fix. The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux x64, Solaris, Windows, and Mac OS X, by running Mach5 tiers 3 -5 on Linux x64, and by running JCK-13 Lang and VM tests on Linux x64. Thanks, Harold From david.holmes at oracle.com Thu Feb 28 21:24:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Mar 2019 07:24:18 +1000 Subject: RFR 8219492: Restore static callsite resolution for the current class In-Reply-To: <76aeaa88-45c0-232d-b450-f2906b8ed69a@oracle.com> References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> <76aeaa88-45c0-232d-b450-f2906b8ed69a@oracle.com> Message-ID: <79a867f4-9d45-e403-17b9-520a90f09e40@oracle.com> Thanks Vladimir! David On 1/03/2019 4:01 am, Vladimir Ivanov wrote: > >> I switched the bug ids round so that this small fix is the subtask - >> 8219492. Please find the webrev at: >> >> http://cr.openjdk.java.net/~dholmes/8219492/webrev/ > > Looks good. > > Best regards, > Vladimir Ivanov > >> On 27/02/2019 9:37 pm, David Holmes wrote: >>> Hi Claes, >>> >>> On 27/02/2019 5:56 pm, Claes Redestad wrote: >>>> Hi David, >>>> >>>> On 2019-02-27 05:17, David Holmes wrote: >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ >>>> >>>> patch looks good to me. >>> >>> Thanks for looking at this. >>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8219233 >>>> >>>> As this is only a partial fix (about a 10% improvement in the clojure >>>> startup repro), I'd suggest moving it to a subtask and leaving >>>> JDK-8219233 open for the time being - if only to not give the false >>>> impression the issue is resolved in its entirety. >>> >>> Yes I can do that. Though I may use the existing sub-task for this >>> part and let the main bug become the C1/C2 issue that Vladimir is >>> working on - the discussion is all in the comments of the main bug >>> anyway. >>> >>> Thanks, >>> David >>> >>>> I've verified this recuperates performance completely in cases where >>>> we're calling into static methods from the class itself, e.g., >>>> "Bad"[1], >>>> and also that it doesn't help in cases where call are routed back via >>>> another class, e.g., "AlsoBad". >>>> >>>> Thanks! >>>> >>>> /Claes >>>> >>>> [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html >>>> >>>>> >>>>> We had a bug whereby the callsite to a static method was resolved >>>>> as soon as it was executed, allowing other threads to execute the >>>>> same code and skip the class initialization check. The fix to that >>>>> was to not do the resolution if the target class was not fully >>>>> initialized. This has a consequence that calls to static methods of >>>>> the current class from the (including transitively) can't >>>>> be resolved and effectively compiled and so we can take a huge >>>>> performance hit for those cases (which is a rare case and regular >>>>> benchmarking showed no issue). Clojure unfortunately uses a style >>>>> of coding that is significantly impacted by this. >>>>> >>>>> There is a simple fix for the direct case of calling a static >>>>> method from : when we are dealing with the same class then >>>>> it's okay to do the resolution as the current thread must have >>>>> on its callstack. No other thread can execute the code >>>>> being resolved until the initial thread completes the static >>>>> initialization. >>>>> >>>>> Unfortunately that doesn't address the main pattern used by >>>>> Clojure, but we have a subtask open where Vladimir Ivanov continues >>>>> to look into that case. And Claes Redestad has also given coding >>>>> advice on how to avoid the problem in the first place. >>>>> >>>>> Testing: tier 1-3 >>>>> Microbenchmarking - see bug report. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- From david.holmes at oracle.com Thu Feb 28 21:23:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Mar 2019 07:23:51 +1000 Subject: RFR 8219492: Restore static callsite resolution for the current class In-Reply-To: <4a652591-06b4-bb54-131e-2896b2daa76a@oracle.com> References: <3bb9a918-2ab5-6024-ff15-3bb6cce4d4c4@oracle.com> <06707530-7b23-d5ee-f08d-c14726961c60@oracle.com> <4129229b-9970-eb73-d6a7-129fba9fb1ea@oracle.com> <4a652591-06b4-bb54-131e-2896b2daa76a@oracle.com> Message-ID: <5e27bd96-4d1e-f819-e876-4b4caaef2e0b@oracle.com> Thanks for taking a look Lois! David On 28/02/2019 10:18 pm, Lois Foltan wrote: > Looks good. > Lois > > On 2/28/2019 2:19 AM, David Holmes wrote: >> I switched the bug ids round so that this small fix is the subtask - >> 8219492. Please find the webrev at: >> >> http://cr.openjdk.java.net/~dholmes/8219492/webrev/ >> >> Thanks, >> David >> >> On 27/02/2019 9:37 pm, David Holmes wrote: >>> Hi Claes, >>> >>> On 27/02/2019 5:56 pm, Claes Redestad wrote: >>>> Hi David, >>>> >>>> On 2019-02-27 05:17, David Holmes wrote: >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8219233/webrev.v2/ >>>> >>>> patch looks good to me. >>> >>> Thanks for looking at this. >>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8219233 >>>> >>>> As this is only a partial fix (about a 10% improvement in the clojure >>>> startup repro), I'd suggest moving it to a subtask and leaving >>>> JDK-8219233 open for the time being - if only to not give the false >>>> impression the issue is resolved in its entirety. >>> >>> Yes I can do that. Though I may use the existing sub-task for this >>> part and let the main bug become the C1/C2 issue that Vladimir is >>> working on - the discussion is all in the comments of the main bug >>> anyway. >>> >>> Thanks, >>> David >>> >>>> I've verified this recuperates performance completely in cases where >>>> we're calling into static methods from the class itself, e.g., >>>> "Bad"[1], >>>> and also that it doesn't help in cases where call are routed back via >>>> another class, e.g., "AlsoBad". >>>> >>>> Thanks! >>>> >>>> /Claes >>>> >>>> [1] https://cl4es.github.io/2019/02/21/Cljinit-Woes.html >>>> >>>>> >>>>> We had a bug whereby the callsite to a static method was resolved >>>>> as soon as it was executed, allowing other threads to execute the >>>>> same code and skip the class initialization check. The fix to that >>>>> was to not do the resolution if the target class was not fully >>>>> initialized. This has a consequence that calls to static methods of >>>>> the current class from the (including transitively) can't >>>>> be resolved and effectively compiled and so we can take a huge >>>>> performance hit for those cases (which is a rare case and regular >>>>> benchmarking showed no issue). Clojure unfortunately uses a style >>>>> of coding that is significantly impacted by this. >>>>> >>>>> There is a simple fix for the direct case of calling a static >>>>> method from : when we are dealing with the same class then >>>>> it's okay to do the resolution as the current thread must have >>>>> on its callstack. No other thread can execute the code >>>>> being resolved until the initial thread completes the static >>>>> initialization. >>>>> >>>>> Unfortunately that doesn't address the main pattern used by >>>>> Clojure, but we have a subtask open where Vladimir Ivanov continues >>>>> to look into that case. And Claes Redestad has also given coding >>>>> advice on how to avoid the problem in the first place. >>>>> >>>>> Testing: tier 1-3 >>>>> Microbenchmarking - see bug report. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- > From david.holmes at oracle.com Thu Feb 28 21:48:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Mar 2019 07:48:48 +1000 Subject: RFR: 8219241: Provide basic virtualization related info in the hs_error file on linux/windows x86_64 In-Reply-To: References: Message-ID: <98b6c488-a935-9b43-7382-5bfc732f0ac7@oracle.com> Hi Matthias, Combining this with 8219746 I have to insist that we use a nice clean OS-CPU abstraction for dealing with this and get rid of the platform ifdefs in os::Linux::print_virtualization_info. What you've added in VM_Version would seem to be the right kind of platform specific functionality and it seems to me that you could get rid of os::Linux::print_virtualization_info and just use VM_Version::print_detected_virtualization in its place. Thanks, David On 1/03/2019 2:04 am, Baesken, Matthias wrote: > Hello, I provided a second version . > The x86_64 assembler code was simplified (thanks to Martin for the hint) ; additionally some comments were adjusted . > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.2/ > > > Best regards , Matthias > > > > Hello , please review the following change. > It provides basic virtualization related information in the hs_error file on linux/windows x86_64. > We use cpuid to get the information (detection of VMWare, Xen, KVM and HyperV is included). > > Some info about how to detect the virtualization info can be found here : > https://kb.vmware.com/s/article/1009458 > > > > (it is VMware related but can be applied for other virtualization technologies as well) > > > An overview of the ID strings can be found here as well : > > https://en.wikipedia.org/wiki/CPUID > The following are known ID strings from virtual machines: ... > > > > bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8219241 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219241.1/ > > > > Thanks, Matthias >