Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]

2020-09-16 Thread Kim Barrett
On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty wrote: >> This RFE is to migrate the following field to OopStorage: >> >> class ObjectMonitor { >> >> void* volatile _object; // backward object pointer - strong root >> >> Unlike the previous patches in this series, there are a lot of

Re: RFR: 8253028: SA core file tests still time out on OSX with "java.io.IOException: App waiting timeout"

2020-09-16 Thread Alex Menkov
On Tue, 15 Sep 2020 18:53:30 GMT, Chris Plummer wrote: > Some SA core file testing requires longer timeouts since core files can on > occasion take a very long time to produce on > OSX. > I'd like to treat this as a trival change. Agreed that this is trivial change - Marked as

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]

2020-09-16 Thread David Holmes
On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty wrote: >> This RFE is to migrate the following field to OopStorage: >> >> class ObjectMonitor { >> >> void* volatile _object; // backward object pointer - strong root >> >> Unlike the previous patches in this series, there are a lot of

Re: RFR: 8253028: SA core file tests still time out on OSX with "java.io.IOException: App waiting timeout"

2020-09-16 Thread Chris Plummer
On Tue, 15 Sep 2020 18:53:30 GMT, Chris Plummer wrote: > Some SA core file testing requires longer timeouts since core files can on > occasion take a very long time to produce on > OSX. > I'd like to treat this as a trival change. Ping! This change is trivial. Thanks! - PR:

RFR: 8234808: jdb quoted option parsing broken

2020-09-16 Thread Alex Menkov
Migrating this review from the mailing list into a pull request. Some background: when jdb launches debuggee process it passes java options from "options" value for CommandLineLaunch connector and forward options specified before command. The fix solves several discovered issues: - proper

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]

2020-09-16 Thread Erik Österlund
On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty wrote: >> This RFE is to migrate the following field to OopStorage: >> >> class ObjectMonitor { >> >> void* volatile _object; // backward object pointer - strong root >> >> Unlike the previous patches in this series, there are a lot of

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]

2020-09-16 Thread Serguei Spitsyn
On Wed, 16 Sep 2020 16:13:23 GMT, Daniel D. Daugherty wrote: >> This RFE is to migrate the following field to OopStorage: >> >> class ObjectMonitor { >> >> void* volatile _object; // backward object pointer - strong root >> >> Unlike the previous patches in this series, there are a lot of

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]

2020-09-16 Thread Daniel D . Daugherty
On Tue, 15 Sep 2020 10:17:59 GMT, Kim Barrett wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> rkennke, coleenp, fisk CR - delete random assert() that knows too much >> about markWords. > > Marked as

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v6]

2020-09-16 Thread Daniel D . Daugherty
> This RFE is to migrate the following field to OopStorage: > > class ObjectMonitor { > > void* volatile _object; // backward object pointer - strong root > > Unlike the previous patches in this series, there are a lot of collateral > changes so this is not a trivial review. Sorry for the

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]

2020-09-16 Thread Daniel D . Daugherty
On Wed, 16 Sep 2020 08:23:03 GMT, Erik Österlund wrote: >> Marked as reviewed by sspitsyn (Reviewer). > > I added a release note (https://bugs.openjdk.java.net/browse/JDK-8253225) > describing that these roots are now weak, and > hence won't be reported. Please have a look at that, to make sure

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]

2020-09-16 Thread Daniel D . Daugherty
On Wed, 16 Sep 2020 00:07:08 GMT, Serguei Spitsyn wrote: >> I've taken a first pass at creating a CSR: >> JDK-8253121 migrate ObjectMonitor::_object to OopStorage >> https://bugs.openjdk.java.net/browse/JDK-8253121 > > I've looked at the CSR and added myself as a reviewer. > We had a slack chat

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]

2020-09-16 Thread Daniel D . Daugherty
On Wed, 16 Sep 2020 00:20:16 GMT, Serguei Spitsyn wrote: >> I've taken a first pass at creating a CSR: >> JDK-8253121 migrate ObjectMonitor::_object to OopStorage >> https://bugs.openjdk.java.net/browse/JDK-8253121 > > Just a minor comment. > The line 1754 can be deleted as the

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v4]

2020-09-16 Thread Daniel D . Daugherty
On Tue, 15 Sep 2020 10:17:45 GMT, Kim Barrett wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> kimbarrett CR - made minor changes to address Kim's code review. > > src/hotspot/share/runtime/objectMonitor.cpp

Re: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]

2020-09-16 Thread Zhengyu Gu
On Sat, 12 Sep 2020 00:17:58 GMT, Lin Zang wrote: >> - enable parallel heap inspecton for ShenandoahHeap >> - preliminary evaluation: >> Time of jmap histo on (8GB heap with 4GB objects) >> * before: 5.186s >> * after : 1.698s > > Lin Zang has refreshed the contents of this pull

Re: RFR: 8252104: parallel heap inspection for ShenandoahHeap [v3]

2020-09-16 Thread Zhengyu Gu
On Sat, 12 Sep 2020 00:15:06 GMT, Lin Zang wrote: > Hi @zhengyu123 , > Thanks for your comments! I have refined the code and update the PR. > -Lin Looks good to me. @shipilev may want to take a look. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/67

Re: RFR: 8247281: migrate ObjectMonitor::_object to OopStorage [v5]

2020-09-16 Thread Erik Österlund
On Wed, 16 Sep 2020 00:21:02 GMT, Serguei Spitsyn wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one >> additional commit since the last revision: >> >> rkennke, coleenp, fisk CR - delete random assert() that knows too much >> about markWords. > > Marked as

Re: RFR: 8238761: Asynchronous handshakes

2020-09-16 Thread Patricio Chilano
Hi Robbin, Changes look good to me! Some minor comments: src/hotspot/share/prims/jvmtiThreadState.cpp 222:   assert(current_thread == get_thread() || 223:  SafepointSynchronize::is_at_safepoint() || 224: get_thread()->is_handshake_safe_for(current_thread), 225:  "call by myself

Re: RFR: 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT

2020-09-16 Thread Richard Reingruber
On Wed, 16 Sep 2020 06:26:51 GMT, Chris Plummer wrote: >> Continuing review [1] after transition to Git/Github. >> >> I still cannot reproduce the issue. >> >> RFC on alternatives: >> >> 1. Integrate this change and ignore future JVMTI_ERROR_INVALID_SLOT >> 2. Don't ignore

Re: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes()

2020-09-16 Thread Serguei Spitsyn
On Tue, 15 Sep 2020 20:02:38 GMT, Coleen Phillimore wrote: >> The change fixes a 'deadlock' situation in >> VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested >> in the Jira issue [2]

Re: RFR: 8241390: 'Deadlock' with VM_RedefineClasses::lock_classes()

2020-09-16 Thread Serguei Spitsyn
On Tue, 15 Sep 2020 20:02:33 GMT, Coleen Phillimore wrote: >> The change fixes a 'deadlock' situation in >> VM_RedefineClasses::lock_classes() when the current thread is in the middle >> of redefining the same class. The change is based on the fix [1] suggested >> in the Jira issue [2]

Re: RFR: 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT

2020-09-16 Thread Chris Plummer
On Sat, 12 Sep 2020 23:19:46 GMT, Richard Reingruber wrote: > Continuing review [1] after transition to Git/Github. > > I still cannot reproduce the issue. > > RFC on alternatives: > > 1. Integrate this change and ignore future JVMTI_ERROR_INVALID_SLOT > 2. Don't ignore