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

2018-12-02 Thread Jini George
Hi Roman, A few comments on the SA changes: ==> Could you please add the following lines in src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java from line 1120 onwards to avoid the "[Unknown generation]" message with hsdb while displaying the Stack Memory for a mutator thread ? els

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

2018-12-02 Thread David Holmes
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 seems to dominant the test and obscure the original

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

2018-12-02 Thread John Rose
On Nov 30, 2018, at 3:22 PM, coleen.phillim...@oracle.com wrote: > > Hi, I looked at the runtime changes, which are very few, since you've > upstreamed most of the runtime dependent changes already. > They look good to me. "since you've upstreamed most of the runtime dependent changes already"

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

2018-12-02 Thread Jini George
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 the presence of the hprof file and throw an exception if the

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

2018-12-02 Thread David Holmes
On 30/11/2018 8:40 pm, Per Liden wrote: Hi, On 11/30/18 10:55 AM, Roman Kennke wrote: Hi Per, Thanks for taking time to look at this! We will take care of all the issues you mentioned. Regarding the flags, I think they are useful as they are now. Shenandoah can be run in 'passive' mode, wh

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

2018-12-02 Thread Vladimir Kozlov
Yes, compiler changes reviewed. Vladimir On 12/2/18 10:15 AM, Roman Kennke wrote: Hello Vladimir, Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp ? Why not include only shenandoahSupport.hpp when new nodes are defined? I discussed this with my team. shenandoahBarrier

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

2018-12-02 Thread Roman Kennke
>> Hello Vladimir, >> >>> Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp >>> ? Why not include only shenandoahSupport.hpp when new nodes are defined? >> >> I discussed this with my team. shenandoahBarrierSetC2.hpp is supposed to >> be the entry point for external C2 code. N

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

2018-12-02 Thread Vladimir Kozlov
On 12/2/18 8:55 AM, Roman Kennke wrote: Hello Vladimir, Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp ? Why not include only shenandoahSupport.hpp when new nodes are defined? I discussed this with my team. shenandoahBarrierSetC2.hpp is supposed to be the entry point

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

2018-12-02 Thread Roman Kennke
Hello Vladimir, > Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp > ? Why not include only shenandoahSupport.hpp when new nodes are defined? I discussed this with my team. shenandoahBarrierSetC2.hpp is supposed to be the entry point for external C2 code. No C2 code is supp

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

2018-12-02 Thread Roman Kennke
Hi Vladimir, > Much better. Thanks! > Why you need to include shenandoahBarrierSetC2.hpp in /opto/classes.cpp > ? Why not include only shenandoahSupport.hpp when new nodes are defined? For no particular reason, I guess. I'll fix it in next round. > I think it is fine to not use #ifdef in loopo