Re: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should not suspend the thread when the top frame executes JVMCI code

Agreed on both statements below. Thanks, Serguei On 12/3/18 23:32, David Holmes wrote: On 4/12/2018 4:32 pm, serguei.spit...@oracle.com wrote: Hi David and Dean, One option is to add a command line option (disabled by default) to enable debugging/profiling of the Graal compiler. This will

Re: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should not suspend the thread when the top frame executes JVMCI code

On 4/12/2018 4:32 pm, serguei.spit...@oracle.com wrote: Hi David and Dean, One option is to add a command line option (disabled by default) to enable debugging/profiling of the Graal compiler. This will help to avoid all these Graal related issues, simplify the development and stabilize the

Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, Thank you for making the changes. The SA portion looks good to me. One nit though: In src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java, in printGCAlgorithm(), does displaying the nbr of Parallel GC threads not make sense for Shenandoah (like it is for

Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

> 3 dec. 2018 kl. 20:27 skrev Roman Kennke : > > Round 5 of Shenandoah review includes: > - A fix for the @requires tag in TestFullGCCountTest.java. It should be > correct now. We believe the CMS @requires was also not quite right and > fixed it the same. > > It reads now: Don't run this test

RFR (round 5), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Round 5 of Shenandoah review includes: - A fix for the @requires tag in TestFullGCCountTest.java. It should be correct now. We believe the CMS @requires was also not quite right and fixed it the same. It reads now: Don't run this test if: - Actual GC set by harness is CMS *and*

Re: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should not suspend the thread when the top frame executes JVMCI code

Hi David and Dean, One option is to add a command line option (disabled by default) to enable debugging/profiling of the Graal compiler. This will help to avoid all these Graal related issues, simplify the development and stabilize the tests. Not sure the Graal developer will like this proposal

Re: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should not suspend the thread when the top frame executes JVMCI code

On 4/12/2018 5:53 am, dean.l...@oracle.com wrote: On 11/30/18 7:46 PM, JC Beyler wrote: Questions because I'm not familiar with JVMCI consequences so not really comments on the webrev but so that I know:   - Is it normaly that you can suspend when you are in a JVMCI frame? Yes, because it's

Re: RFR 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is expected

Looks good! Thanks, David On 4/12/2018 2:48 am, Patricio Chilano wrote: Hi David, On 12/3/18 2:14 AM, David Holmes wrote: Hi Patricio, On 1/12/2018 2:31 am, Patricio Chilano wrote: Hi David, On 11/29/18 8:05 PM, David Holmes wrote: Hi Patricio, This seems very complicated and I'm not

Re: RFR: (S): JDK-8213323: sa/TestJmapCoreMetaspace.java and sa/TestJmapCore.java fail with ZGC

Thank you, Chris! - Jini On 12/4/2018 9:29 AM, Chris Plummer wrote: Looks good. Chris On 12/2/18 8:36 PM, Jini George wrote: Gentle reminder ! Thanks, Jini On 11/29/2018 12:03 PM, Jini George wrote: Thank you very much, Chris. I have modified HeapHprofBinWriter.java slightly so that the

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

Hi Gary, Somewhere in this I got the mistaken impression that it is the VMThread that blocks waiting for the debugger to attach, but it is actually the main thread executing create_vm. That simplifies things and addresses the concern I had about jcmds that needed VM ops. So IIUC the only

Re: RFR: (S): JDK-8213323: sa/TestJmapCoreMetaspace.java and sa/TestJmapCore.java fail with ZGC

Looks good. Chris On 12/2/18 8:36 PM, Jini George wrote: Gentle reminder ! Thanks, Jini On 11/29/2018 12:03 PM, Jini George wrote: Thank you very much, Chris. I have modified HeapHprofBinWriter.java slightly so that the hprof file does not dumped if this is ZGC. In the test, we check for

Re: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should not suspend the thread when the top frame executes JVMCI code

Hi Daniil, It looks good in general. I have two comments though. -vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/TestDescription.java 8195635 generic-all   It is not a good idea to remove the test from the ProblemList

Re: RFR: JDK-821430: .attach_pid files may remain in the process cwd

+1 Thanks, Serguei On 12/3/18 12:09, Chris Plummer wrote: Looks good. Chris On 12/1/18 3:10 AM, gary.ad...@oracle.com wrote: Updated webrev:  

Re: RFR: JDK-821430: .attach_pid files may remain in the process cwd

Looks good. Chris On 12/1/18 3:10 AM, gary.ad...@oracle.com wrote: Updated webrev:   http://cr.openjdk.java.net/~gadams/8214300/webrev.01/ On 11/30/18 3:10 PM, Chris Plummer wrote:

Re: RFR 8214572: nsk/jvmti/unit/ForceEarlyReturn/earlyretbase should not suspend the thread when the top frame executes JVMCI code

On 11/30/18 7:46 PM, JC Beyler wrote: Questions because I'm not familiar with JVMCI consequences so not really comments on the webrev but so that I know:   - Is it normaly that you can suspend when you are in a JVMCI frame? Yes, because it's just Java code, and we allow all Java code to be

Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Round 5 of Shenandoah review includes: - A fix for the @requires tag in TestFullGCCountTest.java. It should be correct now. We believe the CMS @requires was also not quite right and fixed it the same. It reads now: Don't run this test if: - Actual GC set by harness is CMS *and*

Re: RFR 8214148: [TESTBUG] serviceability/tmtools/jstack/WaitNotifyThreadTest.java is not doing what is expected

Hi David, On 12/3/18 2:14 AM, David Holmes wrote: Hi Patricio, On 1/12/2018 2:31 am, Patricio Chilano wrote: Hi David, On 11/29/18 8:05 PM, David Holmes wrote: Hi Patricio, This seems very complicated and I'm not quite seeing how it all goes together. The check for waiting to re-lock now

Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Per, Thanks for looking again. I've fixed the ordering in shenandoah-dev: http://cr.openjdk.java.net/~rkennke/fix-macro-order/webrev.00/ and it will apear in the next round of webrevs. Thanks, Roman > Hi Roman, > > On 11/30/18 10:00 PM, Roman Kennke wrote: >> Hi all, >> >> here comes

Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Roman, On 11/30/18 10:00 PM, Roman Kennke wrote: Hi all, here comes round 4 of Shenandoah upstreaming review: This includes fixes for the issues that Per brought up: - Verify and gracefully reject dangerous flags combinations that disables required barriers - Revisited @requires filters in

Re: RFR (round 4), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi Jini, Thanks for your suggestions. I've added this to Shenandoah's dev: http://cr.openjdk.java.net/~rkennke/shenandoah-sa/webrev.01/ and it will show up in next round of webrevs. Thanks, Roman > A few comments on the SA changes: > > ==> Could you please add the following lines in >

Re: RFR: 8214484: ZGC: Exclude SA tests ClhsdbJhisto and TestHeapDumpFor*

Thanks for reviewing, Thomas! /Per On 11/30/18 1:53 PM, Thomas Schatzl wrote: Hi, On Thu, 2018-11-29 at 16:07 +0100, Per Liden wrote: There's no support for SA heap walking when using ZGC. Hence the tests for this should not execute when ZGC is enabled. Bug:

Re: Suggested improvement to X86Frame.getInterpreterFrameBCI

Ok great, I will submit new patch then. Thanks for reviewing! Cheers, David On Fri, 30 Nov 2018 at 17:06, JC Beyler wrote: > Hi both, > > The webrev looks good to me but I could see gains of just adding a new > constructor instead of doing a new + set. > > LinuxAMD64JavaThreadPDAccess.java

Re: RFR (round 1), JDK-8214259: Implementation: JEP 189: Shenandoah: A Low-Pause Garbage Collector

Hi, On 11/28/18 3:24 PM, Roman Kennke wrote: Hi Per, Hi Roman, On 11/26/18 10:39 PM, Roman Kennke wrote: [...]    *) shared-serviceability   - The usual code to support another GC Just had a quick