webrev for hsail backend merging with new providers infrastructure

[Gilles Duboscq]

For this kind of scenario in general you would need to fork the VM and
change just that one option, I don't think there is support for this kind
of things in JUnit and its usually not trivial to do.

The jcstress and jmh tools (http://openjdk.java.net/projects/code-tools/)
need to do something like that for example.

-Gilles
On 7 Nov 2013 23:06, "Doug Simon" <doug.simon at oracle.com> wrote:

>
> On Nov 7, 2013, at 10:54 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
>
> > Doug --
> >
> > Sometimes we want to run a test with several different max heap sizes
> because it forces different types of Compressed Oops encoding, etc.  Can
> that type of change be handled by this scoped overriding of options? (I
> assume not).
>
> Unfortunately not. The scoped overriding mechanism is only supported for
> Graal options, not HotSpot options.
>
> -Doug
>
> > -----Original Message-----
> > From: Doug Simon [mailto:doug.simon at oracle.com]
> > Sent: Tuesday, November 05, 2013 8:06 AM
> > To: Deneau, Tom
> > Cc: graal-dev at openjdk.java.net
> > Subject: Re: webrev for hsail backend merging with new providers
> infrastructure
> >
> >
> > On Nov 4, 2013, at 6:19 PM, Doug Simon <doug.simon at oracle.com> wrote:
> >
> >>
> >> On Nov 4, 2013, at 5:27 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> >>
> >>> Hi Doug --
> >>>
> >>> Some of our java 8 based unit tests (which use lambdas) use these two
> libraries currently, but you're right we don't use them in the java 7 based
> tests yet.  If you want to remove them from the public mx/projects, go
> ahead.
> >>>
> >>> This points to a hole in our testing strategy which we've always been
> aware of.  We have written a number of java 8 style unit tests that we test
> locally here but that don't get exercised in the public repository.  We
> could of course add similar java 7 based unit tests and push them to public
> but we haven't done that work, and if graal is going to support 8 soon,
> there wouldn't be a need for that conversion work.
> >>
> >> Yes, I suggest to keep just running these tests locally until Graal has
> transitioned to 8.
> >>
> >>> On a related note, I think Vasanth mentioned that we run our unit
> tests locally here with the flags -G:+InlineEverything
>  -G:-RemoveNeverExecutedCode.   We need InlineEverything because we don't
> support HSAIL function calls yet.  Several test cases have a line like
> >>>     assumeTrue(aggressiveInliningEnabled());
> >>>
> >>> and of course these just get skipped if -G:+InlineEverything is not
> set.  Is it possible to get the hsail tests that get run at Oracle to use
> these two flags?
> >>
> >> We don't currently have infrastructure for running tests in a different
> VM instances based on required command line option settings. What we
> ideally want (in this case at least) is for options such as
> InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped
> manner (e.g., for individual compilations). Until we have support for this
> however, we'll have to rely on your testing setup to run these tests.
> >
> > There is now support for scoped overriding of options[1]. For example,
> in StaticNBodyCallTest:
> >
> >    @Test
> >    @Override
> >    public void test() throws Exception {
> >        Field f =
> GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode");
> >        f.setAccessible(true);
> >        OptionValue<?> removeNeverExecutedCode = (OptionValue<?>)
> f.get(null);
> >        try (OverrideScope s =
> OptionValue.override(GraalOptions.InlineEverything, true,
> removeNeverExecutedCode, false)) {
> >            assumeTrue(aggressiveInliningEnabled() ||
> canHandleHSAILMethodCalls());
> >            testGeneratedHsail();
> >        }
> >    }
> >
> >
> > [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231
> >
> > -Doug
> >
> >>> -----Original Message-----
> >>> From: Doug Simon [mailto:doug.simon at oracle.com]
> >>> Sent: Monday, November 04, 2013 9:30 AM
> >>> To: Deneau, Tom
> >>> Cc: graal-dev at openjdk.java.net
> >>> Subject: Re: webrev for hsail backend merging with new providers
> infrastructure
> >>>
> >>> Actually, one quick question: Do we really need the VECMATH and
> APACHELANG libraries declared in mx/projects[1]? None of the projects seem
> to use them.
> >>>
> >>> -Doug
> >>>
> >>> [1]
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html
> >>>
> >>> On Nov 1, 2013, at 11:54 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> >>>
> >>>> All --
> >>>>
> >>>> I have posted a small webrev to
> >>>>
> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/
> >>>>
> >>>> This is the result of our merge with the recent providers
> infrastructure.  Could you please look this over?
> >>>>
> >>>> Here is a brief summary:
> >>>>
> >>>>
> >>>> HSAILHotSpotForeignCallsProvider.java
> >>>> -------------------------------------
> >>>> . As noted in the comments,   we don't really support foreign calls
> yet,  yet we do get asked to handle ForeignCall nodes, and we want to
> generate dummy code for them.  We just support them all and lazily create
> dummy linkages here.  When we finally support foreign calls we will
> explicitly register the ones we want to support.
> >>>>
> >>>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java,
> HSAILControlFlow.java
> >>>>
> ----------------------------------------------------------------------------
> >>>> . This again is part of the dummy Foreign Call support.   Some less
> extensive ForeignCall support used to be in HSAILLIRGenerator.
> >>>>
> >>>> HSAILHotSpotReplacementsImpl.java
> >>>> ---------------------------------
> >>>> . This is another one of the providers in the new runtime
> infrastructure.  For both macro substitutions and method substitutions, we
> just delegate to the host substitution list.  This is a quick solution
> which allows things like Math.sqrt, and some of the Unsafe methods to work
> for HSAIL, similar to the way these substitutions worked before the
> providers change.  Eventually, we will explicitly list which substitutions
> we will support.
> >>>>
> >>>> HSAIL.java
> >>>> ----------
> >>>> . Not really part of the webrev infrastructure merge but since we're
> planning to limit the number of registers actually used by the graal
> compiler, it seemed appropriate to push this out.
> >>>>
> >>>> Tests
> >>>> -----
> >>>> . With the ForeignCall support above, some test cases that were
> marked as failing are now passing.
> >>>>
> >>>> KernelTester.java
> >>>> -----------------
> >>>> . Not really part of the webrev infrastructure merge but added a
> property to allow running the gpu code either first or second vs. the java
> code in our test cases.
> >>>>
> >>>>
> >>>> -- Tom Deneau
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>