[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Re: RFR: 8231296: ZGC: vmTestbase/nsk/jvmti/Allocate/alloc001/ fails
From:       Per Liden <per.liden () oracle ! com>
Date:       2019-09-30 13:18:39
Message-ID: 13de14f2-a6c0-1eaf-56bd-ffff3d5f2da7 () oracle ! com
[Download RAW message or body]

Hi Igor,

On 9/28/19 6:47 PM, Igor Ignatyev wrote:
> Hi Per,
> 
> if you decide to go w/ @requires, I'd encourage you to also put an explaining \
> comment in the test descriptor using jtreg's tag @comment, so at least it will be \
> easier for future readers to understand why the test can't / shouldn't be run w/ \
> ZGC.

Will do!

cheers,
Per

> 
> Thanks,
> -- Igor
> 
> > On Sep 27, 2019, at 6:43 AM, Daniel D. Daugherty <daniel.daugherty@oracle.com> \
> > wrote: 
> > Thanks for the background info. I think that's a more convincing
> > explanation and I'm okay with the change as is.
> > 
> > Please add a comment to JDK-8231552 making it clear that
> > vmTestbase/nsk/jvmti/Allocate/alloc001 should be reenabled
> > if/when the bug^H^H^H RFE is fixed. :-)
> > 
> > Dan
> > 
> > 
> > On 9/27/19 9:39 AM, Per Liden wrote:
> > > Hi Dan,
> > > 
> > > The background here is that ZGC previously (by design) required a certain \
> > > amount of address space to run. So it was a deliberate decision to not support \
> > > RLIMIT_AS. However, as ZGC's design have progressed, we're now in a position \
> > > where we could reconsider this (which is why the RFE was filed). In _theory_, \
> > > we could come to the conclusion that we still don't want to support this and \
> > > just close the RFE as Won't fix. That's (very) unlikely, but I think that line \
> > > of thinking shows why sticking this in the problem list is the wrong thing to \
> > > do here, because that problem list entry would then potentially stay there \
> > > forever. Until that RFE is pushed, that test should not even attempt to test it \
> > > with ZGC, because it's not a supported use case. 
> > > Anyways... ;)
> > > 
> > > cheers,
> > > Per
> > > 
> > > On 9/27/19 2:48 PM, Daniel D. Daugherty wrote:
> > > [...]
> > > > 
> > > > In your code review invite you say this:
> > > > 
> > > > > The root problem is that ZGC doesn't properly respect address space \
> > > > > limitations (RLIMIT_AS).
> > > > 
> > > > To me that says the current behavior is temporary and then you say this:
> > > > 
> > > > > This test will be re-enabled again as part of fixing \
> > > > > https://bugs.openjdk.java.net/browse/JDK-8231552
> > > > 
> > > > and that confirms that the issue is planned to be resolved. I'm not
> > > > sure that I agree that 8231552 is an RFE rather than a bug, but that's
> > > > not the point here...
> > > > 
> > > > To me, both of those sentences would lead to a ProblemListing
> > > > and not an @requires. Your call...
> > > > 
> > > > Dan
> > > > 
> > > > 
> > > > > 
> > > > > cheers,
> > > > > Per
> > > > > 
> > > > > > > 
> > > > > > > cheers,
> > > > > > > Per
> > > > > > > 
> > > > > > > > On 9/26/19 10:58 PM, Igor Ignatyev wrote:
> > > > > > > > Hi Per,
> > > > > > > > wouldn't it be better to put this test into zgc-specific problem list \
> > > > > > > > (test/hotspot/jtreg/ProblemList-zgc.txt)? Thanks,
> > > > > > > > -- Igor
> > > > > > > > > > On Sep 26, 2019, at 1:39 PM, Per Liden <per.liden@oracle.com> \
> > > > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > Please review this one-liner to disable \
> > > > > > > > > vmTestbase/nsk/jvmti/Allocate/alloc001 when using ZGC. The root \
> > > > > > > > > problem is that ZGC doesn't properly respect address space \
> > > > > > > > > limitations (RLIMIT_AS). This test will be re-enabled again as part \
> > > > > > > > > of fixing https://bugs.openjdk.java.net/browse/JDK-8231552 
> > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231296
> > > > > > > > > Webrev: http://cr.openjdk.java.net/~pliden/8231296/webrev.0
> > > > > > > > > 
> > > > > > > > > /Per
> > > > > > 
> > > > 
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]