graal-dev Digest, Vol 21, Issue 15
Mozumder, Monir
Monir.Mozumder at amd.com
Fri Nov 8 15:58:03 PST 2013
Thanks Tom,
I will give it a shot. I believe I did the " mx build" as per the graal wiki page.
Bests,
-Monir
-----Original Message-----
From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of graal-dev-request at openjdk.java.net
Sent: Friday, November 08, 2013 3:52 PM
To: graal-dev at openjdk.java.net
Subject: graal-dev Digest, Vol 21, Issue 15
Send graal-dev mailing list submissions to
graal-dev at openjdk.java.net
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.openjdk.java.net/mailman/listinfo/graal-dev
or, via email, send a message with subject or body 'help' to
graal-dev-request at openjdk.java.net
You can reach the person managing the list at
graal-dev-owner at openjdk.java.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of graal-dev digest..."
Today's Topics:
1. Error compiling example code for HSAIL generation
(Mozumder, Monir)
2. RE: Error compiling example code for HSAIL generation
(Mozumder, Monir)
3. scoped overriding of graal options (Deneau, Tom)
4. RE: Error compiling example code for HSAIL generation
(Deneau, Tom)
----------------------------------------------------------------------
Message: 1
Date: Fri, 8 Nov 2013 22:17:00 +0000
From: "Mozumder, Monir" <Monir.Mozumder at amd.com>
Subject: Error compiling example code for HSAIL generation
To: "graal-dev at openjdk.java.net" <graal-dev at openjdk.java.net>
Message-ID:
<FEFA2B6480B5BA42A32321F1A0399EA8301C74DC at SATLEXDAG02.amd.com>
Content-Type: text/plain; charset="us-ascii"
I am trying to compile an example code from this page: http://www.tuicool.com/articles/eEFRR3?jdfwkey=d741l1
~/dev/sumatra/test$ cat IntSquaredTest.java
package com.oracle.graal.compiler.hsail.test;
import org.junit.Test;
import java.util.logging.*;
public class IntSquaredTest extends StaticMethodTwoIntArrays {
public static void run(int[] out, int[] in, int gid) {
out[gid] = in[gid] * in[gid];
}
@Test
public void test() {
super.testGeneratedHsail();
}
}
I see errors when trying to do the compilation step: mx --vm server unittest hsail.test.IntSquaredTest.
~/dev/sumatra/test$ mx --vm server unittest hsail.test.IntSquaredTest # # A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as:
# /home/munir/dev/sumatra/test/hs_err_pid12108.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
See below for my setup details. I am also providing some snippets from hs_err_pid12108.log . Any ideas?
Bests,
-Monir
~/dev/sumatra/test$ which javac
/home/munir/dev/sumatra/simulator/build_linux/grail/profuct/bin/javac
~/dev/sumatra/test$ java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b112) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b54, mixed mode)
============================== excerpts from hs_err_pid12108.log
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144 # fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112) # Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x00007f76d800d800): JavaThread "main" [_thread_in_native, id=12109, stack(0x00007f76de85b000,0x00007f76de95c000)]
Stack: [0x00007f76de85b000,0x00007f76de95c000], sp=0x00007f76de95a860, free space=1022k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x96f8b6] VMError::report_and_die()+0x166 V [libjvm.so+0x46c773] report_fatal(char const*, int, char const*)+0x53 V [libjvm.so+0x555439] compute_offset(int&, Klass*, char const*, char const*, bool)+0x2e9 V [libjvm.so+0x555f13] graal_compute_offsets()+0xa93 V [libjvm.so+0x5461b6] GraalCompiler::initialize()+0x436 V [libjvm.so+0x5f65ee] JNI_CreateJavaVM+0xde C [libjli.so+0x703e] JavaMain+0x9e
--------------- P R O C E S S ---------------
~
~
~
------------------------------
Message: 2
Date: Fri, 8 Nov 2013 22:26:21 +0000
From: "Mozumder, Monir" <Monir.Mozumder at amd.com>
Subject: RE: Error compiling example code for HSAIL generation
To: "graal-dev at openjdk.java.net" <graal-dev at openjdk.java.net>
Message-ID:
<FEFA2B6480B5BA42A32321F1A0399EA8301C74EE at SATLEXDAG02.amd.com>
Content-Type: text/plain; charset="us-ascii"
More setup details:
graal setup: done as per https://wiki.openjdk.java.net/display/Graal/Instructions (hg clone http://hg.openjdk.java.net/graal/graal)
HSA simulator setup: https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator (installed all 3 components)
Though the HAS simulator setup does not matter here, I am mentioning it for giving the environment. Upon setting up grail, I pointed JAVA_HOME to be from its product folder. All test cases from simulator and grail seem to work fine.
Bests,
-Monir
------------------------------
Message: 3
Date: Fri, 8 Nov 2013 22:44:12 +0000
From: "Deneau, Tom" <tom.deneau at amd.com>
Subject: scoped overriding of graal options
To: Doug Simon <doug.simon at oracle.com>
Cc: "graal-dev at openjdk.java.net" <graal-dev at openjdk.java.net>
Message-ID:
<BC97738F8E7C8742BABED7F06FB9DF91532421F6 at SATLEXDAG01.amd.com>
Content-Type: text/plain; charset="us-ascii"
Doug --
OK, this still looks very useful.
One small complaint, I did a println of the overridden option while debugging, and it just showed the original value from the command line.
Maybe toString could show both the original value and the overridden value (if different)
-- Tom
-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com]
Sent: Thursday, November 07, 2013 4:05 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: webrev for hsail backend merging with new providers infrastructure
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
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
------------------------------
Message: 4
Date: Fri, 8 Nov 2013 23:51:49 +0000
From: "Deneau, Tom" <tom.deneau at amd.com>
Subject: RE: Error compiling example code for HSAIL generation
To: "Mozumder, Monir" <Monir.Mozumder at amd.com>,
"graal-dev at openjdk.java.net" <graal-dev at openjdk.java.net>
Message-ID:
<BC97738F8E7C8742BABED7F06FB9DF9153242245 at SATLEXDAG01.amd.com>
Content-Type: text/plain; charset="us-ascii"
Monir --
I just did a download of jdk8-b112 and built a clone of graal and the test below worked for me.
I built graal with "mx --vm server --vmbuild product build". Is that what you used?
-- Tom
-----Original Message-----
From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev-bounces at openjdk.java.net] On Behalf Of Mozumder, Monir
Sent: Friday, November 08, 2013 4:17 PM
To: graal-dev at openjdk.java.net
Subject: Error compiling example code for HSAIL generation
I am trying to compile an example code from this page: http://www.tuicool.com/articles/eEFRR3?jdfwkey=d741l1
~/dev/sumatra/test$ cat IntSquaredTest.java
package com.oracle.graal.compiler.hsail.test;
import org.junit.Test;
import java.util.logging.*;
public class IntSquaredTest extends StaticMethodTwoIntArrays {
public static void run(int[] out, int[] in, int gid) {
out[gid] = in[gid] * in[gid];
}
@Test
public void test() {
super.testGeneratedHsail();
}
}
I see errors when trying to do the compilation step: mx --vm server unittest hsail.test.IntSquaredTest.
~/dev/sumatra/test$ mx --vm server unittest hsail.test.IntSquaredTest
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144
# fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/munir/dev/sumatra/test/hs_err_pid12108.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
See below for my setup details. I am also providing some snippets from hs_err_pid12108.log . Any ideas?
Bests,
-Monir
~/dev/sumatra/test$ which javac
/home/munir/dev/sumatra/simulator/build_linux/grail/profuct/bin/javac
~/dev/sumatra/test$ java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b112)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b54, mixed mode)
============================== excerpts from hs_err_pid12108.log
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (graalJavaAccess.cpp:42), pid=12108, tid=140148517222144
# fatal error: Invalid layout of registerRefMap at com.oracle.graal.api.code.DebugInfo
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b112) (build 1.8.0-ea-b112)
# Java VM: OpenJDK 64-Bit Server VM (25.0-b53-internal mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
--------------- T H R E A D ---------------
Current thread (0x00007f76d800d800): JavaThread "main" [_thread_in_native, id=12109, stack(0x00007f76de85b000,0x00007f76de95c000)]
Stack: [0x00007f76de85b000,0x00007f76de95c000], sp=0x00007f76de95a860, free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x96f8b6] VMError::report_and_die()+0x166
V [libjvm.so+0x46c773] report_fatal(char const*, int, char const*)+0x53
V [libjvm.so+0x555439] compute_offset(int&, Klass*, char const*, char const*, bool)+0x2e9
V [libjvm.so+0x555f13] graal_compute_offsets()+0xa93
V [libjvm.so+0x5461b6] GraalCompiler::initialize()+0x436
V [libjvm.so+0x5f65ee] JNI_CreateJavaVM+0xde
C [libjli.so+0x703e] JavaMain+0x9e
--------------- P R O C E S S ---------------
~
~
~
End of graal-dev Digest, Vol 21, Issue 15
*****************************************
More information about the graal-dev
mailing list