RFR (XS) 8061467: Add UseLargePages to TestNUMAPageSize
Per Liden
per.liden at oracle.com
Tue Aug 21 05:54:32 UTC 2018
Hi JC,
To avoid this you can fetch the title from JIRA, which makes it harder
to get this wrong and easier to detect when you get it wrong. I use mq,
so when I want to set the title of the patch I do:
$ mref -b <bugnumber>
This is a script, which basically does this:
$ hg qrefresh -m "$(msymmary $BUGID)"
and msummary in turn looks like this:
#!/bin/bash
#
# Get JDK bug summary
#
if [ $# != 1 ]; then
echo "usage: msummary <bug-id>"
exit 1
fi
BUGID="$1"
URL="https://bugs.openjdk.java.net/rest/api/2/issue/JDK-$BUGID"
echo -n "$BUGID: "
curl -s $URL | python -c "import json,sys; obj=json.load(sys.stdin);
print obj['fields']['summary']"
echo "Reviewed-by: "
# End of file
Since it fetches the bug title for me it's pretty easy to notice if it
says something completely different from what I expected. Once the patch
has been reviewed, I go back (hg qrefresh -e) and update the Reviewed-by
line.
cheers,
Per
On 08/20/2018 04:45 PM, JC Beyler wrote:
> Arg.... Sorry about this. Am I missing a tool that double checks the
> number in the CR with what is in JBS?
>
> 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.
> Jc
>
> On Mon, Aug 20, 2018 at 2:01 AM Thomas Schatzl
> <thomas.schatzl at oracle.com <mailto:thomas.schatzl at oracle.com>> wrote:
>
> Hi JC,
>
> the changeset had a wrong CR number (8061467), and so the change has
> been pushed under that CR on Wednesday already.
>
> I will figure out how to handle the original CR (8063110).
>
> Thanks,
> Thomas
>
> On Tue, 2018-08-14 at 20:20 -0700, JC Beyler wrote:
> > Hi all,
> >
> > Here is the webrev with all the reviewers added:
> > http://cr.openjdk.java.net/~jcbeyler/8063110/webrev.03/
> >
> > Let me know if I can/should do anything else for this webrev.
> >
> > Thanks for all your help,
> > Jc
> >
> > On Mon, Aug 13, 2018 at 11:04 PM Per Liden <per.liden at oracle.com
> <mailto:per.liden at oracle.com>>
> > wrote:
> > > Hi,
> > >
> > > On 08/13/2018 06:22 PM, JC Beyler wrote:
> > > > Hi all,
> > > >
> > > > I added Per's fix into the webrev:
> > > > http://cr.openjdk.java.net/~jcbeyler/8063110/webrev.02/
> > > >
> > > > (I also put you Thomas as reviewer, I was not sure Per wanted to
> > > be put
> > > > as reviewer, let me know).
> > >
> > > Sure, you can put me as reviewer.
> > >
> > > /Per
> > >
> > > >
> > > > Not sure if you wanted to wait or not to push it but at least
> > > this
> > > > version would be the version that does not run with ZGC.
> > > >
> > > > Thanks for your help,
> > > > Jc
> > > >
> > > > On Mon, Aug 13, 2018 at 5:54 AM Per Liden
> <per.liden at oracle.com <mailto:per.liden at oracle.com>
> > > > <mailto:per.liden at oracle.com <mailto:per.liden at oracle.com>>>
> wrote:
> > > >
> > > > On 08/13/2018 11:41 AM, Thomas Schatzl wrote:
> > > > > Hi,
> > > > >
> > > > > while testing this patch before push it seems like the
> > > problem
> > > > is ZGC
> > > > > which does not fall back to using small pages (which I did
> > > not know).
> > > > >
> > > > >> [5.048s][error][gc,init] Not enough space available on
> > > the backing
> > > > > filesystem to hold the current max
> > > > >> [5.048s][error][gc,init] Java heap size (128M).
> > > Forcefully lowering
> > > > > max Java heap size to 0M (0%).
> > > > >> Error occurred during initialization of VM
> > > > >> java.lang.OutOfMemoryError: Java heap too small
> > > > >
> > > > > I will hold off pushing this before this issue has been
> > > resolved
> > > > in one
> > > > > way or the other.
> > > >
> > > > UseNUMA is enabled by default in ZGC, so it's tested
> > > frequently anyway.
> > > > I guess the easiest solution is to just not run this test
> > > when ZGC is
> > > > enabled, something like this:
> > > >
> > > > diff --git a/test/hotspot/jtreg/gc/TestNUMAPageSize.java
> > > > b/test/hotspot/jtreg/gc/TestNUMAPageSize.java
> > > > --- a/test/hotspot/jtreg/gc/TestNUMAPageSize.java
> > > > +++ b/test/hotspot/jtreg/gc/TestNUMAPageSize.java
> > > > @@ -27,7 +27,8 @@
> > > > * @summary Make sure that start up with NUMA support does
> > > not cause
> > > > problems.
> > > > * @bug 8061467
> > > > * @requires vm.opt.AggressiveOpts != true
> > > > - * @run main/othervm -Xmx128m -XX:+UseNUMA TestNUMAPageSize
> > > > + * @requires vm.gc != "Z"
> > > > + * @run main/othervm -Xmx128m -XX:+UseNUMA
> > > -XX:+UseLargePages
> > > > TestNUMAPageSize
> > > > */
> > > >
> > > > public class TestNUMAPageSize {
> > > >
> > > >
> > > > cheers,
> > > > Per
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > > Thomas
> > > > >
> > > > > On Mon, 2018-08-13 at 10:23 +0200, Thomas Schatzl wrote:
> > > > >> Hi,
> > > > >>
> > > > >> On Mon, 2018-08-13 at 09:58 +0200, Per Liden wrote:
> > > > >>> Hmm, I suspect this might fail on many Linux systems,
> > > since it
> > > > >>> might require configuring the huge page pool with enough
> > > pages.
> > > > >>
> > > > >> from my understanding -XX:+UseLargePages will just
> > > give some
> > > > >> warnings
> > > > >> at startup if it can not allocate pages. It will not
> > > fail.
> > > > >>
> > > > >> Assuming that the intent is to check whether when trying
> > > to use
> > > > large
> > > > >> pages (and the machine is properly configured), does not
> > > in any way
> > > > >> make the VM crash, the warnings can be ignored.
> > > > >>
> > > > >> I am not aware there is a way to run tests on machines
> > > only that
> > > > have
> > > > >> the property "properly configured large pages" at this
> > > time.
> > > > >>
> > > > >> Thanks,
> > > > >> Thomas
> > > > >>
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Thanks,
> > > > Jc
> >
> >
>
>
>
> --
>
> Thanks,
> Jc
More information about the hotspot-gc-dev
mailing list