Okra loader needs to check OS support

[Deneau, Tom]

Doug --

OK, The new 1.6 jar files are up there now.

One other related thought on junit tests...
For the hsail junit tests to run the Hotspot flags -XX:+UseHSAILSimulatr and the
recently added -XX:+GPUOffload need to be set.  If these were
graal flags we could cover them with scoped options but...

Should we design some sort of CompilerToVM or CompilerToGPU call that would allow
a junit test to adjust certain Hotspot Global flags for the length of the test?
Or will your gate procedures specify the necessary Hotspot flags?

-- Tom


> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com]
> Sent: Saturday, January 25, 2014 2:08 AM
> To: Deneau, Tom
> Subject: Re: Okra loader needs to check OS support
> 
> No. If you just upload the new jars and let me know, I will make the
> projects file change and push it.
> 
> Sent from my iPhone
> 
> > On Jan 25, 2014, at 1:22 AM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> >
> > Doug --
> >
> > Do you want an actual webrev for the projects file change?
> >
> > -- Tom
> >
> >> -----Original Message-----
> >> From: Doug Simon [mailto:doug.simon at oracle.com]
> >> Sent: Friday, January 24, 2014 6:10 PM
> >> To: Deneau, Tom
> >> Cc: graal-dev at openjdk.java.net
> >> Subject: Re: Okra loader needs to check OS support
> >>
> >> Unfortunately, you need to update the version number (and hence the
> jar
> >> files and projects file) for this kind of change as mx does not do a
> >> time stamp or file size check on downloaded libs. The only
> alternative
> >> is to use this list to tell everyone to delete the out of date jar
> >> files.
> >>
> >> Sent from my iPhone
> >>
> >>>> On Jan 24, 2014, at 10:42 PM, "Deneau, Tom" <tom.deneau at amd.com>
> >>> wrote:
> >>>
> >>> Doug --
> >>>
> >>> OK new jar files with this fix should be up there now.
> >>> I didn't change the version number so mx/projects doesn't need to
> >> change.
> >>>
> >>> -- Tom
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Doug Simon [mailto:doug.simon at oracle.com]
> >>>> Sent: Friday, January 24, 2014 3:27 PM
> >>>> To: Deneau, Tom
> >>>> Cc: graal-dev at openjdk.java.net
> >>>> Subject: Re: Okra loader needs to check OS support
> >>>>
> >>>>
> >>>>
> >>>> Sent from my iPhone
> >>>>
> >>>>> On Jan 24, 2014, at 8:21 PM, "Deneau, Tom" <tom.deneau at amd.com>
> >> wrote:
> >>>>>
> >>>>> Doug --
> >>>>>
> >>>>> I'll get out an update today. I didn't know this was a gate
> >>>> environment.
> >>>>> As you know, the hsail simulator itself has never been ported to
> >> Mac.
> >>>>>
> >>>>> So on a Mac you want this to work the way things used to work on
> >>>> linux,
> >>>>> basically skipping all the hsail tests, is that correct?
> >>>>
> >>>> Yes, that would be great.
> >>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
> >>>>>> Sent: Friday, January 24, 2014 12:27 PM
> >>>>>> To: Deneau, Tom
> >>>>>> Cc: graal-dev at openjdk.java.net
> >>>>>> Subject: Okra loader needs to check OS support
> >>>>>>
> >>>>>> Hi Tom,
> >>>>>>
> >>>>>> The new Okra library loading mechanism breaks the unit tests on a
> >>>> Mac:
> >>>>>>
> >>>>>> $ mx --vm server unittest LongNegTest JUnit version 4.8 .E
> >>>>>> Time: 2.377
> >>>>>> There was 1 failure:
> >>>>>> 1) test(com.oracle.graal.compiler.hsail.test.LongNegTest)
> >>>>>> java.lang.ExceptionInInitializerError
> >>>>>>  at com.amd.okra.OkraUtil.testOkraLibExists(OkraUtil.java:61)
> >>>>>>  at com.amd.okra.OkraUtil.<clinit>(OkraUtil.java:51)
> >>>>>>  at
> >>>>
> com.oracle.graal.compiler.hsail.test.infra.KernelTester.<init>(Kernel
> >>>> Tes
> >>>>>> ter.java:118)
> >>>>>>  at
> >>>>
> com.oracle.graal.compiler.hsail.test.infra.GraalKernelTester.<init>(G
> >>>> raa
> >>>>>> lKernelTester.java:45)
> >>>>>>  at
> >>>>
> com.oracle.graal.compiler.hsail.test.LongNegTest.<init>(LongNegTest.j
> >>>> ava
> >>>>>> :32)
> >>>>>>  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> >>>>>> Method)
> >>>>>>  at
> >>>>
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
> >>>> orA
> >>>>>> ccessorImpl.java:62)
> >>>>>>  at
> >>>>
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
> >>>> ons
> >>>>>> tructorAccessorImpl.java:45)
> >>>>>>  at
> >>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:408)
> >>>>>>  at
> >>>>
> org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassR
> >>>> unn
> >>>>>> er.java:202)
> >>>>>>  at
> >>>>
> org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUn
> >>>> it4
> >>>>>> ClassRunner.java:251)
> >>>>>>  at
> >>>>
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCal
> >>>> lab
> >>>>>> le.java:15)
> >>>>>>  at
> >>>>
> org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4Class
> >>>> Run
> >>>>>> ner.java:248)
> >>>>>>  at
> >>>>
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
> >>>> ner
> >>>>>> .java:76)
> >>>>>>  at
> >>>>
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRun
> >>>> ner
> >>>>>> .java:50)
> >>>>>>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> >>>>>>  at
> >>>>>> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> >>>>>>  at
> >>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> >>>>>>  at
> >>>>>> org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> >>>>>>  at
> >>>>>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> >>>>>>  at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> >>>>>>  at org.junit.runners.Suite.runChild(Suite.java:128)
> >>>>>>  at org.junit.runners.Suite.runChild(Suite.java:24)
> >>>>>>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> >>>>>>  at
> >>>>>> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> >>>>>>  at
> >>>>>> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> >>>>>>  at
> >>>>>> org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> >>>>>>  at
> >>>>>> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> >>>>>>  at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> >>>>>>  at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> >>>>>>  at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
> >>>>>>  at org.junit.runner.JUnitCore.run(JUnitCore.java:117)
> >>>>>>  at org.junit.runner.JUnitCore.runMain(JUnitCore.java:98)
> >>>>>>  at org.junit.runner.JUnitCore.runMainAndExit(JUnitCore.java:53)
> >>>>>>  at org.junit.runner.JUnitCore.main(JUnitCore.java:45)
> >>>>>> Caused by: java.lang.RuntimeException: unable to load
> >>>>>> libokra_x86_64.dylib, java.lang.UnsatisfiedLinkError: Can't load
> >>>>>> library:
> >>>>
> /var/folders/d_/fn0kjn111nsc60w4vfy38fgr0026wn/T/okraresource.dir_656
> >>>> 902
> >>>>>> 6372617119677/libokra_x86_64.dylib
> >>>>>>  at
> >> com.amd.okra.OkraContext.loadOkraNativeLibrary(OkraContext.java:140)
> >>>>>>  at com.amd.okra.OkraContext.<clinit>(OkraContext.java:69)
> >>>>>>  ... 35 more
> >>>>>>
> >>>>>> FAILURES!!!
> >>>>>> Tests run: 1,  Failures: 1
> >>>>>>
> >>>>>>
> >>>>>> Can you please fix
> com.amd.okra.OkraContext.loadOkraNativeLibrary()
> >>>> so
> >>>>>> that it only tries to load the library if on Linux.
> >>>>>>
> >>>>>> This will require an update to the Okra jar files.
> >>>>>>
> >>>>>> -Doug
> >
> >