<div dir="ltr">Arg.... Sorry about this. Am I missing a tool that double checks the number in the CR with what is in JBS?<div><br></div><div>It is error prone but I've tried to be careful (and failed miserably it seems). I'll double my double checking for it and can only apologize again profusely.</div><div>Jc</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 20, 2018 at 2:01 AM Thomas Schatzl <<a href="mailto:thomas.schatzl@oracle.com">thomas.schatzl@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi JC,<br>
<br>
the changeset had a wrong CR number (8061467), and so the change has<br>
been pushed under that CR on Wednesday already.<br>
<br>
I will figure out how to handle the original CR (8063110).<br>
<br>
Thanks,<br>
Thomas<br>
<br>
On Tue, 2018-08-14 at 20:20 -0700, JC Beyler wrote:<br>
> Hi all,<br>
> <br>
> Here is the webrev with all the reviewers added:<br>
> <a href="http://cr.openjdk.java.net/~jcbeyler/8063110/webrev.03/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~jcbeyler/8063110/webrev.03/</a><br>
> <br>
> Let me know if I can/should do anything else for this webrev.<br>
> <br>
> Thanks for all your help,<br>
> Jc<br>
> <br>
> On Mon, Aug 13, 2018 at 11:04 PM Per Liden <<a href="mailto:per.liden@oracle.com" target="_blank">per.liden@oracle.com</a>><br>
> wrote:<br>
> > Hi,<br>
> > <br>
> > On 08/13/2018 06:22 PM, JC Beyler wrote:<br>
> > > Hi all,<br>
> > > <br>
> > > I added Per's fix into the webrev:<br>
> > > <a href="http://cr.openjdk.java.net/~jcbeyler/8063110/webrev.02/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~jcbeyler/8063110/webrev.02/</a><br>
> > > <br>
> > > (I also put you Thomas as reviewer, I was not sure Per wanted to<br>
> > be put <br>
> > > as reviewer, let me know).<br>
> > <br>
> > Sure, you can put me as reviewer.<br>
> > <br>
> > /Per<br>
> > <br>
> > > <br>
> > > Not sure if you wanted to wait or not to push it but at least<br>
> > this <br>
> > > version would be the version that does not run with ZGC.<br>
> > > <br>
> > > Thanks for your help,<br>
> > > Jc<br>
> > > <br>
> > > On Mon, Aug 13, 2018 at 5:54 AM Per Liden <<a href="mailto:per.liden@oracle.com" target="_blank">per.liden@oracle.com</a> <br>
> > > <mailto:<a href="mailto:per.liden@oracle.com" target="_blank">per.liden@oracle.com</a>>> wrote:<br>
> > > <br>
> > > On 08/13/2018 11:41 AM, Thomas Schatzl wrote:<br>
> > > > Hi,<br>
> > > ><br>
> > > > while testing this patch before push it seems like the<br>
> > problem<br>
> > > is ZGC<br>
> > > > which does not fall back to using small pages (which I did<br>
> > not know).<br>
> > > ><br>
> > > >> [5.048s][error][gc,init] Not enough space available on<br>
> > the backing<br>
> > > > filesystem to hold the current max<br>
> > > >> [5.048s][error][gc,init] Java heap size (128M).<br>
> > Forcefully lowering<br>
> > > > max Java heap size to 0M (0%).<br>
> > > >> Error occurred during initialization of VM<br>
> > > >> java.lang.OutOfMemoryError: Java heap too small<br>
> > > ><br>
> > > > I will hold off pushing this before this issue has been<br>
> > resolved<br>
> > > in one<br>
> > > > way or the other.<br>
> > > <br>
> > > UseNUMA is enabled by default in ZGC, so it's tested<br>
> > frequently anyway.<br>
> > > I guess the easiest solution is to just not run this test<br>
> > when ZGC is<br>
> > > enabled, something like this:<br>
> > > <br>
> > > diff --git a/test/hotspot/jtreg/gc/TestNUMAPageSize.java<br>
> > > b/test/hotspot/jtreg/gc/TestNUMAPageSize.java<br>
> > > --- a/test/hotspot/jtreg/gc/TestNUMAPageSize.java<br>
> > > +++ b/test/hotspot/jtreg/gc/TestNUMAPageSize.java<br>
> > > @@ -27,7 +27,8 @@<br>
> > > * @summary Make sure that start up with NUMA support does<br>
> > not cause<br>
> > > problems.<br>
> > > * @bug 8061467<br>
> > > * @requires vm.opt.AggressiveOpts != true<br>
> > > - * @run main/othervm -Xmx128m -XX:+UseNUMA TestNUMAPageSize<br>
> > > + * @requires vm.gc != "Z"<br>
> > > + * @run main/othervm -Xmx128m -XX:+UseNUMA<br>
> > -XX:+UseLargePages<br>
> > > TestNUMAPageSize<br>
> > > */<br>
> > > <br>
> > > public class TestNUMAPageSize {<br>
> > > <br>
> > > <br>
> > > cheers,<br>
> > > Per<br>
> > > <br>
> > > <br>
> > > ><br>
> > > > Thanks,<br>
> > > > Thomas<br>
> > > ><br>
> > > > On Mon, 2018-08-13 at 10:23 +0200, Thomas Schatzl wrote:<br>
> > > >> Hi,<br>
> > > >><br>
> > > >> On Mon, 2018-08-13 at 09:58 +0200, Per Liden wrote:<br>
> > > >>> Hmm, I suspect this might fail on many Linux systems,<br>
> > since it<br>
> > > >>> might require configuring the huge page pool with enough<br>
> > pages.<br>
> > > >><br>
> > > >> from my understanding -XX:+UseLargePages will just<br>
> > give some<br>
> > > >> warnings<br>
> > > >> at startup if it can not allocate pages. It will not<br>
> > fail.<br>
> > > >><br>
> > > >> Assuming that the intent is to check whether when trying<br>
> > to use<br>
> > > large<br>
> > > >> pages (and the machine is properly configured), does not<br>
> > in any way<br>
> > > >> make the VM crash, the warnings can be ignored.<br>
> > > >><br>
> > > >> I am not aware there is a way to run tests on machines<br>
> > only that<br>
> > > have<br>
> > > >> the property "properly configured large pages" at this<br>
> > time.<br>
> > > >><br>
> > > >> Thanks,<br>
> > > >> Thomas<br>
> > > >><br>
> > > ><br>
> > > <br>
> > > <br>
> > > <br>
> > > -- <br>
> > > <br>
> > > Thanks,<br>
> > > Jc<br>
> <br>
> <br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div>Thanks,<div>Jc</div></div></div>