From Vasanth.Venkatachalam at amd.com Sun Dec 1 09:52:29 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Sun, 1 Dec 2013 17:52:29 +0000 Subject: questions about implementing intrinsics Message-ID: <5DD1503F815BD14889DC81D28643E3A75788ED51@SATLEXDAG02.amd.com> Doug or others- I'm trying to understand the process of implementing intrinsics (for the HSAIL backend) for some java.lang.Math routines that x86 doesn't necessarily intrinsify. As a toy example, I'm trying to implement my own intrinsic for Math.sqrt( ). Below are the steps I tried to take to hack a small prototype. Can you tell me whether I'm on the right track? I also had some questions below. 1) Define a package com.oracle.graal.replacements.hsail. 2) In the above package, define a class MathSubstitutionsHSAIL.java (similar to MathSubstitutionsX86) which contains substitutions for methods of the java.lang.Math class. I currently just have a substitution for Math.sqrt( ), but I could list substitutions here for other java.lang.Math routines that aren't in MathSubstitutionsX86. 3) Define a MathIntrinsicHSAILNode (under com.oracle.graal.replacements.hsail) which is similar to the MathIntrinsicNode but defines the operations that will be treated as intrinsics in the HSAIL backend. a. The substitutions in MathSubsitutionsHSAIL.java will call the MathIntrinsicHSAILNode.compute( ) routine for the math operations we are interested in intrinsifying. 4) Define a ReplacementsProvider called GraalHSAILMethodSubstitutions.java under com.oracle.graal.replacements.hsail/ . Implement the registerReplacements method( ) to register specific replacements with the compiler. My version of registerReplacements() just calls replacements.registerSubstitutions(MathSubstitutionsHSAIL.class). 5) Override HSAILHotspotBackend.completeInitialization( ) to call ReplacementsProvider.registerReplacements( ) similar to the way it's being done in the host backend, so that the substitutions I have defined get registered in the compiler. Some questions: a) The part that's fuzzy to me is step 5). VMToCompilerImpl.startCompiler() is calling completeInitialization( ) for the host backend (x86) and for each of the GPU target backends (including HSAIL). The completeInitialization( ) routine in the host backend is calling ReplacementsProvider.registerReplacements() to register all the x86 replacements. Am I supposed to override HSAILHotSpotBackend.completeInitialization( ) to do something similar so that the HSAIL substitutions get registered? Can you explain this process a bit? I'm not clear on who is supposed to call ReplacementsProvider.registerReplacements() to register my intrinsics. b) From looking at VMToCompilerImpl.startCompiler(), it appears that the substitutions used in the host backend (x86) as well as substitutions used in the GPU target backend (HSAIL) will all get registered with the compiler if I take the approach in a) above. How can I ensure that my math intrinsics are the ones that get used instead of the host backend intrinsics? In particular, how do I ensure that my intrinsic for Math.sqrt is what gets used (instead of the host backend's version) when I'm generating HSAIL code? Vasanth From doug.simon at oracle.com Mon Dec 2 02:16:11 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 2 Dec 2013 11:16:11 +0100 Subject: questions about implementing intrinsics In-Reply-To: <5DD1503F815BD14889DC81D28643E3A75788ED51@SATLEXDAG02.amd.com> References: <5DD1503F815BD14889DC81D28643E3A75788ED51@SATLEXDAG02.amd.com> Message-ID: <466E9D24-CC6F-405F-A836-F82048698D90@oracle.com> On Dec 1, 2013, at 6:52 PM, Venkatachalam, Vasanth wrote: > Doug or others- > > I'm trying to understand the process of implementing intrinsics (for the HSAIL backend) for some java.lang.Math routines that x86 doesn't necessarily intrinsify. > As a toy example, I'm trying to implement my own intrinsic for Math.sqrt( ). Below are the steps I tried to take to hack a small prototype. > Can you tell me whether I'm on the right track? I also had some questions below. > > > 1) Define a package com.oracle.graal.replacements.hsail. > > 2) In the above package, define a class MathSubstitutionsHSAIL.java (similar to MathSubstitutionsX86) which contains substitutions for methods of the java.lang.Math class. > > I currently just have a substitution for Math.sqrt( ), but I could list substitutions here for other java.lang.Math routines that aren't in MathSubstitutionsX86. > > 3) Define a MathIntrinsicHSAILNode (under com.oracle.graal.replacements.hsail) which is similar to the MathIntrinsicNode but defines the operations that will be treated as intrinsics in the HSAIL backend. > > a. The substitutions in MathSubsitutionsHSAIL.java will call the MathIntrinsicHSAILNode.compute( ) routine for the math operations we are interested in intrinsifying. > > 4) Define a ReplacementsProvider called GraalHSAILMethodSubstitutions.java under com.oracle.graal.replacements.hsail/ . Implement the registerReplacements method( ) to register specific replacements with the compiler. My version of registerReplacements() just calls replacements.registerSubstitutions(MathSubstitutionsHSAIL.class). > > 5) Override HSAILHotspotBackend.completeInitialization( ) to call ReplacementsProvider.registerReplacements( ) similar to the way it's being done in the host backend, so that the substitutions I have defined get registered in the compiler. > > Some questions: > > > a) The part that's fuzzy to me is step 5). VMToCompilerImpl.startCompiler() is calling completeInitialization( ) for the host backend (x86) and for each of the GPU target backends (including HSAIL). The completeInitialization( ) routine in the host backend is calling ReplacementsProvider.registerReplacements() to register all the x86 replacements. Am I supposed to override HSAILHotSpotBackend.completeInitialization( ) to do something similar so that the HSAIL substitutions get registered? Can you explain this process a bit? I'm not clear on who is supposed to call ReplacementsProvider.registerReplacements() to register my intrinsics. You need to do the registration yourself in HSAILHotspotBackend.completeInitialization(). However, you should not use the ServiceLoader mechanism that HotSpotHostBackend does. This means you don?t need a ReplacementsProvider (such as GraalHSAILMethodSubstitutions) at all. GPU-specific replacements should be explicitly registered with something like: try (Scope s = Debug.scope("RegisterReplacements", new DebugDumpScope("RegisterReplacements"))) { Replacements replacements = providers.getReplacements(); replacements.registerSubstitutions(MathSubstitutionsHSAIL.class) } > b) From looking at VMToCompilerImpl.startCompiler(), it appears that the substitutions used in the host backend (x86) as well as substitutions used in the GPU target backend (HSAIL) will all get registered with the compiler if I take the approach in a) above. How can I ensure that my math intrinsics are the ones that get used instead of the host backend intrinsics? In particular, how do I ensure that my intrinsic for Math.sqrt is what gets used (instead of the host backend's version) when I'm generating HSAIL code? Replacements get registered with a backend specific Replacements object which will be a HSAILHotSpotReplacementsImpl object in your case. Since a compilation uses the Replacements object it was provided with (in the Providers value passed to GraalCompiler.compileGraph()), it will only get replacements from that object. You therefore just have to make sure HSAILHotSpotReplacementsImpl only returns the replacements that are applicable to HSAIL. -Doug From tom.deneau at amd.com Mon Dec 2 12:52:24 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 2 Dec 2013 20:52:24 +0000 Subject: disassembly for foreign call wrapper In-Reply-To: References: Message-ID: Doug or others -- In the case of a Foreign Call to Deoptimization::uncommon_trap, I see that gdb shows this code after we return from uncommon_trap... 0x7fffeb05ddb1: callq 0x7ffff68b130e 0x7fffeb05ddb6: movabs $0x0,%r10 0x7fffeb05ddc0: mov %r10,0x200(%r15) 0x7fffeb05ddc7: jmpq 0x7fffeb05df99 and the code at 0x7fffeb05df99 eventually calls Deoptimization::unpack_frames and then I think enters the interpreter. So I was wondering where this wrapper code that follows the return from uncommon_trap gets generated -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Thursday, November 21, 2013 2:59 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: disassembly for foreign call wrapper This is no wrapper - just the foreign call plus maybe a prologue/epilogue around the call. For example, each of the calls in the output below is to foreign call described by SystemSubstitutions.JAVA_TIME_MILLIS: $ mx --vm server unittest -G:Log=CodeInstall -G:MethodFilter=test System_nanoTime01 JUnit version 4.8 .Loaded disassembler from /Users/dsimon/linz/basic-graal/jdk1.7.0_45/product/jre/lib/hsdis-amd64.dylib [thread:1] scope: [thread:1] scope: Compiling [thread:1] scope: Compiling.CodeInstall Code installed for HotSpotMethod ---------------------------------------------------------------------- com/oracle/graal/jtt/jdk/System_nanoTime01.test [0x000000010971dba0, 0x000000010971dc40] 1280 bytes [Disassembling for mach='i386:x86-64'] [Entry Point] [Verified Entry Point] [Constants] # {method} {0x0000000112bbfde8} 'test' '()I' in 'com/oracle/graal/jtt/jdk/System_nanoTime01' # [sp+0x20] (sp of caller) 0x000000010971dba0: mov %rax,-0x14000(%rsp) 0x000000010971dba8: sub $0x18,%rsp 0x000000010971dbac: mov %rbp,0x10(%rsp) 0x000000010971dbb1: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbb6: nop 0x000000010971dbb7: mov %rax,0x8(%rsp) 0x000000010971dbbc: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbc1: nop 0x000000010971dbc2: sub 0x8(%rsp),%rax 0x000000010971dbc7: cmp $0x0,%rax 0x000000010971dbcb: jg 0x000000010971dc0d 0x000000010971dbd1: mov $0x1,%eax 0x000000010971dbd6: jmpq 0x000000010971dbff 0x000000010971dbdb: nopl 0x0(%rax,%rax,1) 0x000000010971dbe0: mov %eax,0x4(%rsp) 0x000000010971dbe4: callq 0x0000000108c22934 ; {runtime_call} 0x000000010971dbe9: nop 0x000000010971dbea: sub 0x8(%rsp),%rax 0x000000010971dbef: cmp $0x0,%rax 0x000000010971dbf3: jg 0x000000010971dc2a 0x000000010971dbf9: mov 0x4(%rsp),%eax 0x000000010971dbfd: inc %eax 0x000000010971dbff: cmp $0x989680,%eax 0x000000010971dc05: jge 0x000000010971dc23 0x000000010971dc0b: jmp 0x000000010971dbe0 0x000000010971dc0d: mov $0x1,%eax 0x000000010971dc12: mov 0x10(%rsp),%rbp 0x000000010971dc17: add $0x18,%rsp 0x000000010971dc1b: mov -0x1784c1b(%rip),%rbx # 0x0000000107f99007 ; {poll_return} 0x000000010971dc22: retq 0x000000010971dc23: mov $0x0,%eax 0x000000010971dc28: jmp 0x000000010971dc12 0x000000010971dc2a: mov $0x1,%eax 0x000000010971dc2f: jmp 0x000000010971dc12 [Exception Handler] 0x000000010971dc31: callq 0x000000010971dd20 ; {runtime_call} 0x000000010971dc36: nop [Deopt Handler Code] 0x000000010971dc37: callq 0x00000001095deb00 ; {runtime_call} 0x000000010971dc3c: nop [Stub Code] 0x000000010971dc3d: hlt 0x000000010971dc3e: hlt 0x000000010971dc3f: hlt On Nov 21, 2013, at 9:17 PM, Deneau, Tom wrote: > Is there a Log scoping that will show the disassembly for the code that is the wrapper for a foreign call to a non-stub. > > I am currently using -G:Log=CodeInstall which gives me normal methods plus CompilingStub.CodeInstall . > > -- Tom From doug.simon at oracle.com Mon Dec 2 13:05:09 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 2 Dec 2013 22:05:09 +0100 Subject: disassembly for foreign call wrapper In-Reply-To: References: Message-ID: <4EA67CAC-92D5-4C33-99D7-DB2975A6EB38@oracle.com> On Dec 2, 2013, at 9:52 PM, Deneau, Tom wrote: > Doug or others -- > > In the case of a Foreign Call to Deoptimization::uncommon_trap, I see that gdb shows this code after we return from uncommon_trap... > > 0x7fffeb05ddb1: callq 0x7ffff68b130e > 0x7fffeb05ddb6: movabs $0x0,%r10 > 0x7fffeb05ddc0: mov %r10,0x200(%r15) > 0x7fffeb05ddc7: jmpq 0x7fffeb05df99 > > and the code at 0x7fffeb05df99 eventually calls Deoptimization::unpack_frames and > then I think enters the interpreter. This is code from the manually assembled deopt blob (generated by SharedRuntime::generate_deopt_blob() in sharedRuntime_.cpp) > So I was wondering where this wrapper code that follows the return from uncommon_trap gets generated For instance, look at sharedRuntime_x86_64.cpp:3401. The Graal HotSpotBackend.UNCOMMON_TRAP foreign call is to the address within the above blob retrieved via SharedRuntime::deopt_blob()->uncommon_trap(). -Doug > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Thursday, November 21, 2013 2:59 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: disassembly for foreign call wrapper > > This is no wrapper - just the foreign call plus maybe a prologue/epilogue around the call. For example, each of the calls in the output below is to foreign call described by SystemSubstitutions.JAVA_TIME_MILLIS: > > $ mx --vm server unittest -G:Log=CodeInstall -G:MethodFilter=test System_nanoTime01 JUnit version 4.8 .Loaded disassembler from /Users/dsimon/linz/basic-graal/jdk1.7.0_45/product/jre/lib/hsdis-amd64.dylib > [thread:1] scope: > [thread:1] scope: Compiling > [thread:1] scope: Compiling.CodeInstall > Code installed for HotSpotMethod > ---------------------------------------------------------------------- > com/oracle/graal/jtt/jdk/System_nanoTime01.test [0x000000010971dba0, 0x000000010971dc40] 1280 bytes [Disassembling for mach='i386:x86-64'] [Entry Point] [Verified Entry Point] [Constants] > # {method} {0x0000000112bbfde8} 'test' '()I' in 'com/oracle/graal/jtt/jdk/System_nanoTime01' > # [sp+0x20] (sp of caller) > 0x000000010971dba0: mov %rax,-0x14000(%rsp) > 0x000000010971dba8: sub $0x18,%rsp > 0x000000010971dbac: mov %rbp,0x10(%rsp) > 0x000000010971dbb1: callq 0x0000000108c22934 ; {runtime_call} > 0x000000010971dbb6: nop > 0x000000010971dbb7: mov %rax,0x8(%rsp) > 0x000000010971dbbc: callq 0x0000000108c22934 ; {runtime_call} > 0x000000010971dbc1: nop > 0x000000010971dbc2: sub 0x8(%rsp),%rax > 0x000000010971dbc7: cmp $0x0,%rax > 0x000000010971dbcb: jg 0x000000010971dc0d > 0x000000010971dbd1: mov $0x1,%eax > 0x000000010971dbd6: jmpq 0x000000010971dbff > 0x000000010971dbdb: nopl 0x0(%rax,%rax,1) > 0x000000010971dbe0: mov %eax,0x4(%rsp) > 0x000000010971dbe4: callq 0x0000000108c22934 ; {runtime_call} > 0x000000010971dbe9: nop > 0x000000010971dbea: sub 0x8(%rsp),%rax > 0x000000010971dbef: cmp $0x0,%rax > 0x000000010971dbf3: jg 0x000000010971dc2a > 0x000000010971dbf9: mov 0x4(%rsp),%eax > 0x000000010971dbfd: inc %eax > 0x000000010971dbff: cmp $0x989680,%eax > 0x000000010971dc05: jge 0x000000010971dc23 > 0x000000010971dc0b: jmp 0x000000010971dbe0 > 0x000000010971dc0d: mov $0x1,%eax > 0x000000010971dc12: mov 0x10(%rsp),%rbp > 0x000000010971dc17: add $0x18,%rsp > 0x000000010971dc1b: mov -0x1784c1b(%rip),%rbx # 0x0000000107f99007 > ; {poll_return} > 0x000000010971dc22: retq > 0x000000010971dc23: mov $0x0,%eax > 0x000000010971dc28: jmp 0x000000010971dc12 > 0x000000010971dc2a: mov $0x1,%eax > 0x000000010971dc2f: jmp 0x000000010971dc12 > [Exception Handler] > 0x000000010971dc31: callq 0x000000010971dd20 ; {runtime_call} > 0x000000010971dc36: nop > [Deopt Handler Code] > 0x000000010971dc37: callq 0x00000001095deb00 ; {runtime_call} > 0x000000010971dc3c: nop > [Stub Code] > 0x000000010971dc3d: hlt > 0x000000010971dc3e: hlt > 0x000000010971dc3f: hlt > > On Nov 21, 2013, at 9:17 PM, Deneau, Tom wrote: > >> Is there a Log scoping that will show the disassembly for the code that is the wrapper for a foreign call to a non-stub. >> >> I am currently using -G:Log=CodeInstall which gives me normal methods plus CompilingStub.CodeInstall . >> >> -- Tom > > > From christian.thalinger at oracle.com Mon Dec 2 18:32:07 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 2 Dec 2013 18:32:07 -0800 Subject: questions about implementing intrinsics In-Reply-To: <466E9D24-CC6F-405F-A836-F82048698D90@oracle.com> References: <5DD1503F815BD14889DC81D28643E3A75788ED51@SATLEXDAG02.amd.com> <466E9D24-CC6F-405F-A836-F82048698D90@oracle.com> Message-ID: On Dec 2, 2013, at 2:16 AM, Doug Simon wrote: > > On Dec 1, 2013, at 6:52 PM, Venkatachalam, Vasanth wrote: > >> Doug or others- >> >> I'm trying to understand the process of implementing intrinsics (for the HSAIL backend) for some java.lang.Math routines that x86 doesn't necessarily intrinsify. >> As a toy example, I'm trying to implement my own intrinsic for Math.sqrt( ). Below are the steps I tried to take to hack a small prototype. >> Can you tell me whether I'm on the right track? I also had some questions below. >> >> >> 1) Define a package com.oracle.graal.replacements.hsail. >> >> 2) In the above package, define a class MathSubstitutionsHSAIL.java (similar to MathSubstitutionsX86) which contains substitutions for methods of the java.lang.Math class. >> >> I currently just have a substitution for Math.sqrt( ), but I could list substitutions here for other java.lang.Math routines that aren't in MathSubstitutionsX86. >> >> 3) Define a MathIntrinsicHSAILNode (under com.oracle.graal.replacements.hsail) which is similar to the MathIntrinsicNode but defines the operations that will be treated as intrinsics in the HSAIL backend. >> >> a. The substitutions in MathSubsitutionsHSAIL.java will call the MathIntrinsicHSAILNode.compute( ) routine for the math operations we are interested in intrinsifying. >> >> 4) Define a ReplacementsProvider called GraalHSAILMethodSubstitutions.java under com.oracle.graal.replacements.hsail/ . Implement the registerReplacements method( ) to register specific replacements with the compiler. My version of registerReplacements() just calls replacements.registerSubstitutions(MathSubstitutionsHSAIL.class). >> >> 5) Override HSAILHotspotBackend.completeInitialization( ) to call ReplacementsProvider.registerReplacements( ) similar to the way it's being done in the host backend, so that the substitutions I have defined get registered in the compiler. >> >> Some questions: >> >> >> a) The part that's fuzzy to me is step 5). VMToCompilerImpl.startCompiler() is calling completeInitialization( ) for the host backend (x86) and for each of the GPU target backends (including HSAIL). The completeInitialization( ) routine in the host backend is calling ReplacementsProvider.registerReplacements() to register all the x86 replacements. Am I supposed to override HSAILHotSpotBackend.completeInitialization( ) to do something similar so that the HSAIL substitutions get registered? Can you explain this process a bit? I'm not clear on who is supposed to call ReplacementsProvider.registerReplacements() to register my intrinsics. > > You need to do the registration yourself in HSAILHotspotBackend.completeInitialization(). However, you should not use the ServiceLoader mechanism that HotSpotHostBackend does. This means you don?t need a ReplacementsProvider (such as GraalHSAILMethodSubstitutions) at all. GPU-specific replacements should be explicitly registered with something like: > > try (Scope s = Debug.scope("RegisterReplacements", new DebugDumpScope("RegisterReplacements"))) { > Replacements replacements = providers.getReplacements(); > replacements.registerSubstitutions(MathSubstitutionsHSAIL.class) General question: why is the architecture name at the end of the class name? All others have the architecture name in the front. And why is it x86 for AMD64? > } > >> b) From looking at VMToCompilerImpl.startCompiler(), it appears that the substitutions used in the host backend (x86) as well as substitutions used in the GPU target backend (HSAIL) will all get registered with the compiler if I take the approach in a) above. How can I ensure that my math intrinsics are the ones that get used instead of the host backend intrinsics? In particular, how do I ensure that my intrinsic for Math.sqrt is what gets used (instead of the host backend's version) when I'm generating HSAIL code? > > Replacements get registered with a backend specific Replacements object which will be a HSAILHotSpotReplacementsImpl object in your case. Since a compilation uses the Replacements object it was provided with (in the Providers value passed to GraalCompiler.compileGraph()), it will only get replacements from that object. You therefore just have to make sure HSAILHotSpotReplacementsImpl only returns the replacements that are applicable to HSAIL. > > -Doug From doug.simon at oracle.com Mon Dec 2 23:36:41 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 3 Dec 2013 08:36:41 +0100 Subject: questions about implementing intrinsics In-Reply-To: References: <5DD1503F815BD14889DC81D28643E3A75788ED51@SATLEXDAG02.amd.com> <466E9D24-CC6F-405F-A836-F82048698D90@oracle.com> Message-ID: <48FC05FD-4B73-4FC4-BE39-50B1D1D9E77F@oracle.com> On Dec 3, 2013, at 3:32 AM, Christian Thalinger wrote: > > On Dec 2, 2013, at 2:16 AM, Doug Simon wrote: > >> >> On Dec 1, 2013, at 6:52 PM, Venkatachalam, Vasanth wrote: >> >>> Doug or others- >>> >>> I'm trying to understand the process of implementing intrinsics (for the HSAIL backend) for some java.lang.Math routines that x86 doesn't necessarily intrinsify. >>> As a toy example, I'm trying to implement my own intrinsic for Math.sqrt( ). Below are the steps I tried to take to hack a small prototype. >>> Can you tell me whether I'm on the right track? I also had some questions below. >>> >>> >>> 1) Define a package com.oracle.graal.replacements.hsail. >>> >>> 2) In the above package, define a class MathSubstitutionsHSAIL.java (similar to MathSubstitutionsX86) which contains substitutions for methods of the java.lang.Math class. >>> >>> I currently just have a substitution for Math.sqrt( ), but I could list substitutions here for other java.lang.Math routines that aren't in MathSubstitutionsX86. >>> >>> 3) Define a MathIntrinsicHSAILNode (under com.oracle.graal.replacements.hsail) which is similar to the MathIntrinsicNode but defines the operations that will be treated as intrinsics in the HSAIL backend. >>> >>> a. The substitutions in MathSubsitutionsHSAIL.java will call the MathIntrinsicHSAILNode.compute( ) routine for the math operations we are interested in intrinsifying. >>> >>> 4) Define a ReplacementsProvider called GraalHSAILMethodSubstitutions.java under com.oracle.graal.replacements.hsail/ . Implement the registerReplacements method( ) to register specific replacements with the compiler. My version of registerReplacements() just calls replacements.registerSubstitutions(MathSubstitutionsHSAIL.class). >>> >>> 5) Override HSAILHotspotBackend.completeInitialization( ) to call ReplacementsProvider.registerReplacements( ) similar to the way it's being done in the host backend, so that the substitutions I have defined get registered in the compiler. >>> >>> Some questions: >>> >>> >>> a) The part that's fuzzy to me is step 5). VMToCompilerImpl.startCompiler() is calling completeInitialization( ) for the host backend (x86) and for each of the GPU target backends (including HSAIL). The completeInitialization( ) routine in the host backend is calling ReplacementsProvider.registerReplacements() to register all the x86 replacements. Am I supposed to override HSAILHotSpotBackend.completeInitialization( ) to do something similar so that the HSAIL substitutions get registered? Can you explain this process a bit? I'm not clear on who is supposed to call ReplacementsProvider.registerReplacements() to register my intrinsics. >> >> You need to do the registration yourself in HSAILHotspotBackend.completeInitialization(). However, you should not use the ServiceLoader mechanism that HotSpotHostBackend does. This means you don?t need a ReplacementsProvider (such as GraalHSAILMethodSubstitutions) at all. GPU-specific replacements should be explicitly registered with something like: >> >> try (Scope s = Debug.scope("RegisterReplacements", new DebugDumpScope("RegisterReplacements"))) { >> Replacements replacements = providers.getReplacements(); >> replacements.registerSubstitutions(MathSubstitutionsHSAIL.class) > > General question: why is the architecture name at the end of the class name? All others have the architecture name in the front. And why is it x86 for AMD64? Good point. The above class should definitely be named HSAILMathSubstitutions. With respect to MathSubstitutionsX86, this class needs some attention in any case given that it includes substitutions that may be supported on more than just x86/x64. For example, I see that SPARCMathIntrinsicOp support sqrt. In general, I think the class should be renamed to drop the X86 suffix and CPU specific subclasses of HotSpotReplacementsImpl should be created to filter the defined substitutions as applicable. -Doug From falbert9 at vt.edu Wed Dec 4 06:58:54 2013 From: falbert9 at vt.edu (Curt Albert) Date: Wed, 4 Dec 2013 09:58:54 -0500 Subject: Graal Intrinsification Extensions Message-ID: I am a student at Virginia Tech interested in graal. I was looking over the slides from the jvm lang summit and found the intrinsification extension example. However when looking through code I could not find this ever implemented anywhere. I was wondering if someone could help me get the example running. Does it matter where the IntrinsifierImpl class code is? Does it go in graal itself and if so where or in my java source file? Thanks, Curt Albert From tom.deneau at amd.com Wed Dec 4 10:07:27 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 4 Dec 2013 18:07:27 +0000 Subject: compiled leaf method vs. inlined method bounds check In-Reply-To: References: Message-ID: Gilles or others -- Still trying to understand this topic? I made a test case where I just compile a simple method that inlines another method, no profiling. // compile this one public int intFromArrayLonger(int[] ary, int idx) { return intFromArrayLongerInner(ary, idx + 7); } public int intFromArrayLongerInner(int[] ary, int idx) { return ary[idx + 3]; } I ran that compiling for the HSAIL backend and then in a separate run for the AMD64 backend. In the HSAIL case, I see the Deopt NotCompiledExceptionHandler, whereas the AMD64 case has the Deopt BoundsCheckException I put the igv graphs up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/inline-example.xml (the xml has the graphs from both backends) Maybe someone can take a look A couple of questions from the early phases of these graphs: ? why is the graph after bytecode parsing of the inner method so different in the two cases? ? What is the phase called after bytecode parsing called HSAIL? -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Thursday, November 21, 2013 5:27 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiled leaf method vs. inlined method bounds check Hello Tom, sorry for the delayed answer. I did the tests and i can not reproduce the behaviour you are seeing if no exception is ever thrown. However i can easily reproduce it if the first method (the one containing the array accesses) has already thrown an exception while the second one (the one containing the call) has never seen an exception flow through the call. In this case the second method assumes no exception can never flow through the call but when it inline the call, it sees that it actually needs to handle exceptions, in this case you get that NotCompiledExceptionHandler reason. I used this to test: public class ArrayTest extends JTTTest { static int[] array = {1, 2, 3}; @Test public void test0() throws Throwable { run(new int[3], array, array, 0); runTest("callRun", new int[3], array, array, 0); } @Test public void test1() throws Throwable { run(new int[3], array, array, 3); runTest("callRun", new int[3], array, array, 0); } @Test public void test2() throws Throwable { callRun(new int[3], array, array, 3); runTest("callRun", new int[3], array, array, 0); } public static void run(int[] out, int[] ina, int[] inb, int gid) { out[gid] = ina[gid] + inb[gid]; } public static void callRun(int[] out, int[] ina, int[] inb, int gid) { run(out, ina, inb, gid); } } In the first case (test0) i get the inlined call an the BoundsCheckException reason. In the second case (test1) i get the inlined call and the NotCompiledExceptionHandler reason. In the thrid case (test2) i get the full exception handling. Note that you need to run these separately if you don't want profile pollution. -Gilles On Wed, Nov 13, 2013 at 1:22 AM, Tom Deneau > wrote: Gilles -- OK, we have a simple existing test in com.oracle.graal.compiler.hsail.test.IntAddTest which adds ints from two arrays putting the result in a third output array public static void run(int[] out, int[] ina, int[] inb, int gid) { out[gid] = ina[gid] + inb[gid]; } Here is the hsail code:. (Note that we don't really handle the DeoptimizeNode but just print a comment based on the reason). version 0:95: $full : $large; // static method HotSpotMethod kernel &run ( kernarg_u64 %_arg0, kernarg_u64 %_arg1, kernarg_u64 %_arg2 ) { ld_kernarg_u64 $d0, [%_arg0]; ld_kernarg_u64 $d1, [%_arg1]; ld_kernarg_u64 $d2, [%_arg2]; workitemabsid_u32 $s0, 0; @L0: ld_global_s32 $s1, [$d0 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L1: ld_global_s32 $s1, [$d2 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L2: ld_global_s32 $s1, [$d1 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L3: cvt_s64_s32 $d3, $s0; mul_s64 $d3, $d3, 4; add_u64 $d1, $d1, $d3; ld_global_s32 $s1, [$d1 + 16]; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d2, $d2, $d1; ld_global_s32 $s2, [$d2 + 16]; add_s32 $s2, $s2, $s1; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d0, $d0, $d1; st_global_s32 $s2, [$d0 + 16]; ret; @L7: // Deoptimization for BoundsCheckException would occur here ret; }; Then I made a new test where the run method just basically called the original IntAddTest.run public static void run(int[] out, int[] ina, int[] inb, int gid) { IntAddTest.run(out, ina, inb, gid); } We compile with InlineEverything set. We got this almost identical hsail code except for the deoptimization reason. (In this case, there is no call to createOutOfBoundsException but I have seen it in larger test cases). Note that in either case, no exceptions would have occurred when profiling. version 0:95: $full : $large; // static method HotSpotMethod kernel &run ( kernarg_u64 %_arg0, kernarg_u64 %_arg1, kernarg_u64 %_arg2 ) { ld_kernarg_u64 $d0, [%_arg0]; ld_kernarg_u64 $d1, [%_arg1]; ld_kernarg_u64 $d2, [%_arg2]; workitemabsid_u32 $s0, 0; @L0: ld_global_s32 $s1, [$d0 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L1: ld_global_s32 $s1, [$d2 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L2: ld_global_s32 $s1, [$d1 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L3: cvt_s64_s32 $d3, $s0; mul_s64 $d3, $d3, 4; add_u64 $d1, $d1, $d3; ld_global_s32 $s1, [$d1 + 16]; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d2, $d2, $d1; ld_global_s32 $s2, [$d2 + 16]; add_s32 $s2, $s2, $s1; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d0, $d0, $d1; st_global_s32 $s2, [$d0 + 16]; ret; @L7: // Deoptimization for NotCompiledExceptionHandler would occur here ret; }; From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Tuesday, November 12, 2013 5:56 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiled leaf method vs. inlined method bounds check Can you maybe show us the snippets you used and how you ran them? The second scenario you describe usually happen if an ArrayIndexOutOfBoundsException has already been thrown at the array access you're looking at. When compiling an array access, Graal will look at the profile and if it shows that exceptions are thrown there, it will compile in the exception branch (in your case the exception branch ends up into an other deopt for some reason). If profiling shows no exception has been thrown there, it will leave out the exception branch and will only place a which deoptimizes in case an exception needs to be thrown. This should have nothing to do with inlining. When doings tests about that, be carefull not to pollute the profile for the second test with the first one. You can change the bahviour of graal reagrding these things using the UseExceptionProbabilityForOperations flag. -Gilles On Tue, Nov 12, 2013 at 11:49 PM, Tom Deneau > wrote: I've noticed that if the graph I am compiling is simply a leaf method which accesses an array, the target of a failing bounds check is a DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile But if the method that is accessing the array is being inlined into another method, the target of the failing bounds check is a ForeignCall to createOutOfBoundsException followed by a branch to a DeoptimizeNode with reason=NotCompiledExceptionHandler, action=InvalidateRecompile. Can someone explain this difference? -- Tom From gilwooden at gmail.com Wed Dec 4 11:22:15 2013 From: gilwooden at gmail.com (Gilles Duboscq) Date: Wed, 4 Dec 2013 20:22:15 +0100 Subject: compiled leaf method vs. inlined method bounds check In-Reply-To: References: Message-ID: On Wed, Dec 4, 2013 at 7:07 PM, Tom Deneau wrote: > Gilles or others -- > > > > Still trying to understand this topic? > > I made a test case where I just compile a simple method that inlines > another method, no profiling. > > > > // compile this one > > public int intFromArrayLonger(int[] ary, int idx) { > > return intFromArrayLongerInner(ary, idx + 7); > > } > > > > public int intFromArrayLongerInner(int[] ary, int idx) { > > return ary[idx + 3]; > > } > > > > > > I ran that compiling for the HSAIL backend and then in a separate run for > the AMD64 backend. > > In the HSAIL case, I see the Deopt NotCompiledExceptionHandler, whereas > the AMD64 case has the Deopt BoundsCheckException > > > > I put the igv graphs up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/inline-example.xml > (the xml has the graphs from both backends) > > Maybe someone can take a look > > > > A couple of questions from the early phases of these graphs: > > ? why is the graph after bytecode parsing of the inner method so > different in the two cases? > in HSAILCompilationResult.java line 174, you can see the GraphBuilder used there is configured without any optimistic assumptions (OptimisticOptimizations.NONE). This means there will be explicit exception edge for everything. This also explains the difference for the Deopt reason. > ? What is the phase called after bytecode parsing called HSAIL? > It's com.oracle.graal.hotspot.hsail.HSAILCompilationResult.HSAILPhase. it's added in HSAILCompilationResult.java line 174. > > > -- Tom > > > > > > *From:* gilwooden at gmail.com [mailto:gilwooden at gmail.com] *On Behalf Of *Gilles > Duboscq > *Sent:* Thursday, November 21, 2013 5:27 AM > > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: compiled leaf method vs. inlined method bounds check > > > > Hello Tom, > > > > sorry for the delayed answer. > > > > I did the tests and i can not reproduce the behaviour you are seeing if no > exception is ever thrown. > > However i can easily reproduce it if the first method (the one containing > the array accesses) has already thrown an exception while the second one > (the one containing the call) has never seen an exception flow through the > call. > > In this case the second method assumes no exception can never flow through > the call but when it inline the call, it sees that it actually needs to > handle exceptions, in this case you get that > NotCompiledExceptionHandler reason. > > > > I used this to test: > > > > public class ArrayTest extends JTTTest { > > static int[] array = {1, 2, 3}; > > > > @Test > > public void test0() throws Throwable { > > run(new int[3], array, array, 0); > > runTest("callRun", new int[3], array, array, 0); > > } > > > > @Test > > public void test1() throws Throwable { > > run(new int[3], array, array, 3); > > runTest("callRun", new int[3], array, array, 0); > > } > > > > @Test > > public void test2() throws Throwable { > > callRun(new int[3], array, array, 3); > > runTest("callRun", new int[3], array, array, 0); > > } > > > > public static void run(int[] out, int[] ina, int[] inb, int gid) { > > out[gid] = ina[gid] + inb[gid]; > > } > > > > public static void callRun(int[] out, int[] ina, int[] inb, int gid) { > > run(out, ina, inb, gid); > > } > > } > > > > In the first case (test0) i get the inlined call an > the BoundsCheckException reason. > > In the second case (test1) i get the inlined call and the > NotCompiledExceptionHandler reason. > > In the thrid case (test2) i get the full exception handling. > > Note that you need to run these separately if you don't want profile > pollution. > > > > -Gilles > > > > On Wed, Nov 13, 2013 at 1:22 AM, Tom Deneau wrote: > > Gilles -- > > > > OK, we have a simple existing test in > com.oracle.graal.compiler.hsail.test.IntAddTest which adds ints from two > arrays putting the result in a third output array > > public static void run(int[] out, int[] ina, int[] inb, int gid) { > > out[gid] = ina[gid] + inb[gid]; > > } > > > > Here is the hsail code:. (Note that we don't really handle the > DeoptimizeNode but just print a comment based on the reason). > > > > version 0:95: $full : $large; > > // static method HotSpotMethod int)> > > kernel &run ( > > kernarg_u64 %_arg0, > > kernarg_u64 %_arg1, > > kernarg_u64 %_arg2 > > ) { > > ld_kernarg_u64 $d0, [%_arg0]; > > ld_kernarg_u64 $d1, [%_arg1]; > > ld_kernarg_u64 $d2, [%_arg2]; > > workitemabsid_u32 $s0, 0; > > > > @L0: > > ld_global_s32 $s1, [$d0 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L1: > > ld_global_s32 $s1, [$d2 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L2: > > ld_global_s32 $s1, [$d1 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L3: > > cvt_s64_s32 $d3, $s0; > > mul_s64 $d3, $d3, 4; > > add_u64 $d1, $d1, $d3; > > ld_global_s32 $s1, [$d1 + 16]; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d2, $d2, $d1; > > ld_global_s32 $s2, [$d2 + 16]; > > add_s32 $s2, $s2, $s1; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d0, $d0, $d1; > > st_global_s32 $s2, [$d0 + 16]; > > ret; > > @L7: > > // Deoptimization for BoundsCheckException would occur here > > ret; > > }; > > > > > > Then I made a new test where the run method just basically called the > original IntAddTest.run > > public static void run(int[] out, int[] ina, int[] inb, int gid) { > > IntAddTest.run(out, ina, inb, gid); > > } > > > > We compile with InlineEverything set. We got this almost identical hsail > code except for the deoptimization reason. (In this case, there is no call > to createOutOfBoundsException but I have seen it in larger test cases). > Note that in either case, no exceptions would have occurred when profiling. > > > > version 0:95: $full : $large; > > // static method HotSpotMethod int)> > > kernel &run ( > > kernarg_u64 %_arg0, > > kernarg_u64 %_arg1, > > kernarg_u64 %_arg2 > > ) { > > ld_kernarg_u64 $d0, [%_arg0]; > > ld_kernarg_u64 $d1, [%_arg1]; > > ld_kernarg_u64 $d2, [%_arg2]; > > workitemabsid_u32 $s0, 0; > > > > @L0: > > ld_global_s32 $s1, [$d0 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L1: > > ld_global_s32 $s1, [$d2 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L2: > > ld_global_s32 $s1, [$d1 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L3: > > cvt_s64_s32 $d3, $s0; > > mul_s64 $d3, $d3, 4; > > add_u64 $d1, $d1, $d3; > > ld_global_s32 $s1, [$d1 + 16]; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d2, $d2, $d1; > > ld_global_s32 $s2, [$d2 + 16]; > > add_s32 $s2, $s2, $s1; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d0, $d0, $d1; > > st_global_s32 $s2, [$d0 + 16]; > > ret; > > @L7: > > // Deoptimization for NotCompiledExceptionHandler would > occur here > > ret; > > }; > > > > > > *From:* gilwooden at gmail.com [mailto:gilwooden at gmail.com] *On Behalf Of *Gilles > Duboscq > *Sent:* Tuesday, November 12, 2013 5:56 PM > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: compiled leaf method vs. inlined method bounds check > > > > Can you maybe show us the snippets you used and how you ran them? > > The second scenario you describe usually happen if an > ArrayIndexOutOfBoundsException has already been thrown at the array access > you're looking at. > > When compiling an array access, Graal will look at the profile and if it > shows that exceptions are thrown there, it will compile in the exception > branch (in your case the exception branch ends up into an other deopt for > some reason). If profiling shows no exception has been thrown there, it > will leave out the exception branch and will only place a which deoptimizes > in case an exception needs to be thrown. > > > > This should have nothing to do with inlining. When doings tests about > that, be carefull not to pollute the profile for the second test with the > first one. > > You can change the bahviour of graal reagrding these things using > the UseExceptionProbabilityForOperations flag. > > > > -Gilles > > > > On Tue, Nov 12, 2013 at 11:49 PM, Tom Deneau wrote: > > I've noticed that if the graph I am compiling is simply a leaf method > which accesses an array, the target of a failing bounds check is a > DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile > > But if the method that is accessing the array is being inlined into > another method, the target of the failing bounds check is a ForeignCall to > createOutOfBoundsException followed by a branch to a DeoptimizeNode with > reason=NotCompiledExceptionHandler, action=InvalidateRecompile. > > Can someone explain this difference? > > -- Tom > > > > > From tom.deneau at amd.com Wed Dec 4 11:53:09 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 4 Dec 2013 19:53:09 +0000 Subject: compiled leaf method vs. inlined method bounds check In-Reply-To: References: Message-ID: I think the HSAILPhase was copied from some early PTX backend, although I see there is still also a PTXPhase that does the same thing. Does this just mark each object node in the graph as non-null, and thus eliminate null check code? private static class HSAILPhase extends Phase { @Override protected void run(StructuredGraph graph) { for (LocalNode local : graph.getNodes(LocalNode.class)) { if (local.stamp() instanceof ObjectStamp) { local.setStamp(StampFactory.declaredNonNull(((ObjectStamp) local.stamp()).type())); } } } } From: Gilles Duboscq [mailto:gilwooden at gmail.com] Sent: Wednesday, December 04, 2013 1:22 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiled leaf method vs. inlined method bounds check On Wed, Dec 4, 2013 at 7:07 PM, Tom Deneau > wrote: Gilles or others -- Still trying to understand this topic? I made a test case where I just compile a simple method that inlines another method, no profiling. // compile this one public int intFromArrayLonger(int[] ary, int idx) { return intFromArrayLongerInner(ary, idx + 7); } public int intFromArrayLongerInner(int[] ary, int idx) { return ary[idx + 3]; } I ran that compiling for the HSAIL backend and then in a separate run for the AMD64 backend. In the HSAIL case, I see the Deopt NotCompiledExceptionHandler, whereas the AMD64 case has the Deopt BoundsCheckException I put the igv graphs up at http://cr.openjdk.java.net/~tdeneau/graal-webrevs/inline-example.xml (the xml has the graphs from both backends) Maybe someone can take a look A couple of questions from the early phases of these graphs: ? why is the graph after bytecode parsing of the inner method so different in the two cases? in HSAILCompilationResult.java line 174, you can see the GraphBuilder used there is configured without any optimistic assumptions (OptimisticOptimizations.NONE). This means there will be explicit exception edge for everything. This also explains the difference for the Deopt reason. ? What is the phase called after bytecode parsing called HSAIL? It's com.oracle.graal.hotspot.hsail.HSAILCompilationResult.HSAILPhase. it's added in HSAILCompilationResult.java line 174. -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Thursday, November 21, 2013 5:27 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiled leaf method vs. inlined method bounds check Hello Tom, sorry for the delayed answer. I did the tests and i can not reproduce the behaviour you are seeing if no exception is ever thrown. However i can easily reproduce it if the first method (the one containing the array accesses) has already thrown an exception while the second one (the one containing the call) has never seen an exception flow through the call. In this case the second method assumes no exception can never flow through the call but when it inline the call, it sees that it actually needs to handle exceptions, in this case you get that NotCompiledExceptionHandler reason. I used this to test: public class ArrayTest extends JTTTest { static int[] array = {1, 2, 3}; @Test public void test0() throws Throwable { run(new int[3], array, array, 0); runTest("callRun", new int[3], array, array, 0); } @Test public void test1() throws Throwable { run(new int[3], array, array, 3); runTest("callRun", new int[3], array, array, 0); } @Test public void test2() throws Throwable { callRun(new int[3], array, array, 3); runTest("callRun", new int[3], array, array, 0); } public static void run(int[] out, int[] ina, int[] inb, int gid) { out[gid] = ina[gid] + inb[gid]; } public static void callRun(int[] out, int[] ina, int[] inb, int gid) { run(out, ina, inb, gid); } } In the first case (test0) i get the inlined call an the BoundsCheckException reason. In the second case (test1) i get the inlined call and the NotCompiledExceptionHandler reason. In the thrid case (test2) i get the full exception handling. Note that you need to run these separately if you don't want profile pollution. -Gilles On Wed, Nov 13, 2013 at 1:22 AM, Tom Deneau > wrote: Gilles -- OK, we have a simple existing test in com.oracle.graal.compiler.hsail.test.IntAddTest which adds ints from two arrays putting the result in a third output array public static void run(int[] out, int[] ina, int[] inb, int gid) { out[gid] = ina[gid] + inb[gid]; } Here is the hsail code:. (Note that we don't really handle the DeoptimizeNode but just print a comment based on the reason). version 0:95: $full : $large; // static method HotSpotMethod kernel &run ( kernarg_u64 %_arg0, kernarg_u64 %_arg1, kernarg_u64 %_arg2 ) { ld_kernarg_u64 $d0, [%_arg0]; ld_kernarg_u64 $d1, [%_arg1]; ld_kernarg_u64 $d2, [%_arg2]; workitemabsid_u32 $s0, 0; @L0: ld_global_s32 $s1, [$d0 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L1: ld_global_s32 $s1, [$d2 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L2: ld_global_s32 $s1, [$d1 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L3: cvt_s64_s32 $d3, $s0; mul_s64 $d3, $d3, 4; add_u64 $d1, $d1, $d3; ld_global_s32 $s1, [$d1 + 16]; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d2, $d2, $d1; ld_global_s32 $s2, [$d2 + 16]; add_s32 $s2, $s2, $s1; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d0, $d0, $d1; st_global_s32 $s2, [$d0 + 16]; ret; @L7: // Deoptimization for BoundsCheckException would occur here ret; }; Then I made a new test where the run method just basically called the original IntAddTest.run public static void run(int[] out, int[] ina, int[] inb, int gid) { IntAddTest.run(out, ina, inb, gid); } We compile with InlineEverything set. We got this almost identical hsail code except for the deoptimization reason. (In this case, there is no call to createOutOfBoundsException but I have seen it in larger test cases). Note that in either case, no exceptions would have occurred when profiling. version 0:95: $full : $large; // static method HotSpotMethod kernel &run ( kernarg_u64 %_arg0, kernarg_u64 %_arg1, kernarg_u64 %_arg2 ) { ld_kernarg_u64 $d0, [%_arg0]; ld_kernarg_u64 $d1, [%_arg1]; ld_kernarg_u64 $d2, [%_arg2]; workitemabsid_u32 $s0, 0; @L0: ld_global_s32 $s1, [$d0 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L1: ld_global_s32 $s1, [$d2 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L2: ld_global_s32 $s1, [$d1 + 12]; cmp_ge_b1_u32 $c0, $s0, $s1; cbr $c0, @L7; @L3: cvt_s64_s32 $d3, $s0; mul_s64 $d3, $d3, 4; add_u64 $d1, $d1, $d3; ld_global_s32 $s1, [$d1 + 16]; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d2, $d2, $d1; ld_global_s32 $s2, [$d2 + 16]; add_s32 $s2, $s2, $s1; cvt_s64_s32 $d1, $s0; mul_s64 $d1, $d1, 4; add_u64 $d0, $d0, $d1; st_global_s32 $s2, [$d0 + 16]; ret; @L7: // Deoptimization for NotCompiledExceptionHandler would occur here ret; }; From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Tuesday, November 12, 2013 5:56 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: compiled leaf method vs. inlined method bounds check Can you maybe show us the snippets you used and how you ran them? The second scenario you describe usually happen if an ArrayIndexOutOfBoundsException has already been thrown at the array access you're looking at. When compiling an array access, Graal will look at the profile and if it shows that exceptions are thrown there, it will compile in the exception branch (in your case the exception branch ends up into an other deopt for some reason). If profiling shows no exception has been thrown there, it will leave out the exception branch and will only place a which deoptimizes in case an exception needs to be thrown. This should have nothing to do with inlining. When doings tests about that, be carefull not to pollute the profile for the second test with the first one. You can change the bahviour of graal reagrding these things using the UseExceptionProbabilityForOperations flag. -Gilles On Tue, Nov 12, 2013 at 11:49 PM, Tom Deneau > wrote: I've noticed that if the graph I am compiling is simply a leaf method which accesses an array, the target of a failing bounds check is a DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile But if the method that is accessing the array is being inlined into another method, the target of the failing bounds check is a ForeignCall to createOutOfBoundsException followed by a branch to a DeoptimizeNode with reason=NotCompiledExceptionHandler, action=InvalidateRecompile. Can someone explain this difference? -- Tom From duboscq at ssw.jku.at Wed Dec 4 12:04:25 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Wed, 4 Dec 2013 21:04:25 +0100 Subject: compiled leaf method vs. inlined method bounds check In-Reply-To: References: Message-ID: Yes at least for arguments ("Locals") of the method. On Wed, Dec 4, 2013 at 8:53 PM, Deneau, Tom wrote: > I think the HSAILPhase was copied from some early PTX backend, although > I see there is still also a PTXPhase that does the same thing. > > Does this just mark each object node in the graph as non-null, and thus > eliminate null check code? > > > > > > private static class HSAILPhase extends Phase { > > @Override > > protected void run(StructuredGraph graph) { > > for (LocalNode local : graph.getNodes(LocalNode.class)) { > > if (local.stamp() instanceof ObjectStamp) { > > > local.setStamp(StampFactory.declaredNonNull(((ObjectStamp) > local.stamp()).type())); > > } > > } > > } > > } > > > > > > *From:* Gilles Duboscq [mailto:gilwooden at gmail.com] > *Sent:* Wednesday, December 04, 2013 1:22 PM > > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: compiled leaf method vs. inlined method bounds check > > > > > > > > On Wed, Dec 4, 2013 at 7:07 PM, Tom Deneau wrote: > > Gilles or others -- > > > > Still trying to understand this topic? > > I made a test case where I just compile a simple method that inlines > another method, no profiling. > > > > // compile this one > > public int intFromArrayLonger(int[] ary, int idx) { > > return intFromArrayLongerInner(ary, idx + 7); > > } > > > > public int intFromArrayLongerInner(int[] ary, int idx) { > > return ary[idx + 3]; > > } > > > > > > I ran that compiling for the HSAIL backend and then in a separate run for > the AMD64 backend. > > In the HSAIL case, I see the Deopt NotCompiledExceptionHandler, whereas > the AMD64 case has the Deopt BoundsCheckException > > > > I put the igv graphs up at > http://cr.openjdk.java.net/~tdeneau/graal-webrevs/inline-example.xml > (the xml has the graphs from both backends) > > Maybe someone can take a look > > > > A couple of questions from the early phases of these graphs: > > ? why is the graph after bytecode parsing of the inner method so > different in the two cases? > > in HSAILCompilationResult.java line 174, you can see the GraphBuilder used > there is configured without any optimistic assumptions > (OptimisticOptimizations.NONE). This means there will be explicit exception > edge for everything. > > This also explains the difference for the Deopt reason. > > ? What is the phase called after bytecode parsing called HSAIL? > > It's com.oracle.graal.hotspot.hsail.HSAILCompilationResult.HSAILPhase. > it's added in HSAILCompilationResult.java line 174. > > > > > > -- Tom > > > > > > *From:* gilwooden at gmail.com [mailto:gilwooden at gmail.com] *On Behalf Of *Gilles > Duboscq > *Sent:* Thursday, November 21, 2013 5:27 AM > > > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: compiled leaf method vs. inlined method bounds check > > > > Hello Tom, > > > > sorry for the delayed answer. > > > > I did the tests and i can not reproduce the behaviour you are seeing if no > exception is ever thrown. > > However i can easily reproduce it if the first method (the one containing > the array accesses) has already thrown an exception while the second one > (the one containing the call) has never seen an exception flow through the > call. > > In this case the second method assumes no exception can never flow through > the call but when it inline the call, it sees that it actually needs to > handle exceptions, in this case you get that > NotCompiledExceptionHandler reason. > > > > I used this to test: > > > > public class ArrayTest extends JTTTest { > > static int[] array = {1, 2, 3}; > > > > @Test > > public void test0() throws Throwable { > > run(new int[3], array, array, 0); > > runTest("callRun", new int[3], array, array, 0); > > } > > > > @Test > > public void test1() throws Throwable { > > run(new int[3], array, array, 3); > > runTest("callRun", new int[3], array, array, 0); > > } > > > > @Test > > public void test2() throws Throwable { > > callRun(new int[3], array, array, 3); > > runTest("callRun", new int[3], array, array, 0); > > } > > > > public static void run(int[] out, int[] ina, int[] inb, int gid) { > > out[gid] = ina[gid] + inb[gid]; > > } > > > > public static void callRun(int[] out, int[] ina, int[] inb, int gid) { > > run(out, ina, inb, gid); > > } > > } > > > > In the first case (test0) i get the inlined call an > the BoundsCheckException reason. > > In the second case (test1) i get the inlined call and the > NotCompiledExceptionHandler reason. > > In the thrid case (test2) i get the full exception handling. > > Note that you need to run these separately if you don't want profile > pollution. > > > > -Gilles > > > > On Wed, Nov 13, 2013 at 1:22 AM, Tom Deneau wrote: > > Gilles -- > > > > OK, we have a simple existing test in > com.oracle.graal.compiler.hsail.test.IntAddTest which adds ints from two > arrays putting the result in a third output array > > public static void run(int[] out, int[] ina, int[] inb, int gid) { > > out[gid] = ina[gid] + inb[gid]; > > } > > > > Here is the hsail code:. (Note that we don't really handle the > DeoptimizeNode but just print a comment based on the reason). > > > > version 0:95: $full : $large; > > // static method HotSpotMethod int)> > > kernel &run ( > > kernarg_u64 %_arg0, > > kernarg_u64 %_arg1, > > kernarg_u64 %_arg2 > > ) { > > ld_kernarg_u64 $d0, [%_arg0]; > > ld_kernarg_u64 $d1, [%_arg1]; > > ld_kernarg_u64 $d2, [%_arg2]; > > workitemabsid_u32 $s0, 0; > > > > @L0: > > ld_global_s32 $s1, [$d0 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L1: > > ld_global_s32 $s1, [$d2 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L2: > > ld_global_s32 $s1, [$d1 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L3: > > cvt_s64_s32 $d3, $s0; > > mul_s64 $d3, $d3, 4; > > add_u64 $d1, $d1, $d3; > > ld_global_s32 $s1, [$d1 + 16]; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d2, $d2, $d1; > > ld_global_s32 $s2, [$d2 + 16]; > > add_s32 $s2, $s2, $s1; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d0, $d0, $d1; > > st_global_s32 $s2, [$d0 + 16]; > > ret; > > @L7: > > // Deoptimization for BoundsCheckException would occur here > > ret; > > }; > > > > > > Then I made a new test where the run method just basically called the > original IntAddTest.run > > public static void run(int[] out, int[] ina, int[] inb, int gid) { > > IntAddTest.run(out, ina, inb, gid); > > } > > > > We compile with InlineEverything set. We got this almost identical hsail > code except for the deoptimization reason. (In this case, there is no call > to createOutOfBoundsException but I have seen it in larger test cases). > Note that in either case, no exceptions would have occurred when profiling. > > > > version 0:95: $full : $large; > > // static method HotSpotMethod int)> > > kernel &run ( > > kernarg_u64 %_arg0, > > kernarg_u64 %_arg1, > > kernarg_u64 %_arg2 > > ) { > > ld_kernarg_u64 $d0, [%_arg0]; > > ld_kernarg_u64 $d1, [%_arg1]; > > ld_kernarg_u64 $d2, [%_arg2]; > > workitemabsid_u32 $s0, 0; > > > > @L0: > > ld_global_s32 $s1, [$d0 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L1: > > ld_global_s32 $s1, [$d2 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L2: > > ld_global_s32 $s1, [$d1 + 12]; > > cmp_ge_b1_u32 $c0, $s0, $s1; > > cbr $c0, @L7; > > @L3: > > cvt_s64_s32 $d3, $s0; > > mul_s64 $d3, $d3, 4; > > add_u64 $d1, $d1, $d3; > > ld_global_s32 $s1, [$d1 + 16]; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d2, $d2, $d1; > > ld_global_s32 $s2, [$d2 + 16]; > > add_s32 $s2, $s2, $s1; > > cvt_s64_s32 $d1, $s0; > > mul_s64 $d1, $d1, 4; > > add_u64 $d0, $d0, $d1; > > st_global_s32 $s2, [$d0 + 16]; > > ret; > > @L7: > > // Deoptimization for NotCompiledExceptionHandler would > occur here > > ret; > > }; > > > > > > *From:* gilwooden at gmail.com [mailto:gilwooden at gmail.com] *On Behalf Of *Gilles > Duboscq > *Sent:* Tuesday, November 12, 2013 5:56 PM > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: compiled leaf method vs. inlined method bounds check > > > > Can you maybe show us the snippets you used and how you ran them? > > The second scenario you describe usually happen if an > ArrayIndexOutOfBoundsException has already been thrown at the array access > you're looking at. > > When compiling an array access, Graal will look at the profile and if it > shows that exceptions are thrown there, it will compile in the exception > branch (in your case the exception branch ends up into an other deopt for > some reason). If profiling shows no exception has been thrown there, it > will leave out the exception branch and will only place a which deoptimizes > in case an exception needs to be thrown. > > > > This should have nothing to do with inlining. When doings tests about > that, be carefull not to pollute the profile for the second test with the > first one. > > You can change the bahviour of graal reagrding these things using > the UseExceptionProbabilityForOperations flag. > > > > -Gilles > > > > On Tue, Nov 12, 2013 at 11:49 PM, Tom Deneau wrote: > > I've noticed that if the graph I am compiling is simply a leaf method > which accesses an array, the target of a failing bounds check is a > DeoptimizeNode with reason=BoundsCheckException, action=InvalidateReprofile > > But if the method that is accessing the array is being inlined into > another method, the target of the failing bounds check is a ForeignCall to > createOutOfBoundsException followed by a branch to a DeoptimizeNode with > reason=NotCompiledExceptionHandler, action=InvalidateRecompile. > > Can someone explain this difference? > > -- Tom > > > > > > > From tom.deneau at amd.com Thu Dec 5 13:38:58 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 5 Dec 2013 21:38:58 +0000 Subject: getting newVariables in HSAILLIRGenerator Message-ID: We were playing around with hsail handling for a deoptimization node. As part of the codegen for the deopt node, we needed a couple of scratch registers so in our LIRGenerator we have @Override public void emitDeoptimize(Value actionAndReason, DeoptimizingNode deopting) { Variable scratch64 = newVariable(Kind.Object); Variable scratch32 = newVariable(Kind.Int); append(new DeoptimizeOp(actionAndReason, deopting, getMetaAccess(), scratch64, scratch32)); } and inside our HSAIL DeooptimizeOp we have @Use({REG, CONST}) protected Value actionAndReason; protected DeoptimizingNode deopting; protected MetaAccessProvider metaAccessProvider; @Temp({REG}) private AllocatableValue scratch64; @Temp({REG}) private AllocatableValue scratch32; However, maybe I am doing something wrong with the annotations because it seems that the register allocator will pick registers for scratch64, scratch32 that are really live. For instance, sometimes the deopt node is jumped to from various locations with different codes as shown below. In this case, the compiler assigned scratch32 to be $s0, but that should be considered in use coming from the @L12 block. @L12: mov_b32 $s0, -35; // ClassCastException brn @L14; @L14: // Deoptimization for Variable Reason, scratch64=d0|a, scratch32=s0|i ... deoptimize codegen follows -- Tom From tom.deneau at amd.com Thu Dec 5 14:06:52 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Thu, 5 Dec 2013 22:06:52 +0000 Subject: special handling for UnwindNode Message-ID: Hi -- For the hsail backend, we wanted to do some special handling for UnwindNode. The current UnwindNode has @Override public void generate(LIRGeneratorTool gen) { gen.emitUnwind(gen.operand(exception())); } So the LIRGenerators then have @Override public void emitUnwind(Value exception) { In our hsail handling, we would like to have access to the original exception ValueNode rather than the Value. (I don't really know, can one get back to the ValueNode given the Value?) As a dirty solution, we could stick some special handling in UnwindNode but for the long run I was thinking of how to do this without changing any of the base classes. I thought in the lowering stage we could replace UnwindNode with our own HSAILUnwindNode with its own generate routine that did something like @Override public void generate(LIRGeneratorTool gen) { gen.emitUnwind(exception()); } but saw that graph.replaceFixedWithFixed could not be used in this case because UnwindNode is not a FixedWithNextNode. Any other suggestions of how this could be done without changing the base classes? -- Tom From doug.simon at oracle.com Fri Dec 6 00:25:36 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 6 Dec 2013 09:25:36 +0100 Subject: getting newVariables in HSAILLIRGenerator In-Reply-To: References: Message-ID: Your use of the annotations for DeoptimizeOp look correct to me. What?s makes you say that $s0 really is live at the deopt in your example? Unless the deopt takes the ClassCastException value as an input (which does not appear to be the case), then it?s dead at the deopt (deopts are control flow sinks). If you?re still having problems, please send me the c1visualizer log for the compilation of this method (i.e. -G:Dump= -G:MethodFilter=). You?ll know what *.cfg file to send based on console output like this: CFGPrinter: Dumping method HotSpotMethod to compilations-1386318229050_2.cfg -Doug On Dec 5, 2013, at 10:38 PM, Deneau, Tom wrote: > We were playing around with hsail handling for a deoptimization node. > As part of the codegen for the deopt node, we needed a couple of scratch registers so in our LIRGenerator we have > > @Override > public void emitDeoptimize(Value actionAndReason, DeoptimizingNode deopting) { > Variable scratch64 = newVariable(Kind.Object); > Variable scratch32 = newVariable(Kind.Int); > append(new DeoptimizeOp(actionAndReason, deopting, getMetaAccess(), scratch64, scratch32)); > } > > and inside our HSAIL DeooptimizeOp we have > > @Use({REG, CONST}) protected Value actionAndReason; > protected DeoptimizingNode deopting; > protected MetaAccessProvider metaAccessProvider; > @Temp({REG}) private AllocatableValue scratch64; > @Temp({REG}) private AllocatableValue scratch32; > > However, maybe I am doing something wrong with the annotations because it seems that the register allocator will pick registers for scratch64, scratch32 that are really live. For instance, sometimes the deopt node is jumped to from various locations with different codes as shown below. In this case, the compiler assigned scratch32 to be $s0, but that should be considered in use coming from the @L12 block. > > > @L12: > mov_b32 $s0, -35; // ClassCastException > brn @L14; > > @L14: > // Deoptimization for Variable Reason, scratch64=d0|a, scratch32=s0|i > ... deoptimize codegen follows > > -- Tom > > From duboscq at ssw.jku.at Fri Dec 6 01:59:18 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 6 Dec 2013 10:59:18 +0100 Subject: special handling for UnwindNode In-Reply-To: References: Message-ID: Hello Tom, You should be able to use the lowering solution. Since it is a control sink node you can indeed not use replaceFixedWithFixed. However you can still replace such a node using something like what the canonicalizer does in this case: fixed.predecessor().replaceFirstSuccessor(fixed, canonical); GraphUtil.killCFG(fixed); where fixed is the "old" node (in your case the UnwindNode) and canonical is the "new" node (HSAILUnwindNode). Let us know if that work. In particular I'd be interested to know if you don't hit any corner case in the LoweringPhase when lowering control sink nodes. An other solution would be that we change the base unwind node. But the lowering solution doesn't seem that dirty to me. -Gilles On Thu, Dec 5, 2013 at 11:06 PM, Tom Deneau wrote: > Hi -- > > For the hsail backend, we wanted to do some special handling for > UnwindNode. > > The current UnwindNode has > > @Override > public void generate(LIRGeneratorTool gen) { > gen.emitUnwind(gen.operand(exception())); > } > > So the LIRGenerators then have > > @Override > public void emitUnwind(Value exception) { > > In our hsail handling, we would like to have access to the original > exception ValueNode rather than the Value. (I don't really know, can one > get back to the ValueNode given the Value?) > > As a dirty solution, we could stick some special handling in UnwindNode > but for the long run I was thinking of how to do this without changing any > of the base classes. > > I thought in the lowering stage we could replace UnwindNode with our own > HSAILUnwindNode with its own generate routine that did something like > @Override > public void generate(LIRGeneratorTool gen) { > gen.emitUnwind(exception()); > } > > but saw that graph.replaceFixedWithFixed could not be used in this case > because UnwindNode is not a FixedWithNextNode. > > Any other suggestions of how this could be done without changing the base > classes? > > -- Tom > > > > From doug.simon at oracle.com Fri Dec 6 02:00:17 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 6 Dec 2013 11:00:17 +0100 Subject: special handling for UnwindNode In-Reply-To: References: Message-ID: On Dec 5, 2013, at 11:06 PM, Deneau, Tom wrote: > Hi -- > > For the hsail backend, we wanted to do some special handling for UnwindNode. > > The current UnwindNode has > > @Override > public void generate(LIRGeneratorTool gen) { > gen.emitUnwind(gen.operand(exception())); > } > > So the LIRGenerators then have > > @Override > public void emitUnwind(Value exception) { > > In our hsail handling, we would like to have access to the original exception ValueNode rather than the Value. (I don't really know, can one get back to the ValueNode given the Value?) > > As a dirty solution, we could stick some special handling in UnwindNode but for the long run I was thinking of how to do this without changing any of the base classes. > > I thought in the lowering stage we could replace UnwindNode with our own HSAILUnwindNode Yes, that?s the right thing to do. > with its own generate routine that did something like > @Override > public void generate(LIRGeneratorTool gen) { > gen.emitUnwind(exception()); > } > > but saw that graph.replaceFixedWithFixed could not be used in this case because UnwindNode is not a FixedWithNextNode. You can use unwindNode.replaceAtPredecessor() instead. And there?s no need to replace the usages of an unwind node since there are none. -Doug From tom.deneau at amd.com Fri Dec 6 17:17:05 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Sat, 7 Dec 2013 01:17:05 +0000 Subject: getting newVariables in HSAILLIRGenerator In-Reply-To: References: Message-ID: Doug -- Here is the .cfg file. B22 is the common deopt point, jumped to from B21, B19, B18, etc. Each of those sets $s0 to a value corresponding to the actionAndReason. The scratch register we allocate is also $s0. -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Friday, December 06, 2013 2:26 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: getting newVariables in HSAILLIRGenerator Your use of the annotations for DeoptimizeOp look correct to me. What's makes you say that $s0 really is live at the deopt in your example? Unless the deopt takes the ClassCastException value as an input (which does not appear to be the case), then it's dead at the deopt (deopts are control flow sinks). If you're still having problems, please send me the c1visualizer log for the compilation of this method (i.e. -G:Dump= -G:MethodFilter=). You'll know what *.cfg file to send based on console output like this: CFGPrinter: Dumping method HotSpotMethod to compilations-1386318229050_2.cfg -Doug On Dec 5, 2013, at 10:38 PM, Deneau, Tom wrote: > We were playing around with hsail handling for a deoptimization node. > As part of the codegen for the deopt node, we needed a couple of scratch registers so in our LIRGenerator we have > > @Override > public void emitDeoptimize(Value actionAndReason, DeoptimizingNode deopting) { > Variable scratch64 = newVariable(Kind.Object); > Variable scratch32 = newVariable(Kind.Int); > append(new DeoptimizeOp(actionAndReason, deopting, getMetaAccess(), scratch64, scratch32)); > } > > and inside our HSAIL DeooptimizeOp we have > > @Use({REG, CONST}) protected Value actionAndReason; > protected DeoptimizingNode deopting; > protected MetaAccessProvider metaAccessProvider; > @Temp({REG}) private AllocatableValue scratch64; > @Temp({REG}) private AllocatableValue scratch32; > > However, maybe I am doing something wrong with the annotations because it seems that the register allocator will pick registers for scratch64, scratch32 that are really live. For instance, sometimes the deopt node is jumped to from various locations with different codes as shown below. In this case, the compiler assigned scratch32 to be $s0, but that should be considered in use coming from the @L12 block. > > > @L12: > mov_b32 $s0, -35; // ClassCastException > brn @L14; > > @L14: > // Deoptimization for Variable Reason, scratch64=d0|a, scratch32=s0|i > ... deoptimize codegen follows > > -- Tom > > From doug.simon at oracle.com Sat Dec 7 02:14:51 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 7 Dec 2013 11:14:51 +0100 Subject: getting newVariables in HSAILLIRGenerator In-Reply-To: References: Message-ID: Everything looks fine to me: B22 <- B21,B20,B19,B18 [-1, -1] _nr___st__instruction___________________________________________________________ (LIR) 194 [] = LABEL align: false label: ? 196 DEOPTIMIZE (x: -, actionAndReason: s0|i) {scratch64: d0|a, scratch32_1: s0|i, scratch32_2: s1|i} ? s0|i is an input to DEOPTIMIZE and also a temp for the same instruction. This complies with the definition of @Use and @Temp (see OperandMode.USE and OperandMode.TEMP). You just need to ensure the usage of these registers in the code generated for DEOPTIMIZE always complies with this usage pattern. -Doug On Dec 7, 2013, at 2:17 AM, Deneau, Tom wrote: > Doug -- > > Here is the .cfg file. B22 is the common deopt point, jumped to from B21, B19, B18, etc. Each of those sets $s0 to a value corresponding to the actionAndReason. The scratch register we allocate is also $s0. > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Friday, December 06, 2013 2:26 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: getting newVariables in HSAILLIRGenerator > > Your use of the annotations for DeoptimizeOp look correct to me. What's makes you say that $s0 really is live at the deopt in your example? Unless the deopt takes the ClassCastException value as an input (which does not appear to be the case), then it's dead at the deopt (deopts are control flow sinks). > > If you're still having problems, please send me the c1visualizer log for the compilation of this method (i.e. -G:Dump= -G:MethodFilter=). You'll know what *.cfg file to send based on console output like this: > > CFGPrinter: Dumping method HotSpotMethod to compilations-1386318229050_2.cfg > > -Doug > > On Dec 5, 2013, at 10:38 PM, Deneau, Tom wrote: > >> We were playing around with hsail handling for a deoptimization node. >> As part of the codegen for the deopt node, we needed a couple of scratch registers so in our LIRGenerator we have >> >> @Override >> public void emitDeoptimize(Value actionAndReason, DeoptimizingNode deopting) { >> Variable scratch64 = newVariable(Kind.Object); >> Variable scratch32 = newVariable(Kind.Int); >> append(new DeoptimizeOp(actionAndReason, deopting, getMetaAccess(), scratch64, scratch32)); >> } >> >> and inside our HSAIL DeooptimizeOp we have >> >> @Use({REG, CONST}) protected Value actionAndReason; >> protected DeoptimizingNode deopting; >> protected MetaAccessProvider metaAccessProvider; >> @Temp({REG}) private AllocatableValue scratch64; >> @Temp({REG}) private AllocatableValue scratch32; >> >> However, maybe I am doing something wrong with the annotations because it seems that the register allocator will pick registers for scratch64, scratch32 that are really live. For instance, sometimes the deopt node is jumped to from various locations with different codes as shown below. In this case, the compiler assigned scratch32 to be $s0, but that should be considered in use coming from the @L12 block. >> >> >> @L12: >> mov_b32 $s0, -35; // ClassCastException >> brn @L14; >> >> @L14: >> // Deoptimization for Variable Reason, scratch64=d0|a, scratch32=s0|i >> ... deoptimize codegen follows >> >> -- Tom >> >> > > > From tom.deneau at amd.com Sat Dec 7 10:10:33 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Sat, 7 Dec 2013 18:10:33 +0000 Subject: getting newVariables in HSAILLIRGenerator In-Reply-To: References: Message-ID: Doug -- OK, I just assumed that a TEMP newVariable would never conflict with a USE variable in the same block. So if I need a temp variable that never conflicts with any of the live variables in a block, how would I do that? Would annotating the actionAndReason in this case as ALIVE solve my problem? -- Tom -----Original Message----- From: Doug Simon [mailto:doug.simon at oracle.com] Sent: Saturday, December 07, 2013 4:15 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: getting newVariables in HSAILLIRGenerator Everything looks fine to me: B22 <- B21,B20,B19,B18 [-1, -1] _nr___st__instruction___________________________________________________________ (LIR) 194 [] = LABEL align: false label: ? 196 DEOPTIMIZE (x: -, actionAndReason: s0|i) {scratch64: d0|a, scratch32_1: s0|i, scratch32_2: s1|i} ... s0|i is an input to DEOPTIMIZE and also a temp for the same instruction. This complies with the definition of @Use and @Temp (see OperandMode.USE and OperandMode.TEMP). You just need to ensure the usage of these registers in the code generated for DEOPTIMIZE always complies with this usage pattern. -Doug On Dec 7, 2013, at 2:17 AM, Deneau, Tom wrote: > Doug -- > > Here is the .cfg file. B22 is the common deopt point, jumped to from B21, B19, B18, etc. Each of those sets $s0 to a value corresponding to the actionAndReason. The scratch register we allocate is also $s0. > > -- Tom > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Friday, December 06, 2013 2:26 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: getting newVariables in HSAILLIRGenerator > > Your use of the annotations for DeoptimizeOp look correct to me. What's makes you say that $s0 really is live at the deopt in your example? Unless the deopt takes the ClassCastException value as an input (which does not appear to be the case), then it's dead at the deopt (deopts are control flow sinks). > > If you're still having problems, please send me the c1visualizer log for the compilation of this method (i.e. -G:Dump= -G:MethodFilter=). You'll know what *.cfg file to send based on console output like this: > > CFGPrinter: Dumping method HotSpotMethod to compilations-1386318229050_2.cfg > > -Doug > > On Dec 5, 2013, at 10:38 PM, Deneau, Tom wrote: > >> We were playing around with hsail handling for a deoptimization node. >> As part of the codegen for the deopt node, we needed a couple of scratch registers so in our LIRGenerator we have >> >> @Override >> public void emitDeoptimize(Value actionAndReason, DeoptimizingNode deopting) { >> Variable scratch64 = newVariable(Kind.Object); >> Variable scratch32 = newVariable(Kind.Int); >> append(new DeoptimizeOp(actionAndReason, deopting, getMetaAccess(), scratch64, scratch32)); >> } >> >> and inside our HSAIL DeooptimizeOp we have >> >> @Use({REG, CONST}) protected Value actionAndReason; >> protected DeoptimizingNode deopting; >> protected MetaAccessProvider metaAccessProvider; >> @Temp({REG}) private AllocatableValue scratch64; >> @Temp({REG}) private AllocatableValue scratch32; >> >> However, maybe I am doing something wrong with the annotations because it seems that the register allocator will pick registers for scratch64, scratch32 that are really live. For instance, sometimes the deopt node is jumped to from various locations with different codes as shown below. In this case, the compiler assigned scratch32 to be $s0, but that should be considered in use coming from the @L12 block. >> >> >> @L12: >> mov_b32 $s0, -35; // ClassCastException >> brn @L14; >> >> @L14: >> // Deoptimization for Variable Reason, scratch64=d0|a, scratch32=s0|i >> ... deoptimize codegen follows >> >> -- Tom >> >> > > > From christian.thalinger at oracle.com Sat Dec 7 17:06:00 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sat, 7 Dec 2013 17:06:00 -0800 Subject: getting newVariables in HSAILLIRGenerator In-Reply-To: References: Message-ID: On Dec 7, 2013, at 10:10 AM, Deneau, Tom wrote: > Doug -- > > OK, I just assumed that a TEMP newVariable would never conflict with a USE variable in the same block. > So if I need a temp variable that never conflicts with any of the live variables in a block, how would I do that? > Would annotating the actionAndReason in this case as ALIVE solve my problem? Yes. See the documentation for ALIVE: A register assigned to it cannot be assigned to a {@link #TEMP} or {@link #DEF} operand. > > -- Tom > > > > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, December 07, 2013 4:15 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: getting newVariables in HSAILLIRGenerator > > Everything looks fine to me: > > B22 <- B21,B20,B19,B18 [-1, -1] > _nr___st__instruction___________________________________________________________ (LIR) > 194 [] = LABEL align: false label: ? > 196 DEOPTIMIZE (x: -, actionAndReason: s0|i) {scratch64: d0|a, scratch32_1: s0|i, scratch32_2: s1|i} ... > > s0|i is an input to DEOPTIMIZE and also a temp for the same instruction. This complies with the definition of @Use and @Temp (see OperandMode.USE and OperandMode.TEMP). You just need to ensure the usage of these registers in the code generated for DEOPTIMIZE always complies with this usage pattern. > > -Doug > > On Dec 7, 2013, at 2:17 AM, Deneau, Tom wrote: > >> Doug -- >> >> Here is the .cfg file. B22 is the common deopt point, jumped to from B21, B19, B18, etc. Each of those sets $s0 to a value corresponding to the actionAndReason. The scratch register we allocate is also $s0. >> >> -- Tom >> >> >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Friday, December 06, 2013 2:26 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: getting newVariables in HSAILLIRGenerator >> >> Your use of the annotations for DeoptimizeOp look correct to me. What's makes you say that $s0 really is live at the deopt in your example? Unless the deopt takes the ClassCastException value as an input (which does not appear to be the case), then it's dead at the deopt (deopts are control flow sinks). >> >> If you're still having problems, please send me the c1visualizer log for the compilation of this method (i.e. -G:Dump= -G:MethodFilter=). You'll know what *.cfg file to send based on console output like this: >> >> CFGPrinter: Dumping method HotSpotMethod to compilations-1386318229050_2.cfg >> >> -Doug >> >> On Dec 5, 2013, at 10:38 PM, Deneau, Tom wrote: >> >>> We were playing around with hsail handling for a deoptimization node. >>> As part of the codegen for the deopt node, we needed a couple of scratch registers so in our LIRGenerator we have >>> >>> @Override >>> public void emitDeoptimize(Value actionAndReason, DeoptimizingNode deopting) { >>> Variable scratch64 = newVariable(Kind.Object); >>> Variable scratch32 = newVariable(Kind.Int); >>> append(new DeoptimizeOp(actionAndReason, deopting, getMetaAccess(), scratch64, scratch32)); >>> } >>> >>> and inside our HSAIL DeooptimizeOp we have >>> >>> @Use({REG, CONST}) protected Value actionAndReason; >>> protected DeoptimizingNode deopting; >>> protected MetaAccessProvider metaAccessProvider; >>> @Temp({REG}) private AllocatableValue scratch64; >>> @Temp({REG}) private AllocatableValue scratch32; >>> >>> However, maybe I am doing something wrong with the annotations because it seems that the register allocator will pick registers for scratch64, scratch32 that are really live. For instance, sometimes the deopt node is jumped to from various locations with different codes as shown below. In this case, the compiler assigned scratch32 to be $s0, but that should be considered in use coming from the @L12 block. >>> >>> >>> @L12: >>> mov_b32 $s0, -35; // ClassCastException >>> brn @L14; >>> >>> @L14: >>> // Deoptimization for Variable Reason, scratch64=d0|a, scratch32=s0|i >>> ... deoptimize codegen follows >>> >>> -- Tom >>> >>> >> >> >> > > > From doug.simon at oracle.com Sat Dec 7 18:00:39 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 08 Dec 2013 02:00:39 +0000 Subject: hg: graal/graal: 54 new changesets Message-ID: <20131208020406.6378C62B68@hg.openjdk.java.net> Changeset: ffa3d2d26cc2 Author: Christos Kotselidis Date: 2013-12-02 12:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ffa3d2d26cc2 Ommit G1 Pre barrier in init writes of instance objects ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java Changeset: bef512e42262 Author: Christos Kotselidis Date: 2013-12-02 12:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bef512e42262 Merge Changeset: c2deb575483c Author: Andreas Woess Date: 2013-11-30 18:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c2deb575483c do not attempt to virtualize NewFrame if frame descriptor is not constant. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/nodes/frame/NewFrameNode.java Changeset: 9500ac5269ff Author: Andreas Woess Date: 2013-11-30 18:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9500ac5269ff add truffle tree dump handler in order to make tree dumping respect the method filter. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleTreeDumpHandler.java Changeset: 66d793d06465 Author: Andreas Woess Date: 2013-11-30 18:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/66d793d06465 print frame prologue reinstallation message only if TraceTruffleCompilation is enabled. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTarget.java Changeset: b96cc3b87e87 Author: Andreas Woess Date: 2013-12-02 13:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b96cc3b87e87 Merge ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java Changeset: 862a5d60a58a Author: Chris Seaton Date: 2013-12-02 23:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/862a5d60a58a Remove experimental warning on @ImplicitCast. ! graal/com.oracle.truffle.api.dsl/src/com/oracle/truffle/api/dsl/ImplicitCast.java Changeset: d862cb983214 Author: Christian Wimmer Date: 2013-12-02 14:19 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d862cb983214 Relax overly strict assertion ! graal/com.oracle.graal.word/src/com/oracle/graal/word/phases/WordTypeRewriterPhase.java Changeset: eb03a7335eb0 Author: Christian Wimmer Date: 2013-12-02 14:20 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/eb03a7335eb0 Use fixed instead of virtual register for target in far foreign call, since the register allocator does not support virtual registers to be used at call sites. ! graal/com.oracle.graal.api.code/src/com/oracle/graal/api/code/ValueUtil.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Call.java Changeset: d49e17387efc Author: Christian Wimmer Date: 2013-12-02 15:08 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d49e17387efc Merge Changeset: 3f34b8f91cc5 Author: twisti Date: 2013-12-02 20:05 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3f34b8f91cc5 moved CompilerToVM.isTypeInitialized and isTypeLinked to Java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: dca16b3416ab Author: Roland Schatz Date: 2013-12-03 11:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dca16b3416ab Don't peel counted loops. ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopPolicies.java Changeset: 51e97f88c771 Author: Roland Schatz Date: 2013-12-03 11:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/51e97f88c771 Profile deoptimizations of OSR methods separately. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! src/share/vm/oops/methodData.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/deoptimization.hpp Changeset: 210f58e992a1 Author: Roland Schatz Date: 2013-12-03 11:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/210f58e992a1 Use separate method profile for OSR compilations. ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/backend/AllocatorTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierAdditionTest.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/WriteBarrierVerificationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotProfilingInfo.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/OptimisticOptimizations.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/tiers/MidTierContext.java Changeset: 36864a23bc11 Author: Gilles Duboscq Date: 2013-12-02 18:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/36864a23bc11 Use ordinal check on guard stage in LoadHubNode.lower ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/LoadHubNode.java Changeset: fdc3925a8e74 Author: Gilles Duboscq Date: 2013-12-02 18:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fdc3925a8e74 IGV display an error message for any exception during port binding ! src/share/tools/IdealGraphVisualizer/NetworkConnection/src/com/sun/hotspot/igv/connection/Server.java Changeset: 2b43fcc68add Author: Gilles Duboscq Date: 2013-12-02 18:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2b43fcc68add Put _pending_deoptimization and _pending_monitorenter under ifdef GRAAL ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/graal/vmStructs_graal.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: d5c6d9beebe3 Author: Erik Eckstein Date: 2013-12-03 16:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d5c6d9beebe3 graph builder: fixed wrong liveness of locals in ExceptionObject???s frame state ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: de8f74d49690 Author: Erik Eckstein Date: 2013-12-03 16:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/de8f74d49690 rename Replacements.prepareSnippetCopyAfterInstantiation ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/Replacements.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/ReplacementsImpl.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 78c808233ff1 Author: Doug Simon Date: 2013-12-02 17:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/78c808233ff1 ensure instruction at verified entry point is safely patchable (GRAAL-605) ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! src/cpu/x86/vm/nativeInst_x86.cpp Changeset: 7086a2fe7370 Author: Doug Simon Date: 2013-12-03 09:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7086a2fe7370 renamed TargetMethodAssembler.finishTargetMethod to finalize and made its return type void ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java Changeset: f83540edfcd4 Author: Doug Simon Date: 2013-12-03 10:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f83540edfcd4 removed PTXTargetMethodAssembler ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java - graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java Changeset: 0b4d38339708 Author: Doug Simon Date: 2013-12-03 10:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0b4d38339708 moved CompilationResult metric updating out from TargetMethodAssembler.finish() ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java Changeset: 1a66453f73db Author: Doug Simon Date: 2013-12-03 10:51 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1a66453f73db renamed TargetMethodAssembler to CompilationResultBuilder ! graal/com.oracle.graal.asm/src/com/oracle/graal/asm/AbstractAssembler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCRuntimeCallEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotCRuntimeCallPrologueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotJumpToExceptionHandlerInCallerOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotMove.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotPatchReturnAddressOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotReturnOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotUnwindOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotspotDirectVirtualCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64IndirectCallOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64TailcallOp.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCDeoptimizeOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallEpilogueOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCRuntimeCallPrologueOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotDeoptimizeCallerOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotJumpToExceptionHandlerInCallerOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotPatchReturnAddressOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotReturnOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotUnwindOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectStaticCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotspotDirectVirtualCallOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCIndirectCallOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64BitManipulationOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64BreakpointOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ByteSwapOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Call.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Compare.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64LIRInstruction.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64MathIntrinsicOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64RestoreRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64SaveRegistersOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64TestOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ZapRegistersOp.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILBitManipulationOp.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILCompare.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILLIRInstruction.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILMove.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXArithmetic.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXBitManipulationOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXCompare.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXLIRInstruction.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMemOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXMove.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXParameterOp.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXTestOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCArithmetic.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBitManipulationOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCBreakpointOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCByteSwapOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCall.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCCompare.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCLIRInstruction.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMathIntrinsicOp.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCTestOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/InfopointOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRInstruction.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java < graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/FrameContext.java ! graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackend.java Changeset: 4568980f7257 Author: Doug Simon Date: 2013-12-03 11:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4568980f7257 removed GraalCompiler.compileGraphNoScope ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILCompilationResult.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 325b4e4efb60 Author: Doug Simon Date: 2013-12-03 16:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/325b4e4efb60 added CompilationResultBuilderFactory to support peep-hole instrumentation of methods as their code is emitted ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/target/Backend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILCompilationResult.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java + graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilderFactory.java ! graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackend.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 01080e31692d Author: Doug Simon Date: 2013-12-03 16:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/01080e31692d fixed crash when TraceCreateZombies is enabled ! src/share/vm/code/nmethod.cpp Changeset: dad021298158 Author: Doug Simon Date: 2013-12-03 16:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dad021298158 use CompilationResultBuilderFactory to do patching of OptimizedCallTarget.call() - graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackend.java - graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackendFactory.java + graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64OptimizedCallTargetInstrumentationFactory.java - graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/util/OptimizedCallTargetFieldInfo.java + graal/com.oracle.graal.truffle.hotspot/src/com/oracle/graal/truffle/hotspot/OptimizedCallTargetInstrumentation.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java + graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/OptimizedCallTargetInstrumentationFactory.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleBackendFactory.java ! mx/projects Changeset: f1f33d1ff3e2 Author: Doug Simon Date: 2013-12-03 16:53 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f1f33d1ff3e2 made instrumentation of OptimizedCallTarget.call() safe with respect to patching its verified entry point (GRAAL-605) ! graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64OptimizedCallTargetInstrumentationFactory.java Changeset: 8ea51438445c Author: Doug Simon Date: 2013-12-03 17:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8ea51438445c consolidated logging and dumping of InstalledCode to HotSpotCodeCacheProvider ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java Changeset: 7e237378923d Author: Doug Simon Date: 2013-12-03 18:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7e237378923d made the frameContext of a CompilationResultBuilder always non-null and added FrameContext.hasFrame() to determine if a frame is actually generated ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotReturnOp.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotReturnOp.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/FrameContext.java Changeset: 41f28bc4ac58 Author: Doug Simon Date: 2013-12-03 18:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/41f28bc4ac58 fixed frame omission tests to account for mt-safe patching prefix ! graal/com.oracle.graal.hotspot.amd64.test/src/com/oracle/graal/hotspot/amd64/test/AMD64HotSpotFrameOmissionTest.java Changeset: 25da0f4e5c77 Author: Doug Simon Date: 2013-12-03 18:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/25da0f4e5c77 added extra space to disassembler buffer to account for disassembly header ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: bc1b0ff498f4 Author: Doug Simon Date: 2013-12-03 18:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bc1b0ff498f4 removed no longer needed dependency from c.o.g.compiler.ptx to c.o.g.hotspot ! mx/projects Changeset: b429ec5c46d6 Author: Doug Simon Date: 2013-12-03 18:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b429ec5c46d6 Merge. ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Call.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: bb35fc7e0d68 Author: Doug Simon Date: 2013-12-03 18:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bb35fc7e0d68 Merge. ! graal/com.oracle.graal.compiler.ptx.test/src/com/oracle/graal/compiler/ptx/test/PTXTestBase.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/GraalCompilerTest.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/InfopointReasonTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILCompilationResult.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/Stub.java ! graal/com.oracle.graal.java.decompiler.test/src/com/oracle/graal/java/decompiler/test/TestUtil.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/GraalTruffleRuntime.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerImpl.java ! mx/projects Changeset: 3543861aeeb2 Author: Doug Simon Date: 2013-12-03 18:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3543861aeeb2 fixes for eclipseformat ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Move.java Changeset: 8b5852df0471 Author: twisti Date: 2013-12-03 14:48 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/8b5852df0471 remove CompilerToVM.initializeMethodData ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 65c0f2ec1ad7 Author: twisti Date: 2013-12-03 20:28 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/65c0f2ec1ad7 added type to HotSpotVMField annotation in order to verify the expected type ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMField.java Changeset: 68529068f08e Author: Gilles Duboscq Date: 2013-12-04 14:54 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/68529068f08e Update eclipse config when files in eclipse-settings have changed ! mxtool/mx.py Changeset: 6140eda73e6f Author: Doug Simon Date: 2013-12-04 16:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6140eda73e6f make launching IGV with jdk8 issue an error message (GRAAL-420) ! mx/mx_graal.py Changeset: af7d328b2cc7 Author: Doug Simon Date: 2013-12-04 16:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/af7d328b2cc7 minor renamings ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java Changeset: 0909754d87f4 Author: Doug Simon Date: 2013-12-04 16:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0909754d87f4 tightened assertion about lowering a floating node with unscheduled usages to cases where it really matters ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: e709633d87c6 Author: Gilles Duboscq Date: 2013-12-04 14:58 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e709633d87c6 Use java compilance from project in eclipse settings for compilance, source and target Use java compilance for the target when building with javac Use java compilance for the JRE_CONTAINER in eclipse .classpath ! mx/eclipse-settings/org.eclipse.jdt.core.prefs ! mxtool/mx.py Changeset: f89188646695 Author: Gilles Duboscq Date: 2013-12-04 17:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f89188646695 Remove warnings about forbidden and discouraged accesses in eclipse ! mx/eclipse-settings/org.eclipse.jdt.core.prefs Changeset: ff43107fd697 Author: Doug Simon Date: 2013-12-04 22:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ff43107fd697 addressed compilation issue in Eclipse with JDT BETA_JAVA8 ! graal/com.oracle.graal.api.meta.jdk8.test/src/com/oracle/graal/api/meta/jdk8/test/TestResolvedJavaMethodJDK8.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/MethodUniverse.java ! graal/com.oracle.graal.api.meta.test/src/com/oracle/graal/api/meta/test/TestResolvedJavaMethod.java Changeset: ca061aaeddaf Author: twisti Date: 2013-12-04 17:22 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ca061aaeddaf added Math.pow method substitution with code for handling some special cases ! graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/lang/Math_pow.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java Changeset: 3a8a4042229f Author: Roland Schatz Date: 2013-12-05 12:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3a8a4042229f Refactor emission of compare op. ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java Changeset: 5d2bc83e9d22 Author: Doug Simon Date: 2013-12-05 15:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5d2bc83e9d22 force long encoding of frame push instruction in a method without a stack bang; removed -G:StackShadowPages option ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java Changeset: 4d1cd29cceb0 Author: twisti Date: 2013-12-05 11:57 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/4d1cd29cceb0 make SPARC run again ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotCodeCacheProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java Changeset: 42aaf7306707 Author: twisti Date: 2013-12-05 18:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/42aaf7306707 Teach Graal about Symbol and ConstantPool so we can move more logic into Java. We'll see how that ends... ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ConstantPool.java + graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/HotSpotResolvedObjectTypeTest.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotSymbol.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodUnresolved.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 785bbb619238 Author: Tom Rodriguez Date: 2013-12-07 19:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/785bbb619238 Basic allocation prefetching support ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64PrefetchOp.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java + graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCPrefetchOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/nodes/PrefetchAllocateNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java Changeset: 14100434f421 Author: Tom Rodriguez Date: 2013-12-07 19:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/14100434f421 fixed uses of Value.ILLEGAL ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXAddressValue.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCMove.java Changeset: 4eacfd0767ed Author: twisti Date: 2013-12-05 19:28 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/4eacfd0767ed get deoptimization constants in HotSpotMetaAccessProvider from HotSpotVMConfig ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java ! src/share/vm/runtime/vmStructs.cpp From java at stefan-marr.de Mon Dec 9 07:10:29 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 9 Dec 2013 16:10:29 +0100 Subject: TruffleSOM with SimpleLanguage-Style Call Caches Message-ID: <19E36787-D531-4D08-8C42-EB4C8AA5BA7D@stefan-marr.de> Hi: I finally got around to change TruffleSOM to use call caching and inlining based on the new SimpleLanguage examples. The current version uses specialized classes for unary, binary, ternary, and keyword messages to allow for a specialization of messages for primitive operations based on the argument types. So, this part of the design hasn?t changed much from the last iteration. However, the way primitive operations (?builtins? in SL terminology) are handled has changed. Below, you?ll find a brief comparison of the last two design iterations, and my observations, and at the end, I got another of those ?escaping frames? issues, I haven?t been able to solve yet. Direct vs. Indirect Monomorphic Checking ???????????????????????????????????????- In the last design iteration, I tried to use the polymorphic behavior of nodes supported by the TruffleDSL to my advantage. However, since state-based guards are currently not supported, it was not possible to implement the check for a monomorphic send using only the TruffleDSL. However, I think, the general design might still have a few benefits, since it avoids an additional node in the AST. To make that a little more explicit, let?s consider the following example: Calculator>>#add: a to: b = ( ^ a + b ) This would result in an AST roughly looking like this: Method(RootNode) +- BinaryMessage +- receiver = FieldReadNode +- argument = FieldReadNode After specialization, it would look like this: Method(RootNode) +- AdditionPrimNodeInteger (next)-> AdditionPrimNodeDouble (next)-> AdditionPrimNodeUninitialized +- receiver = FieldReadNode +- argument = FieldReadNode Now, the DSL is currently not able to support my approach of having this unified with standard inline caching for instance in case Strings are ?added?, were ?+? is not implemented in AdditionPrimNode as a specialization but as a normal Smalltalk method. So, I switched to the SimpleLanguage approach, and now the AST looks like this after specialization: Method(RootNode) +- BinarySendNode$CachedSendNode (current)-> AdditionPrimNodeInteger (next)-> BinarySendNode$CachedSendNode (current)-> AdditionPrimNodeDouble (next)-> BinarySendNode$CachedSendNode (current)-> BinarySendNode$InlinableSendNode (callTarget)-> (String>>#+:) (next)-> BinarySendNode$UninitializedNode +- receiver = FieldReadNode +- argument = FieldReadNode The nice thing about this design is that the whole question of monomorphic sends is completely handled by the *SendNode?s CachedSendNode implementations. And then, all kind of specialization happens after that. However, I am not sure whether this indirection is unproblematic for compilation. Another problem is that in my current implementation much of the SendNode implementations is duplicated code, slightly adapted to the different types and signatures for the Unary/Binary/Ternary/Keyword message nodes. Similarly, the specialization for the n-ary message nodes also forces me to duplicated code for the variants for inlined methods. All in all, not very nice, but with Java?s restricted support for generics, I also don?t see a lot of options to avoid it. Escaping Frames ??????????????- Following previous experiences with Graal reporting escaping frames, I tried to identify all loops that lead to a call to `executeGeneric(.)` to make sure they are marked with @ExplodeLoop. However, in this case I either missed one or this strategy is not sufficient. Any other general strategies that would help to identify potential issues for escaping frames? Thanks Stefan The latest code can be obtained with: git clone --recursive https://github.com/smarr/TruffleSOM.git cd TruffleSOM ant jar cd $GRAAL ./mx.sh --vm server vm -Xbootclasspath/a:../TruffleSOM/build/classes:$SOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../TruffleSOM/Smalltalk ../TruffleSOM/Examples/Benchmarks/Loop.som -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From Eric.Caspole at amd.com Mon Dec 9 16:31:29 2013 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Tue, 10 Dec 2013 00:31:29 +0000 Subject: Webrev for throwing some exceptions from HSAIL Message-ID: Hi everybody, Tom and I came up with our first baby steps of throwing exceptions from HSAIL kernels back into "regular" java. This is for the context of running as a parallel stream such as a parallel().forEach(). This works such that the first kernel workitem to set an atomic after detecting a problem "wins" to report the exception back to java. The kernel workitems that detect a problem return early even if they lose to set the flag, and the others run on normally. This is about the same as you get with CPU parallel streams. http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/ We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via explicit checks in the HSAIL code, and return a deoptimization reason to the CPU side. In the JVM kernel launch code, we check for these exceptions, then save the method, reason and bci in the thread, then throw using the THROW/CHECK mechanism from C++ back to java. When the thread later gets to fillInStackTrace, it uses the saved info in the thread to add the kernel lambda method as the top frame in the stack trace. Let us know what you think. Thanks, Eric From doug.simon at oracle.com Tue Dec 10 04:03:11 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 Dec 2013 13:03:11 +0100 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: References: Message-ID: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Hi Eric, Apart from the Eclipse errors and warnings (see below), the Java code looks ok. gpu_hsail.cpp: inline void init() { Why a separate init() function for HSAILKernelException? Seems like an inline constructor would do the same thing. thread->set_gpu_exception_method(mh()); If the exception happens in an inlined method, then mh() is the wrong value here (and bci will be wrong as well). gpu_hsail.hpp: static bool execute_kernel_void_1d(address kernel, int dimX, jobject args, methodHandle mh, TRAPS); Why is the mh parameter no longer passed by reference? -Doug Description Resource Path Location Type The import com.oracle.graal.api.code is never used HSAILControlFlow.java /com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail line 36 Java Problem The value of the field HSAILHotSpotLoweringProvider.host is not used HSAILHotSpotLoweringProvider.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 39 Java Problem 'abstract' modifier out of order with the JLS suggestions. HSAILHotSpotLoweringProvider.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 41 Checkstyle Problem The value of the local variable bci is not used HSAILHotSpotLIRGenerator.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 222 Java Problem Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 42 Checkstyle Problem Line matches the illegal pattern 'System\.(out|err)\.print'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 73 Checkstyle Problem The import java.lang.reflect is never used HSAILAssembler.java /com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail line 26 Java Problem The import com.oracle.graal.debug.internal is never used HSAILCompilationResult.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 37 Java Problem First sentence should end with a period. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 14 Checkstyle Problem Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 27 Checkstyle Problem Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 27 Checkstyle Problem Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 42 Checkstyle Problem The import org.junit.Assert.assertTrue is never used ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 11 Java Problem Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 2 Checkstyle Problem First sentence should end with a period. BoundsCheckTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 29 Checkstyle Problem The import java.util.Arrays is never used ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 9 Java Problem Line matches the illegal pattern 'System\.(out|err)\.print'. BoundsCheckTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 67 Checkstyle Problem On Dec 10, 2013, at 1:31 AM, Caspole, Eric wrote: > Hi everybody, > Tom and I came up with our first baby steps of throwing exceptions from HSAIL kernels back into "regular" java. This is for the context of running as a parallel stream such as a parallel().forEach(). This works such that the first kernel workitem to set an atomic after detecting a problem "wins" to report the exception back to java. The kernel workitems that detect a problem return early even if they lose to set the flag, and the others run on normally. This is about the same as you get with CPU parallel streams. > > http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/ > > We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via explicit checks in the HSAIL code, and return a deoptimization reason to the CPU side. In the JVM kernel launch code, we check for these exceptions, then save the method, reason and bci in the thread, then throw using the THROW/CHECK mechanism from C++ back to java. When the thread later gets to fillInStackTrace, it uses the saved info in the thread to add the kernel lambda method as the top frame in the stack trace. > > Let us know what you think. > Thanks, > Eric > From chris at chrisseaton.com Tue Dec 10 06:42:00 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Tue, 10 Dec 2013 14:42:00 +0000 Subject: TruffleSOM with SimpleLanguage-Style Call Caches In-Reply-To: <19E36787-D531-4D08-8C42-EB4C8AA5BA7D@stefan-marr.de> References: <19E36787-D531-4D08-8C42-EB4C8AA5BA7D@stefan-marr.de> Message-ID: Hello Stefan, What's the difference between Unary, Binary and Ternary send nodes? Did you see a need to differentiate between them? They all have arrays of children, so it's not removing the array indirection. Is it so that executedEvaluated can have parameters for each child and you don't need to create an array? I would just use an Object[] here. I used to have Unary, Binary and Ternary method calls in Ruby, but got rid of them one day and couldn't see any performance difference when running on Graal (not just any statistically significant difference - literally no difference), with the benefit of a drastically simpler model. I wouldn't worry about the number of nodes. Certainly having just one extra would never cross my mind as an issue. It may make interpreted performance a little better to have fewer, but really good compiled performance when you start to run on Graal relies on many minimal nodes with maximal specialisations. In Ruby lots of operations that look primitive and irreducible are made up of several nodes. If you have n nodes of complexity c that each specialise in k ways you have n^k possible configurations in space cnk. To have the same number of configurations with a single node requires space cn^k, which you probably aren't going to bother to do. So I always maximise n and k and minimise c. With escaping frames you mention @ExplodeLoop; you also know about @SlowPath, right? Regards, Chris On 9 December 2013 15:10, Stefan Marr wrote: > Hi: > > I finally got around to change TruffleSOM to use call caching and inlining > based on the new SimpleLanguage examples. > The current version uses specialized classes for unary, binary, ternary, > and keyword messages to allow for a specialization of messages for > primitive operations based on the argument types. So, this part of the > design hasn?t changed much from the last iteration. However, the way > primitive operations (?builtins? in SL terminology) are handled has changed. > > Below, you?ll find a brief comparison of the last two design iterations, > and my observations, and at the end, I got another of those ?escaping > frames? issues, I haven?t been able to solve yet. > > Direct vs. Indirect Monomorphic Checking > ???????????????????????????????????????- > > In the last design iteration, I tried to use the polymorphic behavior of > nodes supported by the TruffleDSL to my advantage. However, since > state-based guards are currently not supported, it was not possible to > implement the check for a monomorphic send using only the TruffleDSL. > However, I think, the general design might still have a few benefits, since > it avoids an additional node in the AST. To make that a little more > explicit, let?s consider the following example: > > Calculator>>#add: a to: b = ( ^ a + b ) > > This would result in an AST roughly looking like this: > > Method(RootNode) > +- BinaryMessage > +- receiver = FieldReadNode > +- argument = FieldReadNode > > After specialization, it would look like this: > > Method(RootNode) > +- AdditionPrimNodeInteger > (next)-> AdditionPrimNodeDouble > (next)-> AdditionPrimNodeUninitialized > +- receiver = FieldReadNode > +- argument = FieldReadNode > > Now, the DSL is currently not able to support my approach of having this > unified with standard inline caching for instance in case Strings are > ?added?, were ?+? is not implemented in AdditionPrimNode as a > specialization but as a normal Smalltalk method. > > So, I switched to the SimpleLanguage approach, and now the AST looks like > this after specialization: > > Method(RootNode) > +- BinarySendNode$CachedSendNode (current)-> AdditionPrimNodeInteger > (next)-> BinarySendNode$CachedSendNode (current)-> > AdditionPrimNodeDouble > (next)-> BinarySendNode$CachedSendNode (current)-> > BinarySendNode$InlinableSendNode (callTarget)-> (String>>#+:) > (next)-> BinarySendNode$UninitializedNode > +- receiver = FieldReadNode > +- argument = FieldReadNode > > The nice thing about this design is that the whole question of monomorphic > sends is completely handled by the *SendNode?s CachedSendNode > implementations. And then, all kind of specialization happens after that. > However, I am not sure whether this indirection is unproblematic for > compilation. > > Another problem is that in my current implementation much of the SendNode > implementations is duplicated code, slightly adapted to the different types > and signatures for the Unary/Binary/Ternary/Keyword message nodes. > Similarly, the specialization for the n-ary message nodes also forces me > to duplicated code for the variants for inlined methods. All in all, not > very nice, but with Java?s restricted support for generics, I also don?t > see a lot of options to avoid it. > > > Escaping Frames > ??????????????- > > Following previous experiences with Graal reporting escaping frames, I > tried to identify all loops that lead to a call to `executeGeneric(.)` to > make sure they are marked with @ExplodeLoop. However, in this case I either > missed one or this strategy is not sufficient. > > Any other general strategies that would help to identify potential issues > for escaping frames? > > Thanks > Stefan > > The latest code can be obtained with: > > git clone --recursive https://github.com/smarr/TruffleSOM.git > cd TruffleSOM > ant jar > cd $GRAAL > ./mx.sh --vm server vm > -Xbootclasspath/a:../TruffleSOM/build/classes:$SOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar > som.vm.Universe -cp ../TruffleSOM/Smalltalk > ../TruffleSOM/Examples/Benchmarks/Loop.som > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From java at stefan-marr.de Tue Dec 10 07:02:51 2013 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 10 Dec 2013 16:02:51 +0100 Subject: TruffleSOM with SimpleLanguage-Style Call Caches In-Reply-To: References: <19E36787-D531-4D08-8C42-EB4C8AA5BA7D@stefan-marr.de> Message-ID: Hi Chris: On 10 Dec 2013, at 15:41, Chris Seaton wrote: > What's the difference between Unary, Binary and Ternary send nodes? Did you see a need to differentiate between them? They all have arrays of children, so it?s not removing the array indirection. I rely on the argument array for Binary and Ternary because Christian suggested it, and I think, it is not supposed to make a difference. But indeed, at the moment, it is rather pointless to have the array there. I wasn?t able to unify more of the code, so, I could remove the indirection, and make the code slightly nicer. > Is it so that executedEvaluated can have parameters for each child and you don?t need to create an array? Yes indeed. The main goal was to enable specialization for primitive operations. I wanted to get the addition to be handled directly like this: public abstract class AdditionPrim extends ArithmeticPrim { public AdditionPrim(final SSymbol selector, final Universe universe) { super(selector, universe); } public AdditionPrim(final AdditionPrim node) { this(node.selector, node.universe); } @Specialization(order = 1) public int doInteger(final int left, final int argument) { return left + argument; } ? } And, in the previous design, such specialization would also have had the guard for the monomorphic send (which is here implicit, because if it is an `int`, its and `int`, no other check needed?) That way, a message send for a #+ would have ideally had as few indirection and nodes as possible. In the best case, the AdditionPrim node would really have been the direct node. And perhaps with polymorphic cases, it would have had another node in the next pointer chain. With the new design, the polymorphic check is always down in an extra node. Which might contribute to clarity, but introduces a redundant check for this primitive. So, well, I am not extremely happy with it, but it is ok. Back to the original question, yes, I need the distinction between the nodes to have the explicit and simple parameters here for doInteger, just two plain ints. Don?t know how reach this state with more generic code. > I would just use an Object[] here. I used to have Unary, Binary and Ternary method calls in Ruby, but got rid of them one day and couldn?t see any performance difference when running on Graal (not just any statistically significant difference - literally no difference), with the benefit of a drastically simpler model. Yes, the code gets ugly, and, I have a lot of code duplication that I do not like. > I wouldn't worry about the number of nodes. Certainly having just one extra would never cross my mind as an issue. It may make interpreted performance a little better to have fewer, but really good compiled performance when you start to run on Graal relies on many minimal nodes with maximal specialisations. In Ruby lots of operations that look primitive and irreducible are made up of several nodes. Well, not sure whether the extra indirection with the cached nodes is problematic, but at least in case of the primitive operations, the check for the monomorphic send is redundant. > With escaping frames you mention @ExplodeLoop; you also know about @SlowPath, right? Yes, but I don?t know how to use that properly. And what typical places should be where to use it, especially within nodes. What I already learned is that anything that returns a node should not be annotated with @SlowPath, because that prevents the partial evaluator to see the concrete return type, which leads to undesired virtual calls (causing escaping blocks). Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From duboscq at ssw.jku.at Tue Dec 10 07:05:21 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 10 Dec 2013 16:05:21 +0100 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: Hi Eric, The deoptimization mechanism and the exception mechanism are two completely different things. When a deoptimization happens, your only choice is to restart execution in the interpreter. To do so, the deoptimization points are decorated with LIRFrameState in the backend. This LIRFrameState gives you information that allow to rebuild the interpreter frames. For each frame you have a method, a bci, the stack and local values and the owned monitors. Once a deoptimization happened you can not just throw an exception because the deoptimization informations will not tell you where the problem actually happened, it is also not guaranteed that you have a meaningful exception to throw corresponding to the deoptimization reason and it is not even guaranteed that there actually was any problem at all! I think this was the reason you were using OptimisticOptimizations.NONE previously which should get rid of most deoptimizations and get exceptions instead. But i suspect it was not really used everywhere which could cause problems such as the "not compiled exception handler" deopt reason. Maybe we should try to have a look at those things together over Skype (my username is gilwooden) or something similar. -Gilles On Tue, Dec 10, 2013 at 1:03 PM, Doug Simon wrote: > Hi Eric, > > Apart from the Eclipse errors and warnings (see below), the Java code > looks ok. > > gpu_hsail.cpp: > > inline void init() { > > Why a separate init() function for HSAILKernelException? Seems like an > inline constructor would do the same thing. > > thread->set_gpu_exception_method(mh()); > > If the exception happens in an inlined method, then mh() is the wrong > value here (and bci will be wrong as well). > > gpu_hsail.hpp: > > static bool execute_kernel_void_1d(address kernel, int dimX, jobject > args, methodHandle mh, TRAPS); > > Why is the mh parameter no longer passed by reference? > > -Doug > > Description Resource Path Location Type > The import com.oracle.graal.api.code is never used > HSAILControlFlow.java > /com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail line 36 > Java Problem > The value of the field HSAILHotSpotLoweringProvider.host is not used > HSAILHotSpotLoweringProvider.java > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > line 39 Java Problem > 'abstract' modifier out of order with the JLS suggestions. > HSAILHotSpotLoweringProvider.java > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > line 41 Checkstyle Problem > The value of the local variable bci is not used > HSAILHotSpotLIRGenerator.java > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > line 222 Java Problem > Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 42 Checkstyle Problem > Line matches the illegal pattern 'System\.(out|err)\.print'. > ClassCastTest.java > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 73 Checkstyle Problem > The import java.lang.reflect is never used HSAILAssembler.java > /com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail line 26 > Java Problem > The import com.oracle.graal.debug.internal is never used > HSAILCompilationResult.java > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > line 37 Java Problem > First sentence should end with a period. ClassCastTest.java > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 14 Checkstyle Problem > Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 27 Checkstyle Problem > Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 27 Checkstyle Problem > Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 42 Checkstyle Problem > The import org.junit.Assert.assertTrue is never used ClassCastTest.java > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 11 Java Problem > Line does not match expected header line of ' \* Copyright \(c\) > (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights > reserved.'. ClassCastTest.java > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 2 Checkstyle Problem > First sentence should end with a period. BoundsCheckTest.java > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 29 Checkstyle Problem > The import java.util.Arrays is never used ClassCastTest.java > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 9 Java Problem > Line matches the illegal pattern 'System\.(out|err)\.print'. > BoundsCheckTest.java > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test > line 67 Checkstyle Problem > > > > On Dec 10, 2013, at 1:31 AM, Caspole, Eric wrote: > > > Hi everybody, > > Tom and I came up with our first baby steps of throwing exceptions from > HSAIL kernels back into "regular" java. This is for the context of running > as a parallel stream such as a parallel().forEach(). This works such that > the first kernel workitem to set an atomic after detecting a problem "wins" > to report the exception back to java. The kernel workitems that detect a > problem return early even if they lose to set the flag, and the others run > on normally. This is about the same as you get with CPU parallel streams. > > > > http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/< > http://cr.openjdk.java.net/%7Eecaspole/hsail_exceptions/> > > > > We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via > explicit checks in the HSAIL code, and return a deoptimization reason to > the CPU side. In the JVM kernel launch code, we check for these exceptions, > then save the method, reason and bci in the thread, then throw using the > THROW/CHECK mechanism from C++ back to java. When the thread later gets to > fillInStackTrace, it uses the saved info in the thread to add the kernel > lambda method as the top frame in the stack trace. > > > > Let us know what you think. > > Thanks, > > Eric > > > > From java at stefan-marr.de Tue Dec 10 07:51:55 2013 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 10 Dec 2013 16:51:55 +0100 Subject: TruffleSOM with SimpleLanguage-Style Call Caches In-Reply-To: References: <19E36787-D531-4D08-8C42-EB4C8AA5BA7D@stefan-marr.de> Message-ID: Hi: On 10 Dec 2013, at 16:02, Stefan Marr wrote: >> What's the difference between Unary, Binary and Ternary send nodes? Did you see a need to differentiate between them? They all have arrays of children, so it?s not removing the array indirection. > > I rely on the argument array for Binary and Ternary because Christian suggested it, and I think, it is not supposed to make a difference. But indeed, at the moment, it is rather pointless to have the array there. > I wasn?t able to unify more of the code, so, I could remove the indirection, and make the code slightly nicer. And removing that generalization fixes my issue with escaping frames :) https://github.com/smarr/TruffleSOM/commit/48b24271d8c0ea7be24523f154cbb7e9493c593b But the result is really slow. I have seen better numbers previously. Fibonacci for instance was already 3x faster. Did any of the heuristics or thresholds change? Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From chris at chrisseaton.com Tue Dec 10 08:04:36 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Tue, 10 Dec 2013 16:04:36 +0000 Subject: TruffleSOM with SimpleLanguage-Style Call Caches In-Reply-To: References: <19E36787-D531-4D08-8C42-EB4C8AA5BA7D@stefan-marr.de> Message-ID: I use @SlowPath on any method that don't want inlined because I know due to code size it's not worth inlining (but this is rare), or where I need recursion (for example Ruby's puts method recurses into Arrays as it pretty prints them). You say you've used it where you are returning a node, but if you are returning nodes from methods you probably want to already be back in the interpreter via SlowPathException or transferToInterpreter. I'm not aware of any changes in heuristics of thresholds, sorry. Chris On 10 December 2013 15:51, Stefan Marr wrote: > Hi: > > On 10 Dec 2013, at 16:02, Stefan Marr wrote: > > >> What's the difference between Unary, Binary and Ternary send nodes? Did > you see a need to differentiate between them? They all have arrays of > children, so it?s not removing the array indirection. > > > > I rely on the argument array for Binary and Ternary because Christian > suggested it, and I think, it is not supposed to make a difference. But > indeed, at the moment, it is rather pointless to have the array there. > > I wasn?t able to unify more of the code, so, I could remove the > indirection, and make the code slightly nicer. > > And removing that generalization fixes my issue with escaping frames :) > > > https://github.com/smarr/TruffleSOM/commit/48b24271d8c0ea7be24523f154cbb7e9493c593b > > But the result is really slow. I have seen better numbers previously. > Fibonacci for instance was already 3x faster. > > Did any of the heuristics or thresholds change? > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From eric.caspole at amd.com Tue Dec 10 08:03:37 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Tue, 10 Dec 2013 11:03:37 -0500 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: <52A73B59.5080904@amd.com> Hi Doug, I am cross-posting this to sumatra-dev since exceptions might be interesting to that audience, I should have done it at first. On 12/10/2013 07:03 AM, Doug Simon wrote: > Hi Eric, > > Apart from the Eclipse errors and warnings (see below), the Java code looks ok. How do you get those errors and warnings shown below? I ran "mx eclipseformat -e /opt/eclipse4.3.1/" which I thought was right, and I just see 2 little comment reformatting things. Normally I use NetBeans 7.4, it already supports JDK 8, from your own company :) Either way I will fix those things. > > gpu_hsail.cpp: > > inline void init() { > > Why a separate init() function for HSAILKernelException? Seems like an inline constructor would do the same thing. > Yes I agree, that would be better. > thread->set_gpu_exception_method(mh()); > > If the exception happens in an inlined method, then mh() is the wrong value here (and bci will be wrong as well). Yes that is true. We are still investigating how to do the debug info for HSAIL code and will get more into that in the next weeks. Then we will be able to have better unwind features and so on. > > gpu_hsail.hpp: > > static bool execute_kernel_void_1d(address kernel, int dimX, jobject args, methodHandle mh, TRAPS); > > Why is the mh parameter no longer passed by reference? That is a typo, I will fix it. Thanks for your comments, Eric > > -Doug > > Description Resource Path Location Type > The import com.oracle.graal.api.code is never used HSAILControlFlow.java /com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail line 36 Java Problem > The value of the field HSAILHotSpotLoweringProvider.host is not used HSAILHotSpotLoweringProvider.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 39 Java Problem > 'abstract' modifier out of order with the JLS suggestions. HSAILHotSpotLoweringProvider.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 41 Checkstyle Problem > The value of the local variable bci is not used HSAILHotSpotLIRGenerator.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 222 Java Problem > Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 42 Checkstyle Problem > Line matches the illegal pattern 'System\.(out|err)\.print'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 73 Checkstyle Problem > The import java.lang.reflect is never used HSAILAssembler.java /com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail line 26 Java Problem > The import com.oracle.graal.debug.internal is never used HSAILCompilationResult.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 37 Java Problem > First sentence should end with a period. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 14 Checkstyle Problem > Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 27 Checkstyle Problem > Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 27 Checkstyle Problem > Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 42 Checkstyle Problem > The import org.junit.Assert.assertTrue is never used ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 11 Java Problem > Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 2 Checkstyle Problem > First sentence should end with a period. BoundsCheckTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 29 Checkstyle Problem > The import java.util.Arrays is never used ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 9 Java Problem > Line matches the illegal pattern 'System\.(out|err)\.print'. BoundsCheckTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 67 Checkstyle Problem > > > > On Dec 10, 2013, at 1:31 AM, Caspole, Eric wrote: > >> Hi everybody, >> Tom and I came up with our first baby steps of throwing exceptions from HSAIL kernels back into "regular" java. This is for the context of running as a parallel stream such as a parallel().forEach(). This works such that the first kernel workitem to set an atomic after detecting a problem "wins" to report the exception back to java. The kernel workitems that detect a problem return early even if they lose to set the flag, and the others run on normally. This is about the same as you get with CPU parallel streams. >> >> http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/ >> >> We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via explicit checks in the HSAIL code, and return a deoptimization reason to the CPU side. In the JVM kernel launch code, we check for these exceptions, then save the method, reason and bci in the thread, then throw using the THROW/CHECK mechanism from C++ back to java. When the thread later gets to fillInStackTrace, it uses the saved info in the thread to add the kernel lambda method as the top frame in the stack trace. >> >> Let us know what you think. >> Thanks, >> Eric >> > > From doug.simon at oracle.com Tue Dec 10 08:22:16 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 Dec 2013 17:22:16 +0100 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: <52A73B59.5080904@amd.com> References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> <52A73B59.5080904@amd.com> Message-ID: On Dec 10, 2013, at 5:03 PM, Eric Caspole wrote: > Hi Doug, > I am cross-posting this to sumatra-dev since exceptions might be interesting to that audience, I should have done it at first. > > On 12/10/2013 07:03 AM, Doug Simon wrote: >> Hi Eric, >> >> Apart from the Eclipse errors and warnings (see below), the Java code looks ok. > > How do you get those errors and warnings shown below? I ran > > "mx eclipseformat -e /opt/eclipse4.3.1/? This is (unfortunately) not the same as compiling with Eclipse. The only way to be sure is to open up the code in Eclipse and look at the Problems view. > which I thought was right It?s half right ;-) > , and I just see 2 little comment reformatting things. Normally I use NetBeans 7.4, it already supports JDK 8, from your own company :) For better or worse, the Graal team is heavily invested in Eclipse in terms of experience and expectations. > Either way I will fix those things. No problem, I?m always willing to fix them up when integrating your patches. I just want to make you aware of why you may see such changes. > gpu_hsail.cpp: >> >> inline void init() { >> >> Why a separate init() function for HSAILKernelException? Seems like an inline constructor would do the same thing. >> > > Yes I agree, that would be better. > >> thread->set_gpu_exception_method(mh()); >> >> If the exception happens in an inlined method, then mh() is the wrong value here (and bci will be wrong as well). > > Yes that is true. We are still investigating how to do the debug info for HSAIL code and will get more into that in the next weeks. Then we will be able to have better unwind features and so on. > >> >> gpu_hsail.hpp: >> >> static bool execute_kernel_void_1d(address kernel, int dimX, jobject args, methodHandle mh, TRAPS); >> >> Why is the mh parameter no longer passed by reference? > > That is a typo, I will fix it. > Thanks for your comments, -Doug >> Description Resource Path Location Type >> The import com.oracle.graal.api.code is never used HSAILControlFlow.java /com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail line 36 Java Problem >> The value of the field HSAILHotSpotLoweringProvider.host is not used HSAILHotSpotLoweringProvider.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 39 Java Problem >> 'abstract' modifier out of order with the JLS suggestions. HSAILHotSpotLoweringProvider.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 41 Checkstyle Problem >> The value of the local variable bci is not used HSAILHotSpotLIRGenerator.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 222 Java Problem >> Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 42 Checkstyle Problem >> Line matches the illegal pattern 'System\.(out|err)\.print'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 73 Checkstyle Problem >> The import java.lang.reflect is never used HSAILAssembler.java /com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail line 26 Java Problem >> The import com.oracle.graal.debug.internal is never used HSAILCompilationResult.java /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail line 37 Java Problem >> First sentence should end with a period. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 14 Checkstyle Problem >> Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 27 Checkstyle Problem >> Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 27 Checkstyle Problem >> Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 42 Checkstyle Problem >> The import org.junit.Assert.assertTrue is never used ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 11 Java Problem >> Line does not match expected header line of ' \* Copyright \(c\) (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All rights reserved.'. ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 2 Checkstyle Problem >> First sentence should end with a period. BoundsCheckTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 29 Checkstyle Problem >> The import java.util.Arrays is never used ClassCastTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 9 Java Problem >> Line matches the illegal pattern 'System\.(out|err)\.print'. BoundsCheckTest.java /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test line 67 Checkstyle Problem >> >> >> >> On Dec 10, 2013, at 1:31 AM, Caspole, Eric wrote: >> >>> Hi everybody, >>> Tom and I came up with our first baby steps of throwing exceptions from HSAIL kernels back into "regular" java. This is for the context of running as a parallel stream such as a parallel().forEach(). This works such that the first kernel workitem to set an atomic after detecting a problem "wins" to report the exception back to java. The kernel workitems that detect a problem return early even if they lose to set the flag, and the others run on normally. This is about the same as you get with CPU parallel streams. >>> >>> http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/ >>> >>> We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via explicit checks in the HSAIL code, and return a deoptimization reason to the CPU side. In the JVM kernel launch code, we check for these exceptions, then save the method, reason and bci in the thread, then throw using the THROW/CHECK mechanism from C++ back to java. When the thread later gets to fillInStackTrace, it uses the saved info in the thread to add the kernel lambda method as the top frame in the stack trace. >>> >>> Let us know what you think. >>> Thanks, >>> Eric >>> >> >> > From tom.deneau at amd.com Tue Dec 10 08:41:13 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 10 Dec 2013 16:41:13 +0000 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: Gilles -- Some comments below -- Tom > -----Original Message----- > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev- > bounces at openjdk.java.net] On Behalf Of Gilles Duboscq > Sent: Tuesday, December 10, 2013 9:05 AM > To: Doug Simon > Cc: Caspole, Eric; graal-dev at openjdk.java.net > Subject: Re: Webrev for throwing some exceptions from HSAIL > > Hi Eric, > > The deoptimization mechanism and the exception mechanism are two > completely different things. > When a deoptimization happens, your only choice is to restart execution in the interpreter. > > To do so, the deoptimization points are decorated with LIRFrameState in the > backend. This LIRFrameState gives you information that allow to rebuild the > interpreter frames. For each frame you have a method, a bci, the stack and > local values and the owned monitors. > Yes, this was indeed a baby step. We realized with graal's policy of providing the framestate back at the last side-effecting bytecode means we don't get even get the exact bci on deoptimizations. Our plan for the next phase is to provide enough information and actually build up the correct interpreter frames back and restart execution in the interpreter back on the host side. > Once a deoptimization happened you can not just throw an exception > because the deoptimization informations will not tell you where the problem > actually happened, it is also not guaranteed that you have a meaningful > exception to throw corresponding to the deoptimization reason and it is > not even guaranteed that there actually was any problem at all! > Is this true even when the DeoptimizationReason is something explicit like BoundsCheckException? (realizing that all the problems with exact bci mentioned above still hold) > I think this was the reason you were using OptimisticOptimizations.NONE > previously which should get rid of most deoptimizations and get > exceptions instead. But i suspect it was not really used everywhere which could > cause problems such as the "not compiled exception handler" deopt reason. > Maybe we should try to have a look at those things together over Skype > (my username is gilwooden) or something similar. > I'm not really sure what affect OptimisticOptimizations.NONE or ALL had on any of this. With both NONE and ALL, we definitely still got both DeoptNodes and UnwindNodes. (The UnwindNodes came from profiling information I think). We switched to ALL in the latest just to make it more similar to what the AMD64 backend was doing. > -Gilles > > > > On Tue, Dec 10, 2013 at 1:03 PM, Doug Simon > wrote: > > > Hi Eric, > > > > Apart from the Eclipse errors and warnings (see below), the Java code > > looks ok. > > > > gpu_hsail.cpp: > > > > inline void init() { > > > > Why a separate init() function for HSAILKernelException? Seems like an > > inline constructor would do the same thing. > > > > thread->set_gpu_exception_method(mh()); > > > > If the exception happens in an inlined method, then mh() is the wrong > > value here (and bci will be wrong as well). > > > > gpu_hsail.hpp: > > > > static bool execute_kernel_void_1d(address kernel, int dimX, jobject > > args, methodHandle mh, TRAPS); > > > > Why is the mh parameter no longer passed by reference? > > > > -Doug > > > > Description Resource Path Location Type > > The import com.oracle.graal.api.code is never used > > HSAILControlFlow.java > > /com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail line > 36 > > Java Problem > > The value of the field HSAILHotSpotLoweringProvider.host is not used > > HSAILHotSpotLoweringProvider.java > > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > > line 39 Java Problem > > 'abstract' modifier out of order with the JLS suggestions. > > HSAILHotSpotLoweringProvider.java > > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > > line 41 Checkstyle Problem > > The value of the local variable bci is not used > > HSAILHotSpotLIRGenerator.java > > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > > line 222 Java Problem > > Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. > ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 42 Checkstyle Problem > > Line matches the illegal pattern 'System\.(out|err)\.print'. > > ClassCastTest.java > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 73 Checkstyle Problem > > The import java.lang.reflect is never used HSAILAssembler.java > > /com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail line > 26 > > Java Problem > > The import com.oracle.graal.debug.internal is never used > > HSAILCompilationResult.java > > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > > line 37 Java Problem > > First sentence should end with a period. ClassCastTest.java > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 14 Checkstyle Problem > > Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. > ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 27 Checkstyle Problem > > Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. > ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 27 Checkstyle Problem > > Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. > ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 42 Checkstyle Problem > > The import org.junit.Assert.assertTrue is never used > ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 11 Java Problem > > Line does not match expected header line of ' \* Copyright \(c\) > > (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All > rights > > reserved.'. ClassCastTest.java > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 2 Checkstyle Problem > > First sentence should end with a period. BoundsCheckTest.java > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 29 Checkstyle Problem > > The import java.util.Arrays is never used ClassCastTest.java > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 9 Java Problem > > Line matches the illegal pattern 'System\.(out|err)\.print'. > > BoundsCheckTest.java > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > l/test > > line 67 Checkstyle Problem > > > > > > > > On Dec 10, 2013, at 1:31 AM, Caspole, Eric > wrote: > > > > > Hi everybody, > > > Tom and I came up with our first baby steps of throwing exceptions > from > > HSAIL kernels back into "regular" java. This is for the context of > running > > as a parallel stream such as a parallel().forEach(). This works such > that > > the first kernel workitem to set an atomic after detecting a problem > "wins" > > to report the exception back to java. The kernel workitems that > detect a > > problem return early even if they lose to set the flag, and the others > run > > on normally. This is about the same as you get with CPU parallel > streams. > > > > > > http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/< > > http://cr.openjdk.java.net/%7Eecaspole/hsail_exceptions/> > > > > > > We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via > > explicit checks in the HSAIL code, and return a deoptimization reason > to > > the CPU side. In the JVM kernel launch code, we check for these > exceptions, > > then save the method, reason and bci in the thread, then throw using > the > > THROW/CHECK mechanism from C++ back to java. When the thread later > gets to > > fillInStackTrace, it uses the saved info in the thread to add the > kernel > > lambda method as the top frame in the stack trace. > > > > > > Let us know what you think. > > > Thanks, > > > Eric > > > > > > > From duboscq at ssw.jku.at Tue Dec 10 09:31:30 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 10 Dec 2013 18:31:30 +0100 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: On Tue, Dec 10, 2013 at 5:41 PM, Tom Deneau wrote: > Gilles -- > > Some comments below > > -- Tom > > > -----Original Message----- > > From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev- > > bounces at openjdk.java.net] On Behalf Of Gilles Duboscq > > Sent: Tuesday, December 10, 2013 9:05 AM > > To: Doug Simon > > Cc: Caspole, Eric; graal-dev at openjdk.java.net > > Subject: Re: Webrev for throwing some exceptions from HSAIL > > > > Hi Eric, > > > > The deoptimization mechanism and the exception mechanism are two > > completely different things. > > When a deoptimization happens, your only choice is to restart execution > in the interpreter. > > > > To do so, the deoptimization points are decorated with LIRFrameState in > the > > backend. This LIRFrameState gives you information that allow to rebuild > the > > interpreter frames. For each frame you have a method, a bci, the stack > and > > local values and the owned monitors. > > > > Yes, this was indeed a baby step. > > We realized with graal's policy of providing the framestate back at the > last > side-effecting bytecode means we don't get even get the exact bci on > deoptimizations. > > Our plan for the next phase is to provide enough information and > actually build up the correct interpreter frames back and restart > execution in the interpreter back on the host side. > OK, but i wonder what are the semantics there since the data has already been partially modified by the other kernel workitems which didn't deoptimize. In general when we think about parallelization we consider that it's only safe to parallelize sections where there is no deoptimization since this means we are guaranteed not to deopt to a state of the data that is invalid for the interpreter. I suppose in the case of streams you are relying on the relaxed semantics of parallel streams. How are you going to ensure that all element are processed in the case of deoptimization? > > > > Once a deoptimization happened you can not just throw an exception > > because the deoptimization informations will not tell you where the > problem > > actually happened, it is also not guaranteed that you have a meaningful > > exception to throw corresponding to the deoptimization reason and it is > > not even guaranteed that there actually was any problem at all! > > > > Is this true even when the DeoptimizationReason is something explicit like > BoundsCheckException? > (realizing that all the problems with exact bci mentioned above still hold) > Yes, the compiler does not apply the exception semantics to the deoptimizations. We use deoptimization for exceptions (amongst other things) because it make optimization easier since we don't need to respect exception semantics for deoptimization and we just let the interpreter figure out if and where the exception should be thrown. > > > I think this was the reason you were using OptimisticOptimizations.NONE > > previously which should get rid of most deoptimizations and get > > exceptions instead. But i suspect it was not really used everywhere > which could > > cause problems such as the "not compiled exception handler" deopt reason. > > Maybe we should try to have a look at those things together over Skype > > (my username is gilwooden) or something similar. > > > > I'm not really sure what affect OptimisticOptimizations.NONE or ALL had on > any of this. > With both NONE and ALL, we definitely still got both DeoptNodes and > UnwindNodes. (The > UnwindNodes came from profiling information I think). > We switched to ALL in the latest just to make it more similar to what the > AMD64 backend > was doing. > If you really implement deoptimization then ALL is the way to go. But i thought you would prefer unwind nodes which tell you that an exception actually needs to be thrown. The fact that you still got a mixture of deopt and unwind nodes probably means that there was a problem around inlining where the root method and the inlinined methods didn't use the same policy. > > > -Gilles > > > > > > > > On Tue, Dec 10, 2013 at 1:03 PM, Doug Simon > > wrote: > > > > > Hi Eric, > > > > > > Apart from the Eclipse errors and warnings (see below), the Java code > > > looks ok. > > > > > > gpu_hsail.cpp: > > > > > > inline void init() { > > > > > > Why a separate init() function for HSAILKernelException? Seems like an > > > inline constructor would do the same thing. > > > > > > thread->set_gpu_exception_method(mh()); > > > > > > If the exception happens in an inlined method, then mh() is the wrong > > > value here (and bci will be wrong as well). > > > > > > gpu_hsail.hpp: > > > > > > static bool execute_kernel_void_1d(address kernel, int dimX, jobject > > > args, methodHandle mh, TRAPS); > > > > > > Why is the mh parameter no longer passed by reference? > > > > > > -Doug > > > > > > Description Resource Path Location Type > > > The import com.oracle.graal.api.code is never used > > > HSAILControlFlow.java > > > /com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail line > > 36 > > > Java Problem > > > The value of the field HSAILHotSpotLoweringProvider.host is not used > > > HSAILHotSpotLoweringProvider.java > > > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > > > line 39 Java Problem > > > 'abstract' modifier out of order with the JLS suggestions. > > > HSAILHotSpotLoweringProvider.java > > > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > > > line 41 Checkstyle Problem > > > The value of the local variable bci is not used > > > HSAILHotSpotLIRGenerator.java > > > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > > > line 222 Java Problem > > > Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. > > ClassCastTest.java > > > > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 42 Checkstyle Problem > > > Line matches the illegal pattern 'System\.(out|err)\.print'. > > > ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 73 Checkstyle Problem > > > The import java.lang.reflect is never used HSAILAssembler.java > > > /com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail line > > 26 > > > Java Problem > > > The import com.oracle.graal.debug.internal is never used > > > HSAILCompilationResult.java > > > /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail > > > line 37 Java Problem > > > First sentence should end with a period. ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 14 Checkstyle Problem > > > Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. > > ClassCastTest.java > > > > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 27 Checkstyle Problem > > > Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. > > ClassCastTest.java > > > > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 27 Checkstyle Problem > > > Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. > > ClassCastTest.java > > > > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 42 Checkstyle Problem > > > The import org.junit.Assert.assertTrue is never used > > ClassCastTest.java > > > > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 11 Java Problem > > > Line does not match expected header line of ' \* Copyright \(c\) > > > (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All > > rights > > > reserved.'. ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 2 Checkstyle Problem > > > First sentence should end with a period. BoundsCheckTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 29 Checkstyle Problem > > > The import java.util.Arrays is never used ClassCastTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 9 Java Problem > > > Line matches the illegal pattern 'System\.(out|err)\.print'. > > > BoundsCheckTest.java > > > > > /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai > > l/test > > > line 67 Checkstyle Problem > > > > > > > > > > > > On Dec 10, 2013, at 1:31 AM, Caspole, Eric > > wrote: > > > > > > > Hi everybody, > > > > Tom and I came up with our first baby steps of throwing exceptions > > from > > > HSAIL kernels back into "regular" java. This is for the context of > > running > > > as a parallel stream such as a parallel().forEach(). This works such > > that > > > the first kernel workitem to set an atomic after detecting a problem > > "wins" > > > to report the exception back to java. The kernel workitems that > > detect a > > > problem return early even if they lose to set the flag, and the others > > run > > > on normally. This is about the same as you get with CPU parallel > > streams. > > > > > > > > http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/< > > > http://cr.openjdk.java.net/%7Eecaspole/hsail_exceptions/> > > > > > > > > We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via > > > explicit checks in the HSAIL code, and return a deoptimization reason > > to > > > the CPU side. In the JVM kernel launch code, we check for these > > exceptions, > > > then save the method, reason and bci in the thread, then throw using > > the > > > THROW/CHECK mechanism from C++ back to java. When the thread later > > gets to > > > fillInStackTrace, it uses the saved info in the thread to add the > > kernel > > > lambda method as the top frame in the stack trace. > > > > > > > > Let us know what you think. > > > > Thanks, > > > > Eric > > > > > > > > > > > > From christian.thalinger at oracle.com Tue Dec 10 11:27:52 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Dec 2013 11:27:52 -0800 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> Message-ID: <5B02E26C-8CC1-4F57-919B-073295734001@oracle.com> On Dec 10, 2013, at 9:31 AM, Gilles Duboscq wrote: > On Tue, Dec 10, 2013 at 5:41 PM, Tom Deneau wrote: > >> Gilles -- >> >> Some comments below >> >> -- Tom >> >>> -----Original Message----- >>> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev- >>> bounces at openjdk.java.net] On Behalf Of Gilles Duboscq >>> Sent: Tuesday, December 10, 2013 9:05 AM >>> To: Doug Simon >>> Cc: Caspole, Eric; graal-dev at openjdk.java.net >>> Subject: Re: Webrev for throwing some exceptions from HSAIL >>> >>> Hi Eric, >>> >>> The deoptimization mechanism and the exception mechanism are two >>> completely different things. >>> When a deoptimization happens, your only choice is to restart execution >> in the interpreter. >>> >>> To do so, the deoptimization points are decorated with LIRFrameState in >> the >>> backend. This LIRFrameState gives you information that allow to rebuild >> the >>> interpreter frames. For each frame you have a method, a bci, the stack >> and >>> local values and the owned monitors. >>> >> >> Yes, this was indeed a baby step. >> >> We realized with graal's policy of providing the framestate back at the >> last >> side-effecting bytecode means we don't get even get the exact bci on >> deoptimizations. >> >> Our plan for the next phase is to provide enough information and >> actually build up the correct interpreter frames back and restart >> execution in the interpreter back on the host side. >> > > OK, but i wonder what are the semantics there since the data has already > been partially modified by the other kernel workitems which didn't > deoptimize. > In general when we think about parallelization we consider that it's only > safe to parallelize sections where there is no deoptimization since this > means we are guaranteed not to deopt to a state of the data that is invalid > for the interpreter. > I suppose in the case of streams you are relying on the relaxed semantics > of parallel streams. > How are you going to ensure that all element are processed in the case of > deoptimization? Correct. This is something we have talked about already in the Sumatra scope. Before we can throw exceptions in GPUs we have to have some kind of work item logic. I think trying to throw exceptions without having properly set up work items and a way to undo or record which items have already been processed is premature and not something we want. We need to resume talking about work items and start to implement it. > > >> >> >>> Once a deoptimization happened you can not just throw an exception >>> because the deoptimization informations will not tell you where the >> problem >>> actually happened, it is also not guaranteed that you have a meaningful >>> exception to throw corresponding to the deoptimization reason and it is >>> not even guaranteed that there actually was any problem at all! >>> >> >> Is this true even when the DeoptimizationReason is something explicit like >> BoundsCheckException? >> (realizing that all the problems with exact bci mentioned above still hold) >> > > Yes, the compiler does not apply the exception semantics to the > deoptimizations. We use deoptimization for exceptions (amongst other > things) because it make optimization easier since we don't need to respect > exception semantics for deoptimization and we just let the interpreter > figure out if and where the exception should be thrown. > > >> >>> I think this was the reason you were using OptimisticOptimizations.NONE >>> previously which should get rid of most deoptimizations and get >>> exceptions instead. But i suspect it was not really used everywhere >> which could >>> cause problems such as the "not compiled exception handler" deopt reason. >>> Maybe we should try to have a look at those things together over Skype >>> (my username is gilwooden) or something similar. >>> >> >> I'm not really sure what affect OptimisticOptimizations.NONE or ALL had on >> any of this. >> With both NONE and ALL, we definitely still got both DeoptNodes and >> UnwindNodes. (The >> UnwindNodes came from profiling information I think). >> We switched to ALL in the latest just to make it more similar to what the >> AMD64 backend >> was doing. >> > > If you really implement deoptimization then ALL is the way to go. > But i thought you would prefer unwind nodes which tell you that an > exception actually needs to be thrown. > The fact that you still got a mixture of deopt and unwind nodes probably > means that there was a problem around inlining where the root method and > the inlinined methods didn't use the same policy. > > >> >>> -Gilles >>> >>> >>> >>> On Tue, Dec 10, 2013 at 1:03 PM, Doug Simon >>> wrote: >>> >>>> Hi Eric, >>>> >>>> Apart from the Eclipse errors and warnings (see below), the Java code >>>> looks ok. >>>> >>>> gpu_hsail.cpp: >>>> >>>> inline void init() { >>>> >>>> Why a separate init() function for HSAILKernelException? Seems like an >>>> inline constructor would do the same thing. >>>> >>>> thread->set_gpu_exception_method(mh()); >>>> >>>> If the exception happens in an inlined method, then mh() is the wrong >>>> value here (and bci will be wrong as well). >>>> >>>> gpu_hsail.hpp: >>>> >>>> static bool execute_kernel_void_1d(address kernel, int dimX, jobject >>>> args, methodHandle mh, TRAPS); >>>> >>>> Why is the mh parameter no longer passed by reference? >>>> >>>> -Doug >>>> >>>> Description Resource Path Location Type >>>> The import com.oracle.graal.api.code is never used >>>> HSAILControlFlow.java >>>> /com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail line >>> 36 >>>> Java Problem >>>> The value of the field HSAILHotSpotLoweringProvider.host is not used >>>> HSAILHotSpotLoweringProvider.java >>>> /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail >>>> line 39 Java Problem >>>> 'abstract' modifier out of order with the JLS suggestions. >>>> HSAILHotSpotLoweringProvider.java >>>> /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail >>>> line 41 Checkstyle Problem >>>> The value of the local variable bci is not used >>>> HSAILHotSpotLIRGenerator.java >>>> /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail >>>> line 222 Java Problem >>>> Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. >>> ClassCastTest.java >>>> >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 42 Checkstyle Problem >>>> Line matches the illegal pattern 'System\.(out|err)\.print'. >>>> ClassCastTest.java >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 73 Checkstyle Problem >>>> The import java.lang.reflect is never used HSAILAssembler.java >>>> /com.oracle.graal.asm.hsail/src/com/oracle/graal/asm/hsail line >>> 26 >>>> Java Problem >>>> The import com.oracle.graal.debug.internal is never used >>>> HSAILCompilationResult.java >>>> /com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail >>>> line 37 Java Problem >>>> First sentence should end with a period. ClassCastTest.java >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 14 Checkstyle Problem >>>> Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. >>> ClassCastTest.java >>>> >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 27 Checkstyle Problem >>>> Name '_y' must match pattern '^[a-z][a-zA-Z0-9]*$'. >>> ClassCastTest.java >>>> >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 27 Checkstyle Problem >>>> Name '_x' must match pattern '^[a-z][a-zA-Z0-9]*$'. >>> ClassCastTest.java >>>> >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 42 Checkstyle Problem >>>> The import org.junit.Assert.assertTrue is never used >>> ClassCastTest.java >>>> >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 11 Java Problem >>>> Line does not match expected header line of ' \* Copyright \(c\) >>>> (20[0-9][0-9], )?20[0-9][0-9], Oracle and/or its affiliates. All >>> rights >>>> reserved.'. ClassCastTest.java >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 2 Checkstyle Problem >>>> First sentence should end with a period. BoundsCheckTest.java >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 29 Checkstyle Problem >>>> The import java.util.Arrays is never used ClassCastTest.java >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 9 Java Problem >>>> Line matches the illegal pattern 'System\.(out|err)\.print'. >>>> BoundsCheckTest.java >>>> >>> /com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsai >>> l/test >>>> line 67 Checkstyle Problem >>>> >>>> >>>> >>>> On Dec 10, 2013, at 1:31 AM, Caspole, Eric >>> wrote: >>>> >>>>> Hi everybody, >>>>> Tom and I came up with our first baby steps of throwing exceptions >>> from >>>> HSAIL kernels back into "regular" java. This is for the context of >>> running >>>> as a parallel stream such as a parallel().forEach(). This works such >>> that >>>> the first kernel workitem to set an atomic after detecting a problem >>> "wins" >>>> to report the exception back to java. The kernel workitems that >>> detect a >>>> problem return early even if they lose to set the flag, and the others >>> run >>>> on normally. This is about the same as you get with CPU parallel >>> streams. >>>>> >>>>> http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/< >>>> http://cr.openjdk.java.net/%7Eecaspole/hsail_exceptions/> >>>>> >>>>> We can now detect ArrayIndexOutOfBounds and ClassCastExceptions via >>>> explicit checks in the HSAIL code, and return a deoptimization reason >>> to >>>> the CPU side. In the JVM kernel launch code, we check for these >>> exceptions, >>>> then save the method, reason and bci in the thread, then throw using >>> the >>>> THROW/CHECK mechanism from C++ back to java. When the thread later >>> gets to >>>> fillInStackTrace, it uses the saved info in the thread to add the >>> kernel >>>> lambda method as the top frame in the stack trace. >>>>> >>>>> Let us know what you think. >>>>> Thanks, >>>>> Eric From falbert9 at vt.edu Tue Dec 10 11:33:40 2013 From: falbert9 at vt.edu (Curt Albert) Date: Tue, 10 Dec 2013 14:33:40 -0500 Subject: JVM Language Summit Examples Message-ID: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> I have been trying to look at using graal for compiler optimizations in my java code and found the presentation given at JVM Language Summit 2011. In that presentation there was an example of intrinsificiation called SafeAddNode. I was trying to reproduce this example, but it seems the intrinsification code has moved. Is it still possible to run this same example? If so how? Thanks, Curt Albert Systems Software Research Group Bradley Department of Electrical and Compuer Engineering Virginia Tech From doug.simon at oracle.com Tue Dec 10 13:05:37 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 Dec 2013 22:05:37 +0100 Subject: JVM Language Summit Examples In-Reply-To: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> References: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> Message-ID: <219A4274-21AC-4F8A-AFE6-7C1573510085@oracle.com> Hi Curt, Have a look at MathSubstitutionsX86.pow(double, double)[1] for an example of how intrinsification is done now. -Doug [1] http://hg.openjdk.java.net/graal/graal/file/4eacfd0767ed/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java On Dec 10, 2013, at 8:33 PM, Curt Albert wrote: > I have been trying to look at using graal for compiler > optimizations in my java code and found the presentation given at JVM > Language Summit 2011. In that presentation there was an example of > intrinsificiation called SafeAddNode. I was trying to reproduce this > example, but it seems the intrinsification code has moved. Is it still > possible to run this same example? If so how? > > > > Thanks, > > Curt Albert > > Systems Software Research Group > > Bradley Department of Electrical and Compuer Engineering > > Virginia Tech > > > From doychin at dsoft-bg.com Tue Dec 10 13:53:46 2013 From: doychin at dsoft-bg.com (Doychin Bondzhev) Date: Tue, 10 Dec 2013 23:53:46 +0200 Subject: JVM Language Summit Examples In-Reply-To: <219A4274-21AC-4F8A-AFE6-7C1573510085@oracle.com> References: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> <219A4274-21AC-4F8A-AFE6-7C1573510085@oracle.com> Message-ID: Looking at code for pow I think there is something wrong here. It could be my mistake but this looks like recursive call of pow from pow. So in case of x and y not in any of the special cases this will result in stack overflow. Probably on the last line of call to pow should be Math.pow instead of just pow. On Tue, Dec 10, 2013 at 11:05 PM, Doug Simon wrote: > Hi Curt, > > Have a look at MathSubstitutionsX86.pow(double, double)[1] for an example > of how intrinsification is done now. > > -Doug > > [1] > http://hg.openjdk.java.net/graal/graal/file/4eacfd0767ed/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java > > On Dec 10, 2013, at 8:33 PM, Curt Albert wrote: > > > I have been trying to look at using graal for compiler > > optimizations in my java code and found the presentation given at JVM > > Language Summit 2011. In that presentation there was an example of > > intrinsificiation called SafeAddNode. I was trying to reproduce this > > example, but it seems the intrinsification code has moved. Is it still > > possible to run this same example? If so how? > > > > > > > > Thanks, > > > > Curt Albert > > > > Systems Software Research Group > > > > Bradley Department of Electrical and Compuer Engineering > > > > Virginia Tech > > > > > > > > From doug.simon at oracle.com Tue Dec 10 14:14:17 2013 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 10 Dec 2013 23:14:17 +0100 Subject: JVM Language Summit Examples In-Reply-To: References: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> <219A4274-21AC-4F8A-AFE6-7C1573510085@oracle.com> Message-ID: <95EB4904-9E09-4FB6-991C-C35EC6719215@oracle.com> Yes, it?s certainly looks like a bug doesn?t it! However, this is the (not so well documented) mechanism to do a partial intrinsification. That is, sometimes (as in this example) you only want to optimize for a subset of the potential arguments that can be passed to a method. A recursive call in such an intrinsification will be translated as a call to the original method. -Doug On Dec 10, 2013, at 10:53 PM, Doychin Bondzhev wrote: > Looking at code for pow I think there is something wrong here. > > It could be my mistake but this looks like recursive call of pow from pow. So in case of x and y not in any of the special cases this will result in stack overflow. Probably on the last line of call to pow should be Math.pow instead of just pow. > > > On Tue, Dec 10, 2013 at 11:05 PM, Doug Simon wrote: > Hi Curt, > > Have a look at MathSubstitutionsX86.pow(double, double)[1] for an example of how intrinsification is done now. > > -Doug > > [1] http://hg.openjdk.java.net/graal/graal/file/4eacfd0767ed/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java > > On Dec 10, 2013, at 8:33 PM, Curt Albert wrote: > > > I have been trying to look at using graal for compiler > > optimizations in my java code and found the presentation given at JVM > > Language Summit 2011. In that presentation there was an example of > > intrinsificiation called SafeAddNode. I was trying to reproduce this > > example, but it seems the intrinsification code has moved. Is it still > > possible to run this same example? If so how? > > > > > > > > Thanks, > > > > Curt Albert > > > > Systems Software Research Group > > > > Bradley Department of Electrical and Compuer Engineering > > > > Virginia Tech > > > > > > > > From christian.thalinger at oracle.com Tue Dec 10 17:17:25 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Dec 2013 17:17:25 -0800 Subject: JVM Language Summit Examples In-Reply-To: <95EB4904-9E09-4FB6-991C-C35EC6719215@oracle.com> References: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> <219A4274-21AC-4F8A-AFE6-7C1573510085@oracle.com> <95EB4904-9E09-4FB6-991C-C35EC6719215@oracle.com> Message-ID: <875B3863-CD22-443F-A187-255FD0200179@oracle.com> Not everyone has read your paper, Doug ;-) On Dec 10, 2013, at 2:14 PM, Doug Simon wrote: > Yes, it?s certainly looks like a bug doesn?t it! > > However, this is the (not so well documented) mechanism to do a partial intrinsification. That is, sometimes (as in this example) you only want to optimize for a subset of the potential arguments that can be passed to a method. A recursive call in such an intrinsification will be translated as a call to the original method. > > -Doug > > On Dec 10, 2013, at 10:53 PM, Doychin Bondzhev wrote: > >> Looking at code for pow I think there is something wrong here. >> >> It could be my mistake but this looks like recursive call of pow from pow. So in case of x and y not in any of the special cases this will result in stack overflow. Probably on the last line of call to pow should be Math.pow instead of just pow. >> >> >> On Tue, Dec 10, 2013 at 11:05 PM, Doug Simon wrote: >> Hi Curt, >> >> Have a look at MathSubstitutionsX86.pow(double, double)[1] for an example of how intrinsification is done now. >> >> -Doug >> >> [1] http://hg.openjdk.java.net/graal/graal/file/4eacfd0767ed/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java >> >> On Dec 10, 2013, at 8:33 PM, Curt Albert wrote: >> >>> I have been trying to look at using graal for compiler >>> optimizations in my java code and found the presentation given at JVM >>> Language Summit 2011. In that presentation there was an example of >>> intrinsificiation called SafeAddNode. I was trying to reproduce this >>> example, but it seems the intrinsification code has moved. Is it still >>> possible to run this same example? If so how? >>> >>> >>> >>> Thanks, >>> >>> Curt Albert >>> >>> Systems Software Research Group >>> >>> Bradley Department of Electrical and Compuer Engineering >>> >>> Virginia Tech >>> >>> >>> >> >> > From doug.simon at oracle.com Tue Dec 10 22:54:03 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 11 Dec 2013 07:54:03 +0100 Subject: JVM Language Summit Examples In-Reply-To: <875B3863-CD22-443F-A187-255FD0200179@oracle.com> References: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> <219A4274-21AC-4F8A-AFE6-7C1573510085@oracle.com> <95EB4904-9E09-4FB6-991C-C35EC6719215@oracle.com> <875B3863-CD22-443F-A187-255FD0200179@oracle.com> Message-ID: <080158F4-8821-4C8B-8A04-AA4EAAA433C8@oracle.com> On Dec 11, 2013, at 2:17 AM, Christian Thalinger wrote: > Not everyone has read your paper, Doug ;-) ? which doesn?t even mention this feature ;-) I was about to add some javadoc to MethodSubstitution but see it?s already there: /** * Denotes a substitute method. A substitute method can call the original/substituted method by * making a recursive call to itself. */ @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) public @interface MethodSubstitution { -Doug > On Dec 10, 2013, at 2:14 PM, Doug Simon wrote: > >> Yes, it?s certainly looks like a bug doesn?t it! >> >> However, this is the (not so well documented) mechanism to do a partial intrinsification. That is, sometimes (as in this example) you only want to optimize for a subset of the potential arguments that can be passed to a method. A recursive call in such an intrinsification will be translated as a call to the original method. >> >> -Doug >> >> On Dec 10, 2013, at 10:53 PM, Doychin Bondzhev wrote: >> >>> Looking at code for pow I think there is something wrong here. >>> >>> It could be my mistake but this looks like recursive call of pow from pow. So in case of x and y not in any of the special cases this will result in stack overflow. Probably on the last line of call to pow should be Math.pow instead of just pow. >>> >>> >>> On Tue, Dec 10, 2013 at 11:05 PM, Doug Simon wrote: >>> Hi Curt, >>> >>> Have a look at MathSubstitutionsX86.pow(double, double)[1] for an example of how intrinsification is done now. >>> >>> -Doug >>> >>> [1] http://hg.openjdk.java.net/graal/graal/file/4eacfd0767ed/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java >>> >>> On Dec 10, 2013, at 8:33 PM, Curt Albert wrote: >>> >>>> I have been trying to look at using graal for compiler >>>> optimizations in my java code and found the presentation given at JVM >>>> Language Summit 2011. In that presentation there was an example of >>>> intrinsificiation called SafeAddNode. I was trying to reproduce this >>>> example, but it seems the intrinsification code has moved. Is it still >>>> possible to run this same example? If so how? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Curt Albert >>>> >>>> Systems Software Research Group >>>> >>>> Bradley Department of Electrical and Compuer Engineering >>>> >>>> Virginia Tech >>>> >>>> >>>> >>> >>> >> > From Vasanth.Venkatachalam at amd.com Thu Dec 12 11:35:26 2013 From: Vasanth.Venkatachalam at amd.com (Venkatachalam, Vasanth) Date: Thu, 12 Dec 2013 19:35:26 +0000 Subject: webrev for HSAIL backend Math intrinsics support Message-ID: <5DD1503F815BD14889DC81D28643E3A7578A11C0@SATLEXDAG01.amd.com> Hi, I've uploaded a webrev that adds support to the HSAIL backend for intrinsifying some of the java.lang.Math routines. http://cr.openjdk.java.net/~tdeneau/webrev-mathintrinsics05/webrev/ Please review and provide feedback. When ready for commit, please commit it in my name. Implementation Notes: 1) The java.lang.Math routines that are covered in this webrev include Math.sqrt, Math.abs, Math.rint, Math.floor, and Math.ceil. Based on the HSAIL spec and the precision requirements of Java these are the most straightforward to implement. 2) The main changes are the addition of an HSAILMathSubstitutions class and an HSAILMathIntrinsicNode to define the new intrinsics, and supporting changes in HSAILLIRGenerator and HSAILArithmetic to handle the code generation. 3) Test cases have been included for testing each of the intrinsics included in this webrev. The tests exercise positive and negative values as well as corner cases mentioned in the java.lang.Math spec for the above five routines. Vasanth From falbert9 at vt.edu Thu Dec 12 11:49:50 2013 From: falbert9 at vt.edu (Curt Albert) Date: Thu, 12 Dec 2013 14:49:50 -0500 Subject: JVM Language Summit Examples In-Reply-To: <080158F4-8821-4C8B-8A04-AA4EAAA433C8@oracle.com> References: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> <219A4274-21AC-4F8A-AFE6-7C1573510085@oracle.com> <95EB4904-9E09-4FB6-991C-C35EC6719215@oracle.com> <875B3863-CD22-443F-A187-255FD0200179@oracle.com> <080158F4-8821-4C8B-8A04-AA4EAAA433C8@oracle.com> Message-ID: Thank you for pointing me to the example. I got it working and am now trying to adapt it to substitute methods for a class of my own. I tried to import the package containing the class but I don't know where to add it to the classpath when it compiles. Whenever I compile I keep getting error package does not exist. Is there something in mx.py that I need to change to add to the classpath? Thanks, Curt Albert On Wed, Dec 11, 2013 at 1:54 AM, Doug Simon wrote: > > On Dec 11, 2013, at 2:17 AM, Christian Thalinger < > christian.thalinger at oracle.com> wrote: > > > Not everyone has read your paper, Doug ;-) > > ? which doesn?t even mention this feature ;-) > > I was about to add some javadoc to MethodSubstitution but see it?s already > there: > > /** > * Denotes a substitute method. A substitute method can call the > original/substituted method by > * making a recursive call to itself. > */ > @Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.METHOD) > public @interface MethodSubstitution { > > -Doug > > > On Dec 10, 2013, at 2:14 PM, Doug Simon wrote: > > > >> Yes, it?s certainly looks like a bug doesn?t it! > >> > >> However, this is the (not so well documented) mechanism to do a partial > intrinsification. That is, sometimes (as in this example) you only want to > optimize for a subset of the potential arguments that can be passed to a > method. A recursive call in such an intrinsification will be translated as > a call to the original method. > >> > >> -Doug > >> > >> On Dec 10, 2013, at 10:53 PM, Doychin Bondzhev > wrote: > >> > >>> Looking at code for pow I think there is something wrong here. > >>> > >>> It could be my mistake but this looks like recursive call of pow from > pow. So in case of x and y not in any of the special cases this will result > in stack overflow. Probably on the last line of call to pow should be > Math.pow instead of just pow. > >>> > >>> > >>> On Tue, Dec 10, 2013 at 11:05 PM, Doug Simon > wrote: > >>> Hi Curt, > >>> > >>> Have a look at MathSubstitutionsX86.pow(double, double)[1] for an > example of how intrinsification is done now. > >>> > >>> -Doug > >>> > >>> [1] > http://hg.openjdk.java.net/graal/graal/file/4eacfd0767ed/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java > >>> > >>> On Dec 10, 2013, at 8:33 PM, Curt Albert wrote: > >>> > >>>> I have been trying to look at using graal for compiler > >>>> optimizations in my java code and found the presentation given at JVM > >>>> Language Summit 2011. In that presentation there was an example of > >>>> intrinsificiation called SafeAddNode. I was trying to reproduce this > >>>> example, but it seems the intrinsification code has moved. Is it still > >>>> possible to run this same example? If so how? > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Curt Albert > >>>> > >>>> Systems Software Research Group > >>>> > >>>> Bradley Department of Electrical and Compuer Engineering > >>>> > >>>> Virginia Tech > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > From doug.simon at oracle.com Thu Dec 12 12:03:53 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 12 Dec 2013 21:03:53 +0100 Subject: JVM Language Summit Examples In-Reply-To: References: <006c01cef5de$bb2a27d0$317e7770$@vt.edu> <219A4274-21AC-4F8A-AFE6-7C1573510085@oracle.com> <95EB4904-9E09-4FB6-991C-C35EC6719215@oracle.com> <875B3863-CD22-443F-A187-255FD0200179@oracle.com> <080158F4-8821-4C8B-8A04-AA4EAAA433C8@oracle.com> Message-ID: <2AD03324-9143-4397-B84C-02CE3A514DBC@oracle.com> Have a look at CipherBlockChainingSubstitutions and AESCryptSubstitutions for examples of how to substitute methods not on the boot class path. -Doug On Dec 12, 2013, at 8:49 PM, Curt Albert wrote: > Thank you for pointing me to the example. I got it working and am now trying to adapt it to substitute methods for a class of my own. I tried to import the package containing the class but I don't know where to add it to the classpath when it compiles. Whenever I compile I keep getting error package does not exist. Is there something in mx.py that I need to change to add to the classpath? > > Thanks, > Curt Albert > > > On Wed, Dec 11, 2013 at 1:54 AM, Doug Simon wrote: > > On Dec 11, 2013, at 2:17 AM, Christian Thalinger wrote: > > > Not everyone has read your paper, Doug ;-) > > ? which doesn?t even mention this feature ;-) > > I was about to add some javadoc to MethodSubstitution but see it?s already there: > > /** > * Denotes a substitute method. A substitute method can call the original/substituted method by > * making a recursive call to itself. > */ > @Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.METHOD) > public @interface MethodSubstitution { > > -Doug > > > On Dec 10, 2013, at 2:14 PM, Doug Simon wrote: > > > >> Yes, it?s certainly looks like a bug doesn?t it! > >> > >> However, this is the (not so well documented) mechanism to do a partial intrinsification. That is, sometimes (as in this example) you only want to optimize for a subset of the potential arguments that can be passed to a method. A recursive call in such an intrinsification will be translated as a call to the original method. > >> > >> -Doug > >> > >> On Dec 10, 2013, at 10:53 PM, Doychin Bondzhev wrote: > >> > >>> Looking at code for pow I think there is something wrong here. > >>> > >>> It could be my mistake but this looks like recursive call of pow from pow. So in case of x and y not in any of the special cases this will result in stack overflow. Probably on the last line of call to pow should be Math.pow instead of just pow. > >>> > >>> > >>> On Tue, Dec 10, 2013 at 11:05 PM, Doug Simon wrote: > >>> Hi Curt, > >>> > >>> Have a look at MathSubstitutionsX86.pow(double, double)[1] for an example of how intrinsification is done now. > >>> > >>> -Doug > >>> > >>> [1] http://hg.openjdk.java.net/graal/graal/file/4eacfd0767ed/graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/MathSubstitutionsX86.java > >>> > >>> On Dec 10, 2013, at 8:33 PM, Curt Albert wrote: > >>> > >>>> I have been trying to look at using graal for compiler > >>>> optimizations in my java code and found the presentation given at JVM > >>>> Language Summit 2011. In that presentation there was an example of > >>>> intrinsificiation called SafeAddNode. I was trying to reproduce this > >>>> example, but it seems the intrinsification code has moved. Is it still > >>>> possible to run this same example? If so how? > >>>> > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Curt Albert > >>>> > >>>> Systems Software Research Group > >>>> > >>>> Bradley Department of Electrical and Compuer Engineering > >>>> > >>>> Virginia Tech > >>>> > >>>> > >>>> > >>> > >>> > >> > > > > From Eric.Caspole at amd.com Thu Dec 12 13:55:00 2013 From: Eric.Caspole at amd.com (Caspole, Eric) Date: Thu, 12 Dec 2013 21:55:00 +0000 Subject: missing bscmake.exe during debug build on Windows Message-ID: Hi, I recently noticed I can't build the debug or fastdebug version of Graal on Windows anymore, it can't find this bscmake.exe. I think this used to work about a month ago but I am not sure now. The "--vmbuild product" works fine. I am not blocked on this, just FYI. Regards, Eric mx.cmd --vmbuild debug --vm server build TRACKER : error TRK0005: Failed to locate: "bscmake.exe". The system cannot find the file specified. [c:\work\reduceops\graal\build\ vs-amd64\jvm.vcxproj] Done Building Project "c:\work\reduceops\graal\build\vs-amd64\jvm.vcxproj" (default targets) -- FAILED. Build FAILED. "c:\work\reduceops\graal\build\vs-amd64\jvm.vcxproj" (default target) (1) -> (BscMake target) -> TRACKER : error TRK0005: Failed to locate: "bscmake.exe". The system cannot find the file specified. [c:\work\reduceops\graal\build\ vs-amd64\jvm.vcxproj] 14 Warning(s) 1 Error(s) Time Elapsed 00:00:59.12 RUNINDEBUGSHELL_ENDSEQUENCE c:\work\reduceops\graal>echo ERRXXX%errorlevel% ERRXXX1 Error building project c:\work\reduceops\graal> From dain at iq80.com Thu Dec 12 14:16:36 2013 From: dain at iq80.com (Dain Sundstrom) Date: Thu, 12 Dec 2013 14:16:36 -0800 Subject: Truffle performance problems Message-ID: Hi all, I have been experimenting with Truffle in Presto for a day now and am confused by the performance I am seeing. My high level goal of this experiment is to figure out how I should structure data flow in my Truffle language. Since, I am writing the language and the only user of that language together, I have a lot of options available to me. Specifically, I'd like to figure out if I should take a vectorized approach, a row at a time approach, or some combination of both. Which every solution is fastest, I'll make work in the code base. To this end, I decided to take a top down approach to Truffle (mainly because I am confident the bottom expression bits will be fast). I started with a very simple query hand-coded in Java: double sum = 0; for (row in source) { if (row passes the filter) { sum += row.extendedprice * row.discount } } return sum; When I run that on my machine using 5M rows of input (all in memory), it takes ~165ms using the Graal vm (1.7.0_45) with "-server" option on my laptop. With the performance baseline established, my plan was to start with a single node and then start breaking it apart into more nodes without making stuff slower. So, I wrapped this same code with a single Truffle RootNode. When I execute the same code though the Truffle call, I get the same performance until the node is compiled. Once the node is compiled, performance drops to ~260ms. Now, I understand using a single node is not the point of Truffle, but I would not expect such a massive performance drop off. At this point, I'm not sure if this is a worth while exercise at all. You can find all of the code and instructions on running it here: https://github.com/dain/presto-truffle/tree/master Any ideas or suggestions? Thanks, -dain On a related note, if you leave the Truffle test running it eventually crashes with (https://gist.github.com/dain/c3a29eb81642c86f5072): Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! I've also found "java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Inlined graph is in invalid state" when executing a CallTarget in tight inner loops. From thomas.wuerthinger at oracle.com Thu Dec 12 15:08:46 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 13 Dec 2013 00:08:46 +0100 Subject: Truffle performance problems In-Reply-To: References: Message-ID: <792B79E6-7EF5-4013-8536-F9128A895F98@oracle.com> Dain, We are not confused by the performance you are seeing as Truffle?s use case is the execution of expression trees with multiple smaller nodes (which capture profiling feedback) and not as a single node wrapping a complex Java method (which does not capture any profiling feedback). There is no expected performance gain from doing the latter - on the contrary, the manual specification of the inlining boundaries and the absence of Java profiling feedback can lead to performance losses. We will nevertheless investigate wether there is anything specifically wrong with Truffle?s compiler graph in your example. - thomas On 12 Dec 2013, at 23:16, Dain Sundstrom wrote: > Hi all, > > I have been experimenting with Truffle in Presto for a day now and am confused by the performance I am seeing. > > My high level goal of this experiment is to figure out how I should structure data flow in my Truffle language. Since, I am writing the language and the only user of that language together, I have a lot of options available to me. Specifically, I'd like to figure out if I should take a vectorized approach, a row at a time approach, or some combination of both. Which every solution is fastest, I'll make work in the code base. > > To this end, I decided to take a top down approach to Truffle (mainly because I am confident the bottom expression bits will be fast). I started with a very simple query hand-coded in Java: > > double sum = 0; > for (row in source) { > if (row passes the filter) { > sum += row.extendedprice * row.discount > } > } > return sum; > > When I run that on my machine using 5M rows of input (all in memory), it takes ~165ms using the Graal vm (1.7.0_45) with "-server" option on my laptop. > > With the performance baseline established, my plan was to start with a single node and then start breaking it apart into more nodes without making stuff slower. So, I wrapped this same code with a single Truffle RootNode. When I execute the same code though the Truffle call, I get the same performance until the node is compiled. Once the node is compiled, performance drops to ~260ms. > > Now, I understand using a single node is not the point of Truffle, but I would not expect such a massive performance drop off. At this point, I'm not sure if this is a worth while exercise at all. > > You can find all of the code and instructions on running it here: > > https://github.com/dain/presto-truffle/tree/master > > Any ideas or suggestions? > > Thanks, > > -dain > > > > On a related note, if you leave the Truffle test running it eventually crashes with (https://gist.github.com/dain/c3a29eb81642c86f5072): > > Found illegal recursive call to HotSpotMethod, must annotate such calls with @CompilerDirectives.SlowPath! > > I've also found "java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Inlined graph is in invalid state" when executing a CallTarget in tight inner loops. > From doug.simon at oracle.com Fri Dec 13 00:52:20 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 13 Dec 2013 08:52:20 +0000 Subject: hg: graal/graal: 49 new changesets Message-ID: <20131213085538.801B562CB1@hg.openjdk.java.net> Changeset: fdd6ef90d66d Author: twisti Date: 2013-12-07 17:11 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/fdd6ef90d66d move HotSpotResolvedPrimitiveType's from VMToCompilerImpl to HotSpotGraalRuntime ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: b16fb0b7479b Author: twisti Date: 2013-12-08 11:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b16fb0b7479b every HotSpotResolvedJavaMethod needs its own constant pool ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: f795de8d8b71 Author: twisti Date: 2013-12-08 11:21 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f795de8d8b71 use Unsafe.ensureClassInitialized in HotSpotResolvedObjectType.initialize ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 0ffe9e4bb364 Author: twisti Date: 2013-12-08 13:27 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/0ffe9e4bb364 don't go through VM to create HotSpotResolvedObjectType (part 1) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotSymbol.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantPool.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/HotSpotReplacementsUtil.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/stubs/NewArrayStub.java ! src/share/vm/graal/graalCodeInstaller.cpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f13f6dc290c8 Author: twisti Date: 2013-12-08 14:33 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f13f6dc290c8 don't pass HotSpotResolvedObjectType to VMToCompiler.compileMethod but instead create it in Java code ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp Changeset: 81055aacb98d Author: twisti Date: 2013-12-08 18:06 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/81055aacb98d removed CompilerToVM.getJavaField ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: b23cbfb4366a Author: twisti Date: 2013-12-08 21:55 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b23cbfb4366a merged CompilerToVM.getMetaspaceConstructor into CompilerToVM.getMetaspaceMethod ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMetaAccessProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 2d76d0c85345 Author: Roland Schatz Date: 2013-12-09 13:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2d76d0c85345 Make selection of x86 floating point move instruction extensible. ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64MacroAssembler.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64Arithmetic.java Changeset: 78ed696884b3 Author: Doug Simon Date: 2013-12-09 15:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/78ed696884b3 fixed regression in pylint command (exit code must be non-zero if at least one warning/error was found) ! mxtool/mx.py Changeset: 58d8de1f384b Author: Doug Simon Date: 2013-12-09 15:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/58d8de1f384b add support for JAVA7_HOME environment variable in igv command as a convenience work-around until igv works with jdk8 omit DaCapo eclipse from gate when running jdk8 ! mx/mx_graal.py Changeset: 68b964b6dc8e Author: Doug Simon Date: 2013-12-09 15:24 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/68b964b6dc8e introduced BlockEndOp interface and require that every LIR block is terminated by such an operation LIR BranchOps now control whether or not additional unconditional jump is emitted (obviating the need for the ControlFlowOptimizer to eliminate such jumps) ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64DeoptimizeOp.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotEpilogueOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/NewObjectSnippets.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/ControlFlowOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/EdgeMoveOptimizer.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LabelRef.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java Changeset: 8950e87ffcc9 Author: Doug Simon Date: 2013-12-09 17:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8950e87ffcc9 don't emit code for a JumpOp that goes to its successor ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java Changeset: d86dc1b84973 Author: Doug Simon Date: 2013-12-09 18:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d86dc1b84973 modified ProfilingInfoTest to better handle variability in profiling info provided by the runtime ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/MetaUtil.java ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/ProfilingInfoTest.java Changeset: 2b9fcffd6f36 Author: Christian Humer Date: 2013-12-01 18:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2b9fcffd6f36 Truffle-DSL: added support for generating execute methods with java varargs. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ExecuteEvaluatedTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/ast/CodeExecutableElement.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/codewriter/AbstractCodeWriter.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeData.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeParser.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/SpecializationData.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/ActualParameter.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/MethodSpec.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/TemplateMethod.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/TemplateMethodParser.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/GuardParser.java Changeset: 0b8335a4fb13 Author: Christian Humer Date: 2013-12-02 10:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0b8335a4fb13 Truffle-DSL: more testing for generating execute methods with varargs. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ExecuteEvaluatedTest.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java Changeset: 17b116b80aba Author: Christian Humer Date: 2013-12-02 11:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/17b116b80aba Truffle-DSL: added another test case for generating execute methods with varargs. ! graal/com.oracle.truffle.api.dsl.test/src/com/oracle/truffle/api/dsl/test/ExecuteEvaluatedTest.java Changeset: e4862151eefd Author: Christian Humer Date: 2013-12-02 13:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e4862151eefd Truffle-DSL: fixed varArgs parsing is only used for executable methods. parsing varargs specialization methods must remain untouched for now. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/ExecutableTypeMethodParser.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/template/TemplateMethodParser.java Changeset: bd5c996b5d25 Author: Christian Humer Date: 2013-12-05 13:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bd5c996b5d25 Truffle-DSL: fixed wrong transferToInterpreter with transferToInterpreterAndInvalidate. ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/node/NodeCodeGenerator.java ! graal/com.oracle.truffle.dsl.processor/src/com/oracle/truffle/dsl/processor/typesystem/TypeSystemCodeGenerator.java Changeset: 06afa0db90b3 Author: Christian Humer Date: 2013-12-09 17:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/06afa0db90b3 SL: removed unneccessary field in InlinableCallNode (reported by Stefan Marr) ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLNodeFactory.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/CallNode.java Changeset: ce017d1e4234 Author: Christian Humer Date: 2013-12-09 17:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ce017d1e4234 Merge. - graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXTargetMethodAssembler.java - graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/TargetMethodAssembler.java - graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackend.java - graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/AMD64HotSpotTruffleBackendFactory.java - graal/com.oracle.graal.truffle.hotspot.amd64/src/com/oracle/graal/truffle/hotspot/amd64/util/OptimizedCallTargetFieldInfo.java - graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleBackendFactory.java Changeset: 038f55aab194 Author: Christian Humer Date: 2013-12-10 11:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/038f55aab194 Merge. Changeset: 05de8cf71a41 Author: Doug Simon Date: 2013-12-10 21:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/05de8cf71a41 fixed broken assertions ! src/share/vm/oops/methodData.hpp Changeset: fbcdae53b17e Author: Doug Simon Date: 2013-12-10 22:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fbcdae53b17e force TypeProfileLevel to 0 in GRAAL until HotSpotMethodData is updated to be aware of the new profiling tags ! src/cpu/x86/vm/globals_x86.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 4a6787110408 Author: twisti Date: 2013-12-10 19:23 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/4a6787110408 added PrintBootstrap option ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: dc4128904f0b Author: Gilles Duboscq Date: 2013-12-05 13:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dc4128904f0b Make the guardsStage part of the hash for SnippetTemplate.CacheKey ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 17c9afa0bfcb Author: Gilles Duboscq Date: 2013-12-11 13:29 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/17c9afa0bfcb Allow GuardLoweringPhase, FrameStateAssignementPhase and the different lowerings to work with graph at any valid guards stage ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotLoweringProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FixedGuardNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/GuardingPiNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LoweringTool.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FrameStateAssignmentPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: a3500d145fe1 Author: Gilles Duboscq Date: 2013-12-10 10:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a3500d145fe1 make GuardLoweringPhase work even when no context can provide an implicitNullCheckLimit ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: 54248131f787 Author: Gilles Duboscq Date: 2013-12-05 17:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/54248131f787 InliningPhase asserts correct order on the garph stages ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java Changeset: a3c559c0e460 Author: Gilles Duboscq Date: 2013-12-10 17:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a3c559c0e460 SnippetTemplates does not use assumptions any more ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java Changeset: 9b053d478a4e Author: Gilles Duboscq Date: 2013-12-11 12:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9b053d478a4e Use the appropriate phases in order to change the guards stage ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/SnippetTemplate.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/nodes/MacroNode.java Changeset: 9c3c915b5f56 Author: Gilles Duboscq Date: 2013-12-11 12:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9c3c915b5f56 Log modiffied files during eclipseformat ! mxtool/mx.py Changeset: 1734954cc73d Author: Gilles Duboscq Date: 2013-12-11 13:48 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1734954cc73d Rename AccessNode to FixedAccessNode ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierAdditionPhase.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/phases/WriteBarrierVerificationPhase.java - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AccessNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FixedAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatableAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/ReadNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/WriteNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/LoweredCompareAndSwapNode.java Changeset: 492c9907b9bf Author: Gilles Duboscq Date: 2013-12-11 14:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/492c9907b9bf Move Access.setNullCheck to FixedAccessNode.setNullCheck. FloatingAccessNode.asFixedNode retruns a FixedAccessNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/Access.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingReadNode.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/FloatingReadPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: 01fd11e44f73 Author: Gilles Duboscq Date: 2013-12-11 14:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/01fd11e44f73 Access is not necessarily a DeoptimizingNode. In particular, FloatingAccessNodes are not DeoptimizingNode. ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotLIRGenerator.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotLIRGenerator.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/Access.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/FloatingAccessNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java Changeset: a8964e9bb948 Author: Gilles Duboscq Date: 2013-12-11 16:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a8964e9bb948 GRAAL-635: PartialEscapeClosure.processNodeWithState should support all NodeWithState correctly ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeWithState.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java Changeset: 5215f94f94ec Author: Gilles Duboscq Date: 2013-12-11 15:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5215f94f94ec GRAAL-632: Clarify difference between states managed by StateSplit and DeoptimizingNode ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingFixedWithNextNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/DeoptimizingNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/FrameState.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StateSplit.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeWithState.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 29907e69ae8d Author: Lukas Stadler Date: 2013-12-11 15:59 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/29907e69ae8d rework of switch generation: move code into platform independent SwitchStrategy, add boolean switch strategy ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.compiler.ptx/src/com/oracle/graal/compiler/ptx/PTXLIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILCompare.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java + graal/com.oracle.graal.lir/src/com/oracle/graal/lir/SwitchStrategy.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/IntegerSwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java Changeset: 903fd774dd61 Author: Doug Simon Date: 2013-12-11 20:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/903fd774dd61 simplified implementation of HotSpotResolvedObjectType.getClassInitializer() ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 0fd6c2ab852d Author: Doug Simon Date: 2013-12-11 20:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0fd6c2ab852d fixed regression in VerifyOptionsPhase such that it actually checks class initializers again ! graal/com.oracle.graal.java/src/com/oracle/graal/java/VerifyOptionsPhase.java Changeset: d2165b699e0f Author: Doug Simon Date: 2013-12-11 20:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d2165b699e0f removed unused import ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 5a3491b0c2f0 Author: Doug Simon Date: 2013-12-09 21:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5a3491b0c2f0 convert assertion in SchedulePhase to raise SchedulingError instead of AssertionError ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: d64c0112fb94 Author: Doug Simon Date: 2013-12-11 21:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d64c0112fb94 Merge. - graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/AccessNode.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: d5e65a244f7d Author: Lukas Stadler Date: 2013-12-12 09:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d5e65a244f7d rename BooleanSwitch to BinarySwitch ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/SwitchStrategy.java Changeset: 126ef8e8aa59 Author: Roland Schatz Date: 2013-12-12 17:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/126ef8e8aa59 Separate foreign calls into LEAF and LEAF_NOFP. ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotForeignCallsProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotForeignCallLinkage.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotForeignCallsProviderImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotHostForeignCallsProvider.java Changeset: 094f4ee93977 Author: Lukas Stadler Date: 2013-12-12 18:15 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/094f4ee93977 some javadoc for switch strategies ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.compiler.sparc/src/com/oracle/graal/compiler/sparc/SPARCLIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/SwitchStrategy.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/extended/SwitchNode.java Changeset: d8692e751c65 Author: Chris Seaton Date: 2013-12-12 20:09 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/d8692e751c65 Added trufflejar command, and abstracted packagejar. ! mx/mx_graal.py ! mx/projects Changeset: a1dae6b6d6d2 Author: Chris Seaton Date: 2013-12-12 20:09 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/a1dae6b6d6d2 Merge. Changeset: a63d65b682a8 Author: twisti Date: 2013-12-11 20:42 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a63d65b682a8 moved most HotSpotResolvedJavaMethod.getExceptionHandlers logic to Java ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ExceptionHandler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotUnresolvedJavaType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: dfb780080923 Author: twisti Date: 2013-12-12 14:56 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/dfb780080923 moved most CompilerToVM.getLocalVariableTable to Java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/debug/LocalImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp From doug.simon at oracle.com Fri Dec 13 01:45:36 2013 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 13 Dec 2013 10:45:36 +0100 Subject: webrev for HSAIL backend Math intrinsics support In-Reply-To: <5DD1503F815BD14889DC81D28643E3A7578A11C0@SATLEXDAG01.amd.com> References: <5DD1503F815BD14889DC81D28643E3A7578A11C0@SATLEXDAG01.amd.com> Message-ID: <3CBDBDEF-1653-48AF-B859-DA9A55622F8A@oracle.com> I?ve integrated this patch and am pushing it through now. Apart from some cosmetic touch ups, I also made the node intrinsics in HSAILMathSubstitutions native. This is the best way to keep the Java compiler happy while failing fast should those methods ever be interpreted as a result of deoptimization. -Doug On Dec 12, 2013, at 8:35 PM, Venkatachalam, Vasanth wrote: > > Hi, > > I've uploaded a webrev that adds support to the HSAIL backend for intrinsifying some of the java.lang.Math routines. > > http://cr.openjdk.java.net/~tdeneau/webrev-mathintrinsics05/webrev/ > > Please review and provide feedback. When ready for commit, please commit it in my name. > > Implementation Notes: > > > 1) The java.lang.Math routines that are covered in this webrev include Math.sqrt, Math.abs, Math.rint, Math.floor, and Math.ceil. > > Based on the HSAIL spec and the precision requirements of Java these are the most straightforward to implement. > > 2) The main changes are the addition of an HSAILMathSubstitutions class and an HSAILMathIntrinsicNode to define the new intrinsics, and supporting changes in HSAILLIRGenerator and HSAILArithmetic to handle the code generation. > > 3) Test cases have been included for testing each of the intrinsics included in this webrev. The tests exercise positive and negative values as well as corner cases mentioned in the java.lang.Math spec for the above five routines. > > Vasanth From duboscq at ssw.jku.at Fri Dec 13 08:09:37 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 13 Dec 2013 17:09:37 +0100 Subject: Truffle performance problems In-Reply-To: <792B79E6-7EF5-4013-8536-F9128A895F98@oracle.com> References: <792B79E6-7EF5-4013-8536-F9128A895F98@oracle.com> Message-ID: Hi, About this "illegal recursive call", the inlining that happens during a Truffle compilation is definitely not made the be used on just any Java code. It is really made for Truffle interpreters. You can think of it as inlining *every* call it manages to de-virtualize. When writing a Truffle interpreter, the nodes only include the fast path for the current "profile" or "specialization". When you need a slow path, you can call some method that you annotate with @CompilerDirectives.SlowPath which means that the Truffle compilation will not inline through that path. (if i'm not mistaken, he Graal compiler may later decide to inline it anyway but then the decisions are the same than for normal Java code). -Gilles On Fri, Dec 13, 2013 at 12:08 AM, Thomas Wuerthinger < thomas.wuerthinger at oracle.com> wrote: > Dain, > > We are not confused by the performance you are seeing as Truffle?s use > case is the execution of expression trees with multiple smaller nodes > (which capture profiling feedback) and not as a single node wrapping a > complex Java method (which does not capture any profiling feedback). There > is no expected performance gain from doing the latter - on the contrary, > the manual specification of the inlining boundaries and the absence of Java > profiling feedback can lead to performance losses. We will nevertheless > investigate wether there is anything specifically wrong with Truffle?s > compiler graph in your example. > > - thomas > > > On 12 Dec 2013, at 23:16, Dain Sundstrom wrote: > > > Hi all, > > > > I have been experimenting with Truffle in Presto for a day now and am > confused by the performance I am seeing. > > > > My high level goal of this experiment is to figure out how I should > structure data flow in my Truffle language. Since, I am writing the > language and the only user of that language together, I have a lot of > options available to me. Specifically, I'd like to figure out if I should > take a vectorized approach, a row at a time approach, or some combination > of both. Which every solution is fastest, I'll make work in the code base. > > > > To this end, I decided to take a top down approach to Truffle (mainly > because I am confident the bottom expression bits will be fast). I started > with a very simple query hand-coded in Java: > > > > double sum = 0; > > for (row in source) { > > if (row passes the filter) { > > sum += row.extendedprice * row.discount > > } > > } > > return sum; > > > > When I run that on my machine using 5M rows of input (all in memory), it > takes ~165ms using the Graal vm (1.7.0_45) with "-server" option on my > laptop. > > > > With the performance baseline established, my plan was to start with a > single node and then start breaking it apart into more nodes without making > stuff slower. So, I wrapped this same code with a single Truffle RootNode. > When I execute the same code though the Truffle call, I get the same > performance until the node is compiled. Once the node is compiled, > performance drops to ~260ms. > > > > Now, I understand using a single node is not the point of Truffle, but I > would not expect such a massive performance drop off. At this point, I'm > not sure if this is a worth while exercise at all. > > > > You can find all of the code and instructions on running it here: > > > > https://github.com/dain/presto-truffle/tree/master > > > > Any ideas or suggestions? > > > > Thanks, > > > > -dain > > > > > > > > On a related note, if you leave the Truffle test running it eventually > crashes with (https://gist.github.com/dain/c3a29eb81642c86f5072): > > > > Found illegal recursive call to > HotSpotMethod, > must annotate such calls with @CompilerDirectives.SlowPath! > > > > I've also found "java.util.concurrent.ExecutionException: > java.lang.IllegalStateException: Inlined graph is in invalid state" when > executing a CallTarget in tight inner loops. > > > > From doug.simon at oracle.com Fri Dec 13 07:57:10 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Fri, 13 Dec 2013 15:57:10 +0000 Subject: hg: graal/graal: 15 new changesets Message-ID: <20131213155802.9A78F62CC3@hg.openjdk.java.net> Changeset: c9dd3d5000e8 Author: Doug Simon Date: 2013-12-13 10:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c9dd3d5000e8 added ExceptionHandler.hashCode() to remove Eclipse warning ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ExceptionHandler.java Changeset: d3b3c6e17d40 Author: Doug Simon Date: 2013-12-13 10:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d3b3c6e17d40 HSAIL: added Math intrinsifications Contributed-by: Vasanth Venkatachalam ! graal/com.oracle.graal.compiler.hsail.test.infra/src/com/oracle/graal/compiler/hsail/test/infra/KernelTester.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/DoubleAbsTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/DoubleCeilTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/DoubleFloorTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/DoubleRintTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/DoubleSqrtTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatAbsTest.java ! graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatDivPrecisionTest.java - graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatSqrtTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/IntAbsTest.java + graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/LongAbsTest.java ! graal/com.oracle.graal.compiler.hsail/src/com/oracle/graal/compiler/hsail/HSAILLIRGenerator.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILArithmetic.java + graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/HSAILMathIntrinsicsNode.java + graal/com.oracle.graal.replacements.hsail/src/com/oracle/graal/replacements/hsail/HSAILMathSubstitutions.java ! mx/projects Changeset: 32d2b0de15a8 Author: Doug Simon Date: 2013-12-13 12:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/32d2b0de15a8 added instructions for pushing and popping CPU state flags ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java Changeset: 733cccc125ed Author: Doug Simon Date: 2013-12-13 13:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/733cccc125ed added subqWide to AMD64Assembler renamed HotSpotHostBackend.stackShadowPages to pagesToBang ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotHostBackend.java Changeset: 428c70133bef Author: Doug Simon Date: 2013-12-13 13:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/428c70133bef clarified requirements when overriding LIRGeneratorTool.beforeRegisterAllocation() ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/LIRGeneratorTool.java Changeset: 323d99404728 Author: Doug Simon Date: 2013-12-13 13:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/323d99404728 added missing exception_seen and null_seen info info when formatting some profile data as strings ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotMethodData.java Changeset: 6dd9a1455e64 Author: Doug Simon Date: 2013-12-13 13:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6dd9a1455e64 renamed PlaceholderOp to NoOp ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotLIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java Changeset: 4c3e527bf857 Author: Doug Simon Date: 2013-12-13 13:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4c3e527bf857 added test for any optimization that commons loads of non-inlineable constants + graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CommonedConstantsTest.java Changeset: ab7d5804a6f9 Author: Doug Simon Date: 2013-12-13 13:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ab7d5804a6f9 moved call to beforeRegisterAllocation() to be within "LIRGen" debug scope ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalCompiler.java Changeset: 26472d911fcd Author: Doug Simon Date: 2013-12-13 13:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/26472d911fcd improved LabelRef.toString() ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LabelRef.java Changeset: 755645fa92d6 Author: Doug Simon Date: 2013-12-13 13:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/755645fa92d6 the load of a constant is commoned to the nearest block dominating all usages (GRAAL-508) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java Changeset: da0851712519 Author: Doug Simon Date: 2013-12-13 14:05 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/da0851712519 moved emitting code for LIR and queries about whether an edge goes to its lexical successor "inside" CompilationResultBuilder ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackend.java ! graal/com.oracle.graal.hotspot.hsail/src/com/oracle/graal/hotspot/hsail/HSAILHotSpotBackend.java ! graal/com.oracle.graal.hotspot.ptx/src/com/oracle/graal/hotspot/ptx/PTXHotSpotBackend.java ! graal/com.oracle.graal.hotspot.sparc/src/com/oracle/graal/hotspot/sparc/SPARCHotSpotBackend.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java ! graal/com.oracle.graal.lir.hsail/src/com/oracle/graal/lir/hsail/HSAILControlFlow.java ! graal/com.oracle.graal.lir.ptx/src/com/oracle/graal/lir/ptx/PTXControlFlow.java ! graal/com.oracle.graal.lir.sparc/src/com/oracle/graal/lir/sparc/SPARCControlFlow.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LabelRef.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/StandardOp.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/SwitchStrategy.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/asm/CompilationResultBuilder.java Changeset: 30e57b49fdb1 Author: Chris Seaton Date: 2013-12-13 13:54 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/30e57b49fdb1 Include annotation processor meta-info in Truffle JAR. ! mx/mx_graal.py Changeset: 093353894575 Author: Chris Seaton Date: 2013-12-13 14:26 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/093353894575 Test the Truffle JAR after building. ! mx/mx_graal.py Changeset: e585ac5a385d Author: Chris Seaton Date: 2013-12-13 14:27 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/e585ac5a385d Merge. From tom.deneau at amd.com Fri Dec 13 09:15:12 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 13 Dec 2013 17:15:12 +0000 Subject: assert((uint)reason < _trap_hist_limit) failed: oob Message-ID: Hello -- Running the attached class files with the following command line ./mx.sh --vm graal --vmbuild fastdebug vm -XX:-BootstrapGraal -Xmx1g AryBounds I get # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/tom/graal/src/share/vm/oops/methodData.hpp:2196), pid=24304, tid=140302327252736 # assert((uint)reason < _trap_hist_limit) failed: oob # # JRE version: Java(TM) SE Runtime Environment (7.0_21-b11) (build 1.7.0_21-b11) # Java VM: OpenJDK 64-Bit Graal VM (25.0-b59-internal-fastdebug mixed mode linux-amd64 compressed oops) -- Tom From duboscq at ssw.jku.at Fri Dec 13 09:24:41 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 13 Dec 2013 18:24:41 +0100 Subject: assert((uint)reason < _trap_hist_limit) failed: oob In-Reply-To: References: Message-ID: I can not see your attachment (I don't think the mailing list relays attachments) but this was fixed in http://hg.openjdk.java.net/graal/graal/rev/05de8cf71a41 -Gilles On Fri, Dec 13, 2013 at 6:15 PM, Tom Deneau wrote: > Hello -- > > Running the attached class files with the following command line > > ./mx.sh --vm graal --vmbuild fastdebug vm -XX:-BootstrapGraal -Xmx1g > AryBounds > > I get > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/tom/graal/src/share/vm/oops/methodData.hpp:2196), > pid=24304, tid=140302327252736 > # assert((uint)reason < _trap_hist_limit) failed: oob > # > # JRE version: Java(TM) SE Runtime Environment (7.0_21-b11) (build > 1.7.0_21-b11) > # Java VM: OpenJDK 64-Bit Graal VM (25.0-b59-internal-fastdebug mixed mode > linux-amd64 compressed oops) > > -- Tom > From tom.deneau at amd.com Fri Dec 13 09:27:10 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 13 Dec 2013 17:27:10 +0000 Subject: assert((uint)reason < _trap_hist_limit) failed: oob In-Reply-To: References: Message-ID: OK, I will sync with latest trunk. From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Friday, December 13, 2013 11:25 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: assert((uint)reason < _trap_hist_limit) failed: oob I can not see your attachment (I don't think the mailing list relays attachments) but this was fixed in http://hg.openjdk.java.net/graal/graal/rev/05de8cf71a41 -Gilles On Fri, Dec 13, 2013 at 6:15 PM, Tom Deneau > wrote: Hello -- Running the attached class files with the following command line ./mx.sh --vm graal --vmbuild fastdebug vm -XX:-BootstrapGraal -Xmx1g AryBounds I get # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/tom/graal/src/share/vm/oops/methodData.hpp:2196), pid=24304, tid=140302327252736 # assert((uint)reason < _trap_hist_limit) failed: oob # # JRE version: Java(TM) SE Runtime Environment (7.0_21-b11) (build 1.7.0_21-b11) # Java VM: OpenJDK 64-Bit Graal VM (25.0-b59-internal-fastdebug mixed mode linux-amd64 compressed oops) -- Tom From tom.deneau at amd.com Fri Dec 13 09:56:12 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 13 Dec 2013 17:56:12 +0000 Subject: assert((uint)reason < _trap_hist_limit) failed: oob In-Reply-To: References: Message-ID: Yes this trap_hist_limit problem is fixed. I still see another assert failure if I use -XX:+PrintDeoptimizationDetails in fastdebug (with an example that does a deopt). If you need my class files to reproduce let me know. # Internal Error (/home/tom/graal/src/share/vm/runtime/mutex.cpp:1364), pid=30164, tid=139715571808000 # assert((!thread->is_Java_thread() || ((JavaThread *)thread)->thread_state() == _thread_in_vm) || rank() == Mutex::special) failed: wrong thread state for using locks # -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Friday, December 13, 2013 11:25 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: assert((uint)reason < _trap_hist_limit) failed: oob I can not see your attachment (I don't think the mailing list relays attachments) but this was fixed in http://hg.openjdk.java.net/graal/graal/rev/05de8cf71a41 -Gilles On Fri, Dec 13, 2013 at 6:15 PM, Tom Deneau > wrote: Hello -- Running the attached class files with the following command line ./mx.sh --vm graal --vmbuild fastdebug vm -XX:-BootstrapGraal -Xmx1g AryBounds I get # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/tom/graal/src/share/vm/oops/methodData.hpp:2196), pid=24304, tid=140302327252736 # assert((uint)reason < _trap_hist_limit) failed: oob # # JRE version: Java(TM) SE Runtime Environment (7.0_21-b11) (build 1.7.0_21-b11) # Java VM: OpenJDK 64-Bit Graal VM (25.0-b59-internal-fastdebug mixed mode linux-amd64 compressed oops) -- Tom From duboscq at ssw.jku.at Fri Dec 13 10:33:11 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 13 Dec 2013 19:33:11 +0100 Subject: assert((uint)reason < _trap_hist_limit) failed: oob In-Reply-To: References: Message-ID: This patch should fix this: -----8<---------------------------------------------------------- diff -r e1365fd16104 -r 63724649e19e src/share/vm/runtime/vframe.cpp --- a/src/share/vm/runtime/vframe.cpp Fri Dec 13 16:39:06 2013 +0100 +++ b/src/share/vm/runtime/vframe.cpp Fri Dec 13 19:31:10 2013 +0100 @@ -266,7 +266,7 @@ // Get oopmap describing oops and int for current bci InterpreterOopMap oop_mask; - if (TraceDeoptimization && Verbose) { + if ((TraceDeoptimization && Verbose) GRAAL_ONLY( || PrintDeoptimizationDetails)) { methodHandle m_h(thread(), method()); OopMapCache::compute_one_oop_map(m_h, bci(), &oop_mask); } else { @@ -333,7 +333,7 @@ InterpreterOopMap oop_mask; // Get oopmap describing oops and int for current bci - if (TraceDeoptimization && Verbose) { + if ((TraceDeoptimization && Verbose) GRAAL_ONLY( || PrintDeoptimizationDetails)) { methodHandle m_h(method()); OopMapCache::compute_one_oop_map(m_h, bci(), &oop_mask); } else { ---------------------------------------------------------->8----- Tell me if it helped. -Gilles On Fri, Dec 13, 2013 at 6:56 PM, Tom Deneau wrote: > Yes this trap_hist_limit problem is fixed. > > > > I still see another assert failure if I use > -XX:+PrintDeoptimizationDetails in fastdebug (with an example that does a > deopt). > > If you need my class files to reproduce let me know. > > > > # Internal Error (/home/tom/graal/src/share/vm/runtime/mutex.cpp:1364), > pid=30164, tid=139715571808000 > > # assert((!thread->is_Java_thread() || ((JavaThread > *)thread)->thread_state() == _thread_in_vm) || rank() == Mutex::special) > failed: wrong thread state for using locks > > # > > -- Tom > > > > > > *From:* gilwooden at gmail.com [mailto:gilwooden at gmail.com] *On Behalf Of *Gilles > Duboscq > *Sent:* Friday, December 13, 2013 11:25 AM > *To:* Deneau, Tom > *Cc:* graal-dev at openjdk.java.net > *Subject:* Re: assert((uint)reason < _trap_hist_limit) failed: oob > > > > I can not see your attachment (I don't think the mailing list relays > attachments) but this was fixed in > http://hg.openjdk.java.net/graal/graal/rev/05de8cf71a41 > > > > -Gilles > > > > On Fri, Dec 13, 2013 at 6:15 PM, Tom Deneau wrote: > > Hello -- > > Running the attached class files with the following command line > > ./mx.sh --vm graal --vmbuild fastdebug vm -XX:-BootstrapGraal -Xmx1g > AryBounds > > I get > > > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/tom/graal/src/share/vm/oops/methodData.hpp:2196), > pid=24304, tid=140302327252736 > # assert((uint)reason < _trap_hist_limit) failed: oob > # > # JRE version: Java(TM) SE Runtime Environment (7.0_21-b11) (build > 1.7.0_21-b11) > # Java VM: OpenJDK 64-Bit Graal VM (25.0-b59-internal-fastdebug mixed mode > linux-amd64 compressed oops) > > -- Tom > > > From christian.thalinger at oracle.com Fri Dec 13 11:19:45 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 13 Dec 2013 11:19:45 -0800 Subject: FYI: PrintBootstrap option Message-ID: <63CCE49E-D9C5-43F5-B0DD-D439A3798EDE@oracle.com> Sometimes tests or benchmarks do output verification. For cases like this I?ve added a PrintBootstrap option that suppresses the bootstrapping output: http://hg.openjdk.java.net/graal/graal/rev/4a6787110408 The default value is on so default behavior hasn?t changed. From tom.deneau at amd.com Fri Dec 13 11:47:34 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 13 Dec 2013 19:47:34 +0000 Subject: assert((uint)reason < _trap_hist_limit) failed: oob In-Reply-To: References: Message-ID: Gilles -- Yes this fixed it? -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Friday, December 13, 2013 12:33 PM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: assert((uint)reason < _trap_hist_limit) failed: oob This patch should fix this: -----8<---------------------------------------------------------- diff -r e1365fd16104 -r 63724649e19e src/share/vm/runtime/vframe.cpp --- a/src/share/vm/runtime/vframe.cpp Fri Dec 13 16:39:06 2013 +0100 +++ b/src/share/vm/runtime/vframe.cpp Fri Dec 13 19:31:10 2013 +0100 @@ -266,7 +266,7 @@ // Get oopmap describing oops and int for current bci InterpreterOopMap oop_mask; - if (TraceDeoptimization && Verbose) { + if ((TraceDeoptimization && Verbose) GRAAL_ONLY( || PrintDeoptimizationDetails)) { methodHandle m_h(thread(), method()); OopMapCache::compute_one_oop_map(m_h, bci(), &oop_mask); } else { @@ -333,7 +333,7 @@ InterpreterOopMap oop_mask; // Get oopmap describing oops and int for current bci - if (TraceDeoptimization && Verbose) { + if ((TraceDeoptimization && Verbose) GRAAL_ONLY( || PrintDeoptimizationDetails)) { methodHandle m_h(method()); OopMapCache::compute_one_oop_map(m_h, bci(), &oop_mask); } else { ---------------------------------------------------------->8----- Tell me if it helped. -Gilles On Fri, Dec 13, 2013 at 6:56 PM, Tom Deneau > wrote: Yes this trap_hist_limit problem is fixed. I still see another assert failure if I use -XX:+PrintDeoptimizationDetails in fastdebug (with an example that does a deopt). If you need my class files to reproduce let me know. # Internal Error (/home/tom/graal/src/share/vm/runtime/mutex.cpp:1364), pid=30164, tid=139715571808000 # assert((!thread->is_Java_thread() || ((JavaThread *)thread)->thread_state() == _thread_in_vm) || rank() == Mutex::special) failed: wrong thread state for using locks # -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Friday, December 13, 2013 11:25 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net Subject: Re: assert((uint)reason < _trap_hist_limit) failed: oob I can not see your attachment (I don't think the mailing list relays attachments) but this was fixed in http://hg.openjdk.java.net/graal/graal/rev/05de8cf71a41 -Gilles On Fri, Dec 13, 2013 at 6:15 PM, Tom Deneau > wrote: Hello -- Running the attached class files with the following command line ./mx.sh --vm graal --vmbuild fastdebug vm -XX:-BootstrapGraal -Xmx1g AryBounds I get # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/tom/graal/src/share/vm/oops/methodData.hpp:2196), pid=24304, tid=140302327252736 # assert((uint)reason < _trap_hist_limit) failed: oob # # JRE version: Java(TM) SE Runtime Environment (7.0_21-b11) (build 1.7.0_21-b11) # Java VM: OpenJDK 64-Bit Graal VM (25.0-b59-internal-fastdebug mixed mode linux-amd64 compressed oops) -- Tom From doug.simon at oracle.com Sat Dec 14 18:00:12 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 15 Dec 2013 02:00:12 +0000 Subject: hg: graal/graal: 12 new changesets Message-ID: <20131215020116.E86F462CF2@hg.openjdk.java.net> Changeset: f28ea693056f Author: Chris Seaton Date: 2013-12-13 15:53 +0000 URL: http://hg.openjdk.java.net/graal/graal/rev/f28ea693056f New assumption utilities. + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/AlwaysValidAssumptionTest.java + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/AssumedValueTest.java + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/CyclicAssumptionTest.java + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/UnionAssumptionTest.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/AlwaysValidAssumption.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/AssumedValue.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/CyclicAssumption.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/UnionAssumption.java Changeset: 48e821e409eb Author: Gilles Duboscq Date: 2013-12-13 19:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/48e821e409eb Add Debug.isDumpEnabledForMethod() and Debug.isLogEnabledForMethod() use it to diable graph compression and enable guard-id-as-debug-id ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/GraalDebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/Debug.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DebugConfig.java ! graal/com.oracle.graal.debug/src/com/oracle/graal/debug/DelegatingDebugConfig.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/GuardLoweringPhase.java Changeset: e1365fd16104 Author: Gilles Duboscq Date: 2013-12-13 16:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e1365fd16104 Make LoweringPhase more robust to disapearing anchors ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/LoweringPhase.java Changeset: 63724649e19e Author: Gilles Duboscq Date: 2013-12-13 19:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/63724649e19e Fix native assertion failure when using PrintDeoptimizationDetails in non-product build ! src/share/vm/runtime/vframe.cpp Changeset: ac5243877cc7 Author: Doug Simon Date: 2013-12-13 14:10 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ac5243877cc7 made commoning of loading constants non-configurable (GRAAL-508) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: c258331fdde6 Author: Doug Simon Date: 2013-12-13 14:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c258331fdde6 removed support for external nodes (GRAAL-508) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/NodeClass.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopEx.java ! graal/com.oracle.graal.loop/src/com/oracle/graal/loop/LoopFragment.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/ConstantNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StructuredGraph.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/util/GraphUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/DeadCodeEliminationPhase.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java ! graal/com.oracle.graal.printer/src/com/oracle/graal/printer/BinaryGraphPrinter.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/EffectsClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/VirtualUtil.java Changeset: 5e94b8c9e9d0 Author: Doug Simon Date: 2013-12-13 20:16 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5e94b8c9e9d0 added comment explaining insertion of nop during commoning of constant loads ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 5d47d69d523a Author: Doug Simon Date: 2013-12-13 20:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5d47d69d523a Merge. ! graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Graph.java Changeset: 1f4c9729c9f0 Author: Lukas Stadler Date: 2013-12-13 22:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1f4c9729c9f0 add base class for new object nodes, simplification to remove new objects without real usages ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewArrayNode.java + graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/AbstractNewObjectNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/DynamicNewArrayNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/NewInstanceNode.java Changeset: 51b2999299bc Author: Andreas Woess Date: 2013-12-14 02:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/51b2999299bc make TruffleRuntime field final ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/Truffle.java Changeset: ecea358f97be Author: Andreas Woess Date: 2013-12-14 02:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ecea358f97be mx trufflejar: do not strip debug attributes ! mx/mx_graal.py Changeset: 1c446564d36c Author: Andreas Woess Date: 2013-12-14 03:04 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1c446564d36c AlwaysValidAssumption: fix typo and make constructor private ! graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/AlwaysValidAssumptionTest.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/AlwaysValidAssumption.java From doug.simon at oracle.com Mon Dec 16 02:08:13 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Mon, 16 Dec 2013 10:08:13 +0000 Subject: hg: graal/graal: 13 new changesets Message-ID: <20131216100922.35E4162D0E@hg.openjdk.java.net> Changeset: 39694f3b0ed9 Author: Christian Humer Date: 2013-12-15 21:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/39694f3b0ed9 Truffle: set default TruffleInliningMaxCallerSize to 2250. ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCompilerOptions.java Changeset: 8531c47138dc Author: Christian Humer Date: 2013-12-15 22:19 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8531c47138dc Truffle: introduced new profiling utility BranchProfile. + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/BranchProfileTest.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/utilities/BranchProfile.java Changeset: d4c6dd07be76 Author: Christian Humer Date: 2013-12-15 22:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d4c6dd07be76 SL: added exemplary uses of new profiling utility BranchProfile to SL. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/IfNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadArgumentNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/ReadFunctionNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/WhileNode.java Changeset: ecf152c6bd16 Author: Christian Humer Date: 2013-12-15 22:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ecf152c6bd16 Truffle: added getFrameDescriptor to DefaultCallTarget. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/impl/DefaultCallTarget.java Changeset: 652f24858aad Author: Christian Humer Date: 2013-12-15 23:32 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/652f24858aad SL: simplified call nodes. aligned builtin inlining with user function inlining. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/CallNode.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/FunctionRootNode.java Changeset: 3603fab248a6 Author: Erik Eckstein Date: 2013-12-13 07:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3603fab248a6 added redundant move elimination as post-pass to LinearScan ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java + graal/com.oracle.graal.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java Changeset: 9423a38d6437 Author: Erik Eckstein Date: 2013-12-13 08:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9423a38d6437 added rematerialization of constants in LinearScan, but still disabled ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/MoveResolver.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIRFrameState.java Changeset: 79ed7180745c Author: Erik Eckstein Date: 2013-12-13 09:36 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/79ed7180745c fixed formatting problem in LinearScanWalker ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java Changeset: ebe32617cd65 Author: Erik Eckstein Date: 2013-12-13 16:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ebe32617cd65 cosmetic change in debug logging of graph builder ! graal/com.oracle.graal.java/src/com/oracle/graal/java/GraphBuilderPhase.java Changeset: 5dd9670009df Author: Erik Eckstein Date: 2013-12-13 16:11 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5dd9670009df fixed: parameter registers missing from caller saved set if excluded with the RegisterPressure option ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotRegisterConfig.java Changeset: e01fe53ec4b7 Author: Erik Eckstein Date: 2013-12-13 16:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e01fe53ec4b7 Merge Changeset: 0393767ae0fc Author: Erik Eckstein Date: 2013-12-13 16:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0393767ae0fc Merge ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: f17969ae4a35 Author: Erik Eckstein Date: 2013-12-16 08:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/f17969ae4a35 Merge ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java From java at stefan-marr.de Mon Dec 16 02:13:34 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 16 Dec 2013 11:13:34 +0100 Subject: Regression for TraceTruffleCompilationDetails? Message-ID: Hi: I am running here into a class cast exception when using -G:+TraceTruffleCompilationDetails: java.lang.ClassCastException: com.oracle.graal.truffle.nodes.frame.NewFrameNode cannot be cast to com.oracle.graal.nodes.ConstantNode at com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:193) The corresponding line is: ConstantNode constantNode = (ConstantNode) methodCallTargetNode.arguments().first(); However, the first argument is not a ConstantNode but a NewFrameNode (the new frame node looks like one of mine, i.e., for a TruffleSOM method call). The targetMethod of is `HotSpotMethod`. The problem can be triggered for instance with the following TruffleSOM benchmark: ./mx.sh -d --vm server vm -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 I suppose the receiver is here expected to be constant to print out tracing information, but it isn?t in my case. Is there perhaps some simple work-around possible? Thanks Stefan To check out TruffleSOM: git clone --recursive https://github.com/smarr/TruffleSOM.git cd TruffleSOM ant jar cd $GRAAL -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From christian.humer at gmail.com Mon Dec 16 02:51:52 2013 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 16 Dec 2013 11:51:52 +0100 Subject: Regression for TraceTruffleCompilationDetails? In-Reply-To: References: Message-ID: Hi Stefan, Could you please provide a little more robust command line for the problem? I just completely failed to run it on windows. - Christian Humer On Mon, Dec 16, 2013 at 11:13 AM, Stefan Marr wrote: > Hi: > > I am running here into a class cast exception when using > -G:+TraceTruffleCompilationDetails: > > java.lang.ClassCastException: > com.oracle.graal.truffle.nodes.frame.NewFrameNode cannot be cast to > com.oracle.graal.nodes.ConstantNode > at > com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:193) > > The corresponding line is: > ConstantNode constantNode = (ConstantNode) > methodCallTargetNode.arguments().first(); > > However, the first argument is not a ConstantNode but a NewFrameNode (the > new frame node looks like one of mine, i.e., for a TruffleSOM method call). > > The targetMethod of is > `HotSpotMethod`. > > The problem can be triggered for instance with the following TruffleSOM > benchmark: > > ./mx.sh -d --vm server vm -G:+TraceTruffleCompilationDetails > -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar > som.vm.Universe -cp ../som/Smalltalk > ../som/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 > > I suppose the receiver is here expected to be constant to print out > tracing information, but it isn?t in my case. > > Is there perhaps some simple work-around possible? > > Thanks > Stefan > > To check out TruffleSOM: > > git clone --recursive https://github.com/smarr/TruffleSOM.git > cd TruffleSOM > ant jar > cd $GRAAL > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From java at stefan-marr.de Mon Dec 16 05:57:32 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 16 Dec 2013 14:57:32 +0100 Subject: Regression for TraceTruffleCompilationDetails? In-Reply-To: References: Message-ID: Hi Christian: Since I don?t know exactly whether there is anything Windows related going wrong, perhaps a few additional notes on my setup. I think, the standard problems should be that either the paths in the command line are not correct, or the git repo wasn?t checked out with its submodules: To clone the git repo of TruffleSOM with its submodules: git clone --recursive https://github.com/smarr/TruffleSOM.git In contrast to other Truffle languages, TruffleSOM wasn?t yet adapted to the mx compilation infrastructure, but uses a simple ant script. Executing `ant tests` should compile the necessary files and execute a simple test. Note, it will download the necessary precompiled Truffle jars. I guess, that should work on Windows. Afterwards, it will depend on where your Graal folder is located. The command line assumes that it is in a folder next to TruffleSOM, so in the command line, `../TruffleSOM` would need to be replaced for other locations accordingly. Perhaps the path separators need to be changed for windows as well. > ./mx.sh --vm server vm -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../TruffleSOM/build/classes:../TruffleSOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../TruffleSOM/Smalltalk ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 After the mx.sh arguments, the bootclass path is set to include the Truffle libraries, as well as the compiled TruffleSOM classes (from the build/classes folder). The main class of TruffleSOM is som.vm.Universe, `-cp` gives a class path to SOM to enabled to find its Smalltalk class library, and the main script to be executed is ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som with a name for the benchmark and infos on how many iterations, and warmup cycles should be executed. Thanks for looking into the issue. I worked around it by just catching the exception for the moment. Best regards Stefan On 16 Dec 2013, at 11:51, Christian Humer wrote: > Hi Stefan, > > Could you please provide a little more robust command line for the problem? > I just completely failed to run it on windows. > > > - Christian Humer > > > On Mon, Dec 16, 2013 at 11:13 AM, Stefan Marr wrote: > Hi: > > I am running here into a class cast exception when using -G:+TraceTruffleCompilationDetails: > > java.lang.ClassCastException: com.oracle.graal.truffle.nodes.frame.NewFrameNode cannot be cast to com.oracle.graal.nodes.ConstantNode > at com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:193) > > The corresponding line is: > ConstantNode constantNode = (ConstantNode) methodCallTargetNode.arguments().first(); > > However, the first argument is not a ConstantNode but a NewFrameNode (the new frame node looks like one of mine, i.e., for a TruffleSOM method call). > > The targetMethod of is `HotSpotMethod`. > > The problem can be triggered for instance with the following TruffleSOM benchmark: > > ./mx.sh -d --vm server vm -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 > > I suppose the receiver is here expected to be constant to print out tracing information, but it isn?t in my case. > > Is there perhaps some simple work-around possible? > > Thanks > Stefan > > To check out TruffleSOM: > > git clone --recursive https://github.com/smarr/TruffleSOM.git > cd TruffleSOM > ant jar > cd $GRAAL > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From tom.deneau at amd.com Mon Dec 16 08:14:27 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Dec 2013 16:14:27 +0000 Subject: UnwindNode and deoptimization Message-ID: Gilles, Doug, etc. --- In our recent hsail backend deoptimization experiments, as mentioned previously, we noticed that something like a BoundsCheckException can be presented to the LIR as either a DeoptimizeNode or an UnwindNode (the UnwindNodes came if there was profiling information I think). Anyway, since we want to handle both of these the same way, namely deoptimizing, when we saw un UnwindNode, we were getting our LIRFrameState by looking at the deoptState of the ForeignCallNode exception that is part of the unwindNode. I noticed in a sync with the latest trunk that this infrastructure has changed now and the ForeignCallNode will often have a deoptState of null. I see that there is a deoptState on the ForeignCallNode.next which is a NullCheckNode which I suppose could be used but I'm not sure that's the right approach. I was wondering what is the "right" way to handle this. I think the high level summary is that if in the HSAIL backend we are presented with an UnwindNode with an associated ForeignCallNode, we cannot handle the ForeignCall in HSAIL and would like to treat this as a deoptimization. Is there some node transformation perhaps that we should be doing to accomplish this? -- Tom From tom.deneau at amd.com Mon Dec 16 08:21:14 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Dec 2013 16:21:14 +0000 Subject: hsail gate commands Message-ID: Doug -- I noticed in syncing with the trunk as of last Friday that all of our HSAIL test cases broke. The cause was some imperfect code in our HSAILAssembler for compare instructions which when presented with an unordered compare could generate code that would not assemble, and was easy to fix. But I was wondering how this made it past the gate. Can you describe what gate commands are used regarding hsail? -- Tom From doug.simon at oracle.com Mon Dec 16 08:35:52 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 16 Dec 2013 17:35:52 +0100 Subject: hsail gate commands In-Reply-To: References: Message-ID: On Dec 16, 2013, at 5:21 PM, Deneau, Tom wrote: > Doug -- > > I noticed in syncing with the trunk as of last Friday that all of our HSAIL test cases broke. The cause was some imperfect code in our HSAILAssembler for compare instructions which when presented with an unordered compare could generate code that would not assemble, and was easy to fix. > > But I was wondering how this made it past the gate. > Can you describe what gate commands are used regarding hsail? We simply run ?mx gate? which will include running all the HSAIL unit tests. On my Mac with the latest bits: $ mx --vm server unittest hsail executing junit tests now... (107 test classes) JUnit version 4.8 ...................................................................................I................I...... Time: 5.525 OK (105 tests) Keep in mind I (and the gate infrastructure) don?t have the HSAIL simulator. -Doug From tom.deneau at amd.com Mon Dec 16 08:48:15 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Dec 2013 16:48:15 +0000 Subject: hsail gate commands In-Reply-To: References: Message-ID: Doug -- I see. I don't understand why the tests would run without error if the simulator and associated assembler is missing but... Is there a way we can get the HSAIL simulator into the gate infrastructure? -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, December 16, 2013 10:36 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: hsail gate commands > > > On Dec 16, 2013, at 5:21 PM, Deneau, Tom wrote: > > > Doug -- > > > > I noticed in syncing with the trunk as of last Friday that all of our > HSAIL test cases broke. The cause was some imperfect code in our > HSAILAssembler for compare instructions which when presented with an > unordered compare could generate code that would not assemble, and was > easy to fix. > > > > But I was wondering how this made it past the gate. > > Can you describe what gate commands are used regarding hsail? > > We simply run 'mx gate' which will include running all the HSAIL unit > tests. > > On my Mac with the latest bits: > > $ mx --vm server unittest hsail > executing junit tests now... (107 test classes) JUnit version 4.8 > ........................................................................ > ...........I................I...... > Time: 5.525 > > OK (105 tests) > > Keep in mind I (and the gate infrastructure) don't have the HSAIL > simulator. > > -Doug From duboscq at ssw.jku.at Mon Dec 16 08:59:56 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Mon, 16 Dec 2013 17:59:56 +0100 Subject: missing bscmake.exe during debug build on Windows In-Reply-To: References: Message-ID: Hi, Which version of Visual Studio/Windows SDK are you using? It looks like a problem from the Windows SDK [1]. We should probably change the VS project files/project files generator to not need this but there are at least 2 or 3 people working on Graal with Windows here so I'm surprised they didn't run into the problem yet. [1] https://connect.microsoft.com/VisualStudio/feedback/details/641530/amd64-build-of-bscmake-exe-missing-in-windows-sdk-7-1 -Gilles On Thu, Dec 12, 2013 at 10:55 PM, Eric Caspole wrote: > Hi, > I recently noticed I can't build the debug or fastdebug version of Graal > on Windows anymore, it can't find this bscmake.exe. I think this used to > work about a month ago but I am not sure now. > The "--vmbuild product" works fine. > > I am not blocked on this, just FYI. > Regards, > Eric > > > > mx.cmd --vmbuild debug --vm server build > > TRACKER : error TRK0005: Failed to locate: "bscmake.exe". The system > cannot find the file specified. [c:\work\reduceops\graal\build\ > vs-amd64\jvm.vcxproj] > > > Done Building Project "c:\work\reduceops\graal\build\vs-amd64\jvm.vcxproj" > (default targets) -- FAILED. > > Build FAILED. > > > "c:\work\reduceops\graal\build\vs-amd64\jvm.vcxproj" (default target) (1) > -> > (BscMake target) -> > TRACKER : error TRK0005: Failed to locate: "bscmake.exe". The system > cannot find the file specified. [c:\work\reduceops\graal\build\ > vs-amd64\jvm.vcxproj] > > 14 Warning(s) > 1 Error(s) > > Time Elapsed 00:00:59.12 > RUNINDEBUGSHELL_ENDSEQUENCE > > c:\work\reduceops\graal>echo ERRXXX%errorlevel% > ERRXXX1 > Error building project > > c:\work\reduceops\graal> > > > From doug.simon at oracle.com Mon Dec 16 09:01:39 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 16 Dec 2013 18:01:39 +0100 Subject: hsail gate commands In-Reply-To: References: Message-ID: On Dec 16, 2013, at 5:48 PM, Deneau, Tom wrote: > Doug -- > > I see. > I don't understand why the tests would run without error if the simulator and associated assembler is missing but? What error are you seeing? > Is there a way we can get the HSAIL simulator into the gate infrastructure? Is it a pure Java app yet? That would certainly make it trivial. In any case, I?ll defer to Bernhard or Gilles to answer this since they are the maintainers of this infrastructure. Can you please send instructions on how to install/use/configure the simulator. -Doug >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Monday, December 16, 2013 10:36 AM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: hsail gate commands >> >> >> On Dec 16, 2013, at 5:21 PM, Deneau, Tom wrote: >> >>> Doug -- >>> >>> I noticed in syncing with the trunk as of last Friday that all of our >> HSAIL test cases broke. The cause was some imperfect code in our >> HSAILAssembler for compare instructions which when presented with an >> unordered compare could generate code that would not assemble, and was >> easy to fix. >>> >>> But I was wondering how this made it past the gate. >>> Can you describe what gate commands are used regarding hsail? >> >> We simply run 'mx gate' which will include running all the HSAIL unit >> tests. >> >> On my Mac with the latest bits: >> >> $ mx --vm server unittest hsail >> executing junit tests now... (107 test classes) JUnit version 4.8 >> ........................................................................ >> ...........I................I...... >> Time: 5.525 >> >> OK (105 tests) >> >> Keep in mind I (and the gate infrastructure) don't have the HSAIL >> simulator. >> >> -Doug > From eric.caspole at amd.com Mon Dec 16 09:07:33 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Mon, 16 Dec 2013 12:07:33 -0500 Subject: missing bscmake.exe during debug build on Windows In-Reply-To: References: Message-ID: <52AF3355.2010408@amd.com> Yes I discovered the same thing and I was able to fix it this morning by manually copying that tool from Tom to my box. Eric On 12/16/2013 11:59 AM, Gilles Duboscq wrote: > Hi, > > Which version of Visual Studio/Windows SDK are you using? > It looks like a problem from the Windows SDK [1]. > > We should probably change the VS project files/project files generator to > not need this but there are at least 2 or 3 people working on Graal with > Windows here so I'm surprised they didn't run into the problem yet. > > [1] > https://connect.microsoft.com/VisualStudio/feedback/details/641530/amd64-build-of-bscmake-exe-missing-in-windows-sdk-7-1 > > -Gilles > > > On Thu, Dec 12, 2013 at 10:55 PM, Eric Caspole wrote: > >> Hi, >> I recently noticed I can't build the debug or fastdebug version of Graal >> on Windows anymore, it can't find this bscmake.exe. I think this used to >> work about a month ago but I am not sure now. >> The "--vmbuild product" works fine. >> >> I am not blocked on this, just FYI. >> Regards, >> Eric >> >> >> >> mx.cmd --vmbuild debug --vm server build >> >> TRACKER : error TRK0005: Failed to locate: "bscmake.exe". The system >> cannot find the file specified. [c:\work\reduceops\graal\build\ >> vs-amd64\jvm.vcxproj] >> >> >> Done Building Project "c:\work\reduceops\graal\build\vs-amd64\jvm.vcxproj" >> (default targets) -- FAILED. >> >> Build FAILED. >> >> >> "c:\work\reduceops\graal\build\vs-amd64\jvm.vcxproj" (default target) (1) >> -> >> (BscMake target) -> >> TRACKER : error TRK0005: Failed to locate: "bscmake.exe". The system >> cannot find the file specified. [c:\work\reduceops\graal\build\ >> vs-amd64\jvm.vcxproj] >> >> 14 Warning(s) >> 1 Error(s) >> >> Time Elapsed 00:00:59.12 >> RUNINDEBUGSHELL_ENDSEQUENCE >> >> c:\work\reduceops\graal>echo ERRXXX%errorlevel% >> ERRXXX1 >> Error building project >> >> c:\work\reduceops\graal> >> >> >> > From bernhard.urban at jku.at Mon Dec 16 09:13:02 2013 From: bernhard.urban at jku.at (Bernhard Urban) Date: Mon, 16 Dec 2013 18:13:02 +0100 Subject: hsail gate commands In-Reply-To: References: Message-ID: <52AF349E.4060105@jku.at> On 12/16/2013 06:01 PM, Doug Simon wrote: > > On Dec 16, 2013, at 5:48 PM, Deneau, Tom wrote: > >> Doug -- >> >> I see. >> I don't understand why the tests would run without error if the simulator and associated assembler is missing but? > > What error are you seeing? > >> Is there a way we can get the HSAIL simulator into the gate infrastructure? > > Is it a pure Java app yet? That would certainly make it trivial. In any case, I?ll defer to Bernhard or Gilles to answer this since they are the maintainers of this infrastructure. Can you please send instructions on how to install/use/configure the simulator. Ideally, this should be handled by `mx gate' itself, i.e. downloading the simulator from the right place and execute it appropriately. Please keep in mind it should be a reasonable addition, meaning we probably won't accept a 10GB dependency or that the HSAIL tests take another hour in the gate :-) -Bernhard >>> -----Original Message----- >>> From: Doug Simon [mailto:doug.simon at oracle.com] >>> Sent: Monday, December 16, 2013 10:36 AM >>> To: Deneau, Tom >>> Cc: graal-dev at openjdk.java.net >>> Subject: Re: hsail gate commands >>> >>> >>> On Dec 16, 2013, at 5:21 PM, Deneau, Tom wrote: >>> >>>> Doug -- >>>> >>>> I noticed in syncing with the trunk as of last Friday that all of our >>> HSAIL test cases broke. The cause was some imperfect code in our >>> HSAILAssembler for compare instructions which when presented with an >>> unordered compare could generate code that would not assemble, and was >>> easy to fix. >>>> >>>> But I was wondering how this made it past the gate. >>>> Can you describe what gate commands are used regarding hsail? >>> >>> We simply run 'mx gate' which will include running all the HSAIL unit >>> tests. >>> >>> On my Mac with the latest bits: >>> >>> $ mx --vm server unittest hsail >>> executing junit tests now... (107 test classes) JUnit version 4.8 >>> ........................................................................ >>> ...........I................I...... >>> Time: 5.525 >>> >>> OK (105 tests) >>> >>> Keep in mind I (and the gate infrastructure) don't have the HSAIL >>> simulator. >>> >>> -Doug >> > From tom.deneau at amd.com Mon Dec 16 09:23:55 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Dec 2013 17:23:55 +0000 Subject: hsail gate commands In-Reply-To: References: Message-ID: OK, I see why there is no error when running mx --vm server unittest hsail At some point (I don't recall why, maybe at Oracle's request??), we put in some code in KernelTester that if it could not find the okra simulator files would just silently not run the tests (which I guess counts as a pass). No the hsail simulator is not a java app at all. The page at https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator should describe how to build it and what environment variables to set up to use it... -- Tom > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Monday, December 16, 2013 11:02 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: hsail gate commands > > > On Dec 16, 2013, at 5:48 PM, Deneau, Tom wrote: > > > Doug -- > > > > I see. > > I don't understand why the tests would run without error if the > > simulator and associated assembler is missing but... > > What error are you seeing? > > > Is there a way we can get the HSAIL simulator into the gate > infrastructure? > > Is it a pure Java app yet? That would certainly make it trivial. In any > case, I'll defer to Bernhard or Gilles to answer this since they are the > maintainers of this infrastructure. Can you please send instructions on > how to install/use/configure the simulator. > > -Doug > > > >> -----Original Message----- > >> From: Doug Simon [mailto:doug.simon at oracle.com] > >> Sent: Monday, December 16, 2013 10:36 AM > >> To: Deneau, Tom > >> Cc: graal-dev at openjdk.java.net > >> Subject: Re: hsail gate commands > >> > >> > >> On Dec 16, 2013, at 5:21 PM, Deneau, Tom wrote: > >> > >>> Doug -- > >>> > >>> I noticed in syncing with the trunk as of last Friday that all of > >>> our > >> HSAIL test cases broke. The cause was some imperfect code in our > >> HSAILAssembler for compare instructions which when presented with an > >> unordered compare could generate code that would not assemble, and > >> was easy to fix. > >>> > >>> But I was wondering how this made it past the gate. > >>> Can you describe what gate commands are used regarding hsail? > >> > >> We simply run 'mx gate' which will include running all the HSAIL unit > >> tests. > >> > >> On my Mac with the latest bits: > >> > >> $ mx --vm server unittest hsail > >> executing junit tests now... (107 test classes) JUnit version 4.8 > >> > ........................................................................ > >> ...........I................I...... > >> Time: 5.525 > >> > >> OK (105 tests) > >> > >> Keep in mind I (and the gate infrastructure) don't have the HSAIL > >> simulator. > >> > >> -Doug > > > From tom.deneau at amd.com Mon Dec 16 13:57:45 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 16 Dec 2013 21:57:45 +0000 Subject: graalCodeInstaller questions, recording scopes, etc. Message-ID: Wanted to run a sketch of our plans by the rest of the graal team and get some advice... When there are situations we cannot handle on the HSAIL backend, we want to deoptimize and handle them in the interpreter.? Our thoughts were that at codeInstall time, we could record the various infopoints in the compilationResult and then the graalCodeInstaller would then record these in some way in the nmethod or in some structure that we could access at runtime.? Then at runtime, if a workitem requests a deopt, it would save its HSAIL state, including all the appropriate HSAIL registers in a place that the host side could access. If the JVM code that invokes the kernel sees that one or more workitems have requested a deopt, for each one we could ?? * map the HSAIL "PC" back to the appropriate infopoint ?? * use the infopoint and the saved HSAIL registers to construct the, ???? host-based interpreter frames ?? * and then let things continue in the interpreter. Some questions: ?? * What reason should we use for the InfopointReason?? In ???? graalCodeInstaller.cpp, it seems that some types get "recorded" ???? in the debug_recorder via site_Safepoint of site_Call, while ???? others like InfopointReason::LINE_NUMBER do not.? I am assuming ???? we should "record" ours but am not sure how this all plays ???? together.? Can we map back to an infopoint that has not been ???? recorded? ?? * Our infopoints have byteCodePositions.? The ones that get ???? "recorded" go thru record_scope which has all sorts of ???? host-specific checking on the scope info.? For instance, ???? get_hotspot_value will compare a register # with ???? RegisterImpl::number_of_registers (which refers to the host) and ???? if it is, assert that the type is FLOAT or DOUBLE.? None of this ???? holds with HSAIL registers.? What is the best way to resolve ???? this? -- Tom From duboscq at ssw.jku.at Tue Dec 17 06:56:03 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 17 Dec 2013 15:56:03 +0100 Subject: graalCodeInstaller questions, recording scopes, etc. In-Reply-To: References: Message-ID: Hi, This is a lot of questions that are not simple to answers. I think we should talk about this on skype so that we can converge more quickly on a clearer picture on both sides. Doug an I have time on Thursday (2013-12-19) around 19:00 CET (10 am PST) would this work for you? Doug's skype username is dougxc, mine is gilwooden. -Gilles On Mon, Dec 16, 2013 at 10:57 PM, Tom Deneau wrote: > Wanted to run a sketch of our plans by the rest of the graal team and > get some advice... > > When there are situations we cannot handle on the HSAIL backend, we > want to deoptimize and handle them in the interpreter. Our thoughts > were that at codeInstall time, we could record the various infopoints > in the compilationResult and then the graalCodeInstaller would then > record these in some way in the nmethod or in some structure that we > could access at runtime. Then at runtime, if a workitem requests a > deopt, it would save its HSAIL state, including all the appropriate > HSAIL registers in a place that the host side could access. > > If the JVM code that invokes the kernel sees that one or more > workitems have requested a deopt, for each one we could > > * map the HSAIL "PC" back to the appropriate infopoint > > * use the infopoint and the saved HSAIL registers to construct the, > host-based interpreter frames > > * and then let things continue in the interpreter. > > Some questions: > > * What reason should we use for the InfopointReason? In > graalCodeInstaller.cpp, it seems that some types get "recorded" > in the debug_recorder via site_Safepoint of site_Call, while > others like InfopointReason::LINE_NUMBER do not. I am assuming > we should "record" ours but am not sure how this all plays > together. Can we map back to an infopoint that has not been > recorded? > > * Our infopoints have byteCodePositions. The ones that get > "recorded" go thru record_scope which has all sorts of > host-specific checking on the scope info. For instance, > get_hotspot_value will compare a register # with > RegisterImpl::number_of_registers (which refers to the host) and > if it is, assert that the type is FLOAT or DOUBLE. None of this > holds with HSAIL registers. What is the best way to resolve > this? > > -- Tom > > > From tom.deneau at amd.com Tue Dec 17 07:00:12 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 17 Dec 2013 15:00:12 +0000 Subject: graalCodeInstaller questions, recording scopes, etc. In-Reply-To: References: Message-ID: That time should be good. -- Tom From: gilwooden at gmail.com [mailto:gilwooden at gmail.com] On Behalf Of Gilles Duboscq Sent: Tuesday, December 17, 2013 8:56 AM To: Deneau, Tom Cc: graal-dev at openjdk.java.net; Douglas Simon Subject: Re: graalCodeInstaller questions, recording scopes, etc. Hi, This is a lot of questions that are not simple to answers. I think we should talk about this on skype so that we can converge more quickly on a clearer picture on both sides. Doug an I have time on Thursday (2013-12-19) around 19:00 CET (10 am PST) would this work for you? Doug's skype username is dougxc, mine is gilwooden. -Gilles On Mon, Dec 16, 2013 at 10:57 PM, Tom Deneau > wrote: Wanted to run a sketch of our plans by the rest of the graal team and get some advice... When there are situations we cannot handle on the HSAIL backend, we want to deoptimize and handle them in the interpreter. Our thoughts were that at codeInstall time, we could record the various infopoints in the compilationResult and then the graalCodeInstaller would then record these in some way in the nmethod or in some structure that we could access at runtime. Then at runtime, if a workitem requests a deopt, it would save its HSAIL state, including all the appropriate HSAIL registers in a place that the host side could access. If the JVM code that invokes the kernel sees that one or more workitems have requested a deopt, for each one we could * map the HSAIL "PC" back to the appropriate infopoint * use the infopoint and the saved HSAIL registers to construct the, host-based interpreter frames * and then let things continue in the interpreter. Some questions: * What reason should we use for the InfopointReason? In graalCodeInstaller.cpp, it seems that some types get "recorded" in the debug_recorder via site_Safepoint of site_Call, while others like InfopointReason::LINE_NUMBER do not. I am assuming we should "record" ours but am not sure how this all plays together. Can we map back to an infopoint that has not been recorded? * Our infopoints have byteCodePositions. The ones that get "recorded" go thru record_scope which has all sorts of host-specific checking on the scope info. For instance, get_hotspot_value will compare a register # with RegisterImpl::number_of_registers (which refers to the host) and if it is, assert that the type is FLOAT or DOUBLE. None of this holds with HSAIL registers. What is the best way to resolve this? -- Tom From bharadwaj.yadavalli at oracle.com Tue Dec 17 07:10:38 2013 From: bharadwaj.yadavalli at oracle.com (S. Bharadwaj Yadavalli) Date: Tue, 17 Dec 2013 10:10:38 -0500 Subject: graalCodeInstaller questions, recording scopes, etc. In-Reply-To: References: Message-ID: <52B0696E.1090409@oracle.com> Hi, As I am currently implementing PTX code generation and execution using Graal, I am also interested in participating in the call. Please keep me posted as well. Regards, Bharadwaj On 12/17/2013 09:56 AM, Gilles Duboscq wrote: > Hi, > > This is a lot of questions that are not simple to answers. > I think we should talk about this on skype so that we can converge more > quickly on a clearer picture on both sides. > Doug an I have time on Thursday (2013-12-19) around 19:00 CET (10 am PST) > would this work for you? > Doug's skype username is dougxc, mine is gilwooden. > > -Gilles > > > On Mon, Dec 16, 2013 at 10:57 PM, Tom Deneau wrote: > >> Wanted to run a sketch of our plans by the rest of the graal team and >> get some advice... >> >> When there are situations we cannot handle on the HSAIL backend, we >> want to deoptimize and handle them in the interpreter. Our thoughts >> were that at codeInstall time, we could record the various infopoints >> in the compilationResult and then the graalCodeInstaller would then >> record these in some way in the nmethod or in some structure that we >> could access at runtime. Then at runtime, if a workitem requests a >> deopt, it would save its HSAIL state, including all the appropriate >> HSAIL registers in a place that the host side could access. >> >> If the JVM code that invokes the kernel sees that one or more >> workitems have requested a deopt, for each one we could >> >> * map the HSAIL "PC" back to the appropriate infopoint >> >> * use the infopoint and the saved HSAIL registers to construct the, >> host-based interpreter frames >> >> * and then let things continue in the interpreter. >> >> Some questions: >> >> * What reason should we use for the InfopointReason? In >> graalCodeInstaller.cpp, it seems that some types get "recorded" >> in the debug_recorder via site_Safepoint of site_Call, while >> others like InfopointReason::LINE_NUMBER do not. I am assuming >> we should "record" ours but am not sure how this all plays >> together. Can we map back to an infopoint that has not been >> recorded? >> >> * Our infopoints have byteCodePositions. The ones that get >> "recorded" go thru record_scope which has all sorts of >> host-specific checking on the scope info. For instance, >> get_hotspot_value will compare a register # with >> RegisterImpl::number_of_registers (which refers to the host) and >> if it is, assert that the type is FLOAT or DOUBLE. None of this >> holds with HSAIL registers. What is the best way to resolve >> this? >> >> -- Tom >> >> >> From falbert9 at vt.edu Tue Dec 17 08:24:57 2013 From: falbert9 at vt.edu (Curt Albert) Date: Tue, 17 Dec 2013 11:24:57 -0500 Subject: MethodSubstitution non-static methods Message-ID: Is it possible to preform a method substitution on a non static method? When I try and use @MethodSubstitution followed by a non static method I get the error " Context obj com.oracle.graal.graph.GraalInternalError: Substitution methods must be static:" I was looking at AESCryptSubstitutions.java and for encryptBlock and decryptBlock those methods are not static in com.sun.crypto.provider.AESCrypt and they have (isStatic = false) after the @MethodSubstitution then static and the method with an additional Object in the parameters. A similar thing is true for the ObjectSubstitutions.java for several methods the @MethodSubstitution is followed by (isStatic = false) and have an extra object in the parameters and some have forced = true, but when I try adding (isStatic = false) and static in front of my MethodSubstitution and an object in the parameters graal never substitutes the method. How do you substitute a non-static method in graal and what does forced = true mean? //In VectorSubstitutions,java and tested that substitutions are registered and does substitute for static test methods @MethodSubstitution(isStatic = false, forced = true) static void vecExecution(Object thisObj, int vec) { System.out.println("vect"); } //The method I am trying to substitute public void vecExecution(int vec) { for(int i = 0; i < vec; i++) { run(); //increment group id kernelState.setGroupId(0,(kernelState.getGroupIds()[0] + 1)); //increment global id kernelState.setGlobalId(0,(kernelState.getGlobalIds()[0] + 1)); } } Thanks, Curt Albert From duboscq at ssw.jku.at Tue Dec 17 08:39:33 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Tue, 17 Dec 2013 17:39:33 +0100 Subject: MethodSubstitution non-static methods In-Reply-To: References: Message-ID: About "forced" you can look at the Javadoc on MethodSubstitution#forced: * Determines if this method should be substituted in all cases, even if inlining thinks it isnot important. Are you sure the call site where you expect the substitution to happen can be de-virtualized? Are you sure your substitution is registered? For an example about how this is achieved for other substitutions, have a look at com.oracle.graal.replacements.GraalMethodSubstitutions. You need to implement the com.oracle.graal.nodes.spi.ReplacementsProvider interface and have the @ServiceProvider(ReplacementsProvider.class) annotation. The magic behind the @ServiceProvider annotation can be a bit brittle when building using eclipse. To be sure, you can do a mx clean and mx build. -Gilles On Tue, Dec 17, 2013 at 5:24 PM, Curt Albert wrote: > Is it possible to preform a method substitution on a non static method? > When I try and use @MethodSubstitution followed by a non static method I > get the error " Context obj com.oracle.graal.graph.GraalInternalError: > Substitution methods must be static:" I was looking at > AESCryptSubstitutions.java and for encryptBlock and decryptBlock those > methods are not static in com.sun.crypto.provider.AESCrypt and they have > (isStatic = false) after the @MethodSubstitution then static and the method > with an additional Object in the parameters. A similar thing is true for > the ObjectSubstitutions.java for several methods the @MethodSubstitution is > followed by (isStatic = false) and have an extra object in the parameters > and some have forced = true, but when I try adding (isStatic = false) and > static in front of my MethodSubstitution and an object in the parameters > graal never substitutes the method. > > How do you substitute a non-static method in graal and what does forced = > true mean? > > > //In VectorSubstitutions,java and tested that substitutions are registered > and does substitute for static test methods > @MethodSubstitution(isStatic = false, forced = true) > static void vecExecution(Object thisObj, int vec) { > System.out.println("vect"); > } > > //The method I am trying to substitute > public void vecExecution(int vec) > { > for(int i = 0; i < vec; i++) > { > run(); > //increment group id > kernelState.setGroupId(0,(kernelState.getGroupIds()[0] + 1)); > //increment global id > kernelState.setGlobalId(0,(kernelState.getGlobalIds()[0] + 1)); > } > } > > > > Thanks, > Curt Albert > From java at stefan-marr.de Wed Dec 18 05:45:00 2013 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 18 Dec 2013 14:45:00 +0100 Subject: Truffle: ImplicitCast and Type Specializations for TruffleSOM Message-ID: <0E1CF784-36A0-49A3-AB18-5F9BB444243E@stefan-marr.de> Hi: In the attempt of avoiding boxing throughout TruffleSOM, I tried to push the type-based specialization a little further for ints, BigIntegers, doubles, and Strings. Since implementing all possible combinations for all the type combinations of the primitive operations seems to be infeasible, I used @ImplicitCasts as in this example: @ImplicitCast public int castInteger(final SInteger i) { return i.getEmbeddedInteger(); } I restricted myself to introduce only conversion from boxed SOM types to Java types, because I thought that might be simpler to handle and avoids undesired conversions. Thus, the casts basically just unbox the SOM objects. As a result, the primitives are rather nice now. See an example at the end. I really just need to implement specializations for the basic types, and SOM specific type promotions. While I had the feeling that the overall code got nice, the result of this change is rather unexpected. With the current code on the type-specialization branch (https://github.com/SOM-st/TruffleSOM/commits/type-specialization), I see a slowdown of 5x for the interpreted version. And the Graal-compiled version doesn?t actually run properly. It causes constant method invalidations. I tried to use the following flags to make sense of it: -XX:+TraceDeoptimization -G:-TruffleBackgroundCompilation -G:+TraceTruffleCompilationDetails However, I see only output that tells me about traps in OptimizedCallTarget::executeHelper, which doesn?t give me a lot of hints that I understand. Any ideas what that could be the cause for such invalidations? Thanks Stefan ## MultiplicationPrim public abstract class MultiplicationPrim extends ArithmeticPrim { public MultiplicationPrim(final SSymbol selector, final Universe universe) { super(selector, universe); } public MultiplicationPrim(final MultiplicationPrim node) { this(node.selector, node.universe); } @Specialization(order = 1, rewriteOn = ArithmeticException.class) public int doInteger(final int left, final int right) { return ExactMath.multiplyExact(left, right); } @Specialization(order = 2) public Object doBigInteger(final BigInteger left, final BigInteger right) { BigInteger result = left.multiply(right); return reduceToIntIfPossible(result); } @Specialization(order = 3) public double doDouble(final double left, final double right) { return left * right; } @Specialization(order = 10) public Object doInteger(final int left, final BigInteger right) { return doBigInteger(BigInteger.valueOf(left), right); } @Specialization(order = 11) public double doInteger(final int left, final double right) { return doDouble(left, right); } @Specialization(order = 12) public Object doBigInteger(final BigInteger left, final int right) { return doBigInteger(left, BigInteger.valueOf(right)); } @Specialization(order = 13) public double doDouble(final double left, final int right) { return doDouble(left, (double) right); } } ## Some Graal output ./mx.sh --vm server vm -XX:+TraceDeoptimization -G:-TruffleBackgroundCompilation -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/BenchmarkHarness.som IntegerLoop 1 2 2000 Uncommon trap bci=16 pc=153299396, relative_pc=1540, method=doInteger, speculation=0 Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod) (@0x00000001092329c4) thread=6403 reason=null_assert|unreached0 action=reinterpret unloaded_class_index=-1 speculation=0 Uncommon trap bci=0 pc=137952117, relative_pc=1397, method=executeHelper, speculation=0 Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod) (@0x000000010838fb75) thread=6403 reason=null_assert|unreached0 action=none unloaded_class_index=-1 speculation=0 Uncommon trap bci=61 pc=153208469, relative_pc=181, method=initializeFrame, speculation=0 Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod) (@0x000000010921c695) thread=6403 reason=null_assert|unreached0 action=make_not_entrant unloaded_class_index=-1 speculation=0 [truffle] invalidated Method Integer>>#$block method:../som/Smalltalk//Integer.som:65 at 20e2cbe0 |Inv# 349 |Replace# 15 Uncommon trap bci=0 pc=137952117, relative_pc=1397, method=executeHelper, speculation=0 Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod) (@0x000000010838fb75) thread=6403 reason=null_assert|unreached0 action=none unloaded_class_index=-1 speculation=0 [truffle] invalidated Method IntegerLoop>>#$block method::../som/Examples/Benchmarks//IntegerLoop.som:30 at 10dba097 |Inv# 399 |Replace# 9 Uncommon trap bci=0 pc=137952117, relative_pc=1397, method=executeHelper, speculation=0 Uncommon trap occurred in com.oracle.graal.truffle.OptimizedCallTarget::executeHelper (Graal: installedCodeName=HotSpotMethod) (@0x000000010838fb75) thread=6403 reason=null_assert|unreached0 action=none unloaded_class_index=-1 speculation=0 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From eric.caspole at amd.com Wed Dec 18 06:56:46 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Wed, 18 Dec 2013 09:56:46 -0500 Subject: Webrev for throwing some exceptions from HSAIL In-Reply-To: <5B02E26C-8CC1-4F57-919B-073295734001@oracle.com> References: <356A263B-C27F-4E27-AE5E-0BA5DB266C17@oracle.com> <5B02E26C-8CC1-4F57-919B-073295734001@oracle.com> Message-ID: <52B1B7AE.4030806@amd.com> As Chris mentioned, let's try to come up with a workitem model that relates to the deoptimizations, etc. GPU devices process elements in wavefronts or warps which are often size 32 or 64 workitems at once. Devices can usually execute several wavefronts simultaneously. All the workitems in each wavefront are processed in lock-step unless there is divergence, in which case each side of a branch will be predicated off in turn until the branches reunite. So at any given time, there can be some wavefronts that already definitely completed, some that have not started yet, and some that are in flight. Since the total job size being offloaded could be enormous, I think we should keep track of the workitems/wavefronts currently in flight at any given moment if we need to deoptimize or safepoint etc. This will normally be hundreds or thousands of workitems at once for current hardware. We know the current workitem id in the job for any given GPU core, and we know how many total GPU cores are on a device, so with that we can work out what is the state of partially completed work if there is a deopt etc. We can prevent future wavefronts from starting by explicit checks, and workitems that already completed, at least in the case of HSA for the use cases we have working, their results are already stored back in the heap so that should not require any more attention. I am starting to experiment with this on our hardware. Will this idea work on PTX? It seems like it will work for HSA. Let me know your ideas. Thanks, Eric On 12/10/2013 02:27 PM, Christian Thalinger wrote: > > On Dec 10, 2013, at 9:31 AM, Gilles Duboscq wrote: > >> On Tue, Dec 10, 2013 at 5:41 PM, Tom Deneau wrote: >> >>> Gilles -- >>> >>> Some comments below >>> >>> -- Tom >>> >>>> -----Original Message----- >>>> From: graal-dev-bounces at openjdk.java.net [mailto:graal-dev- >>>> bounces at openjdk.java.net] On Behalf Of Gilles Duboscq >>>> Sent: Tuesday, December 10, 2013 9:05 AM >>>> To: Doug Simon >>>> Cc: Caspole, Eric; graal-dev at openjdk.java.net >>>> Subject: Re: Webrev for throwing some exceptions from HSAIL >>>> >>>> Hi Eric, >>>> >>>> The deoptimization mechanism and the exception mechanism are two >>>> completely different things. >>>> When a deoptimization happens, your only choice is to restart execution >>> in the interpreter. >>>> >>>> To do so, the deoptimization points are decorated with LIRFrameState in >>> the >>>> backend. This LIRFrameState gives you information that allow to rebuild >>> the >>>> interpreter frames. For each frame you have a method, a bci, the stack >>> and >>>> local values and the owned monitors. >>>> >>> >>> Yes, this was indeed a baby step. >>> >>> We realized with graal's policy of providing the framestate back at the >>> last >>> side-effecting bytecode means we don't get even get the exact bci on >>> deoptimizations. >>> >>> Our plan for the next phase is to provide enough information and >>> actually build up the correct interpreter frames back and restart >>> execution in the interpreter back on the host side. >>> >> >> OK, but i wonder what are the semantics there since the data has already >> been partially modified by the other kernel workitems which didn't >> deoptimize. >> In general when we think about parallelization we consider that it's only >> safe to parallelize sections where there is no deoptimization since this >> means we are guaranteed not to deopt to a state of the data that is invalid >> for the interpreter. >> I suppose in the case of streams you are relying on the relaxed semantics >> of parallel streams. >> How are you going to ensure that all element are processed in the case of >> deoptimization? > > Correct. This is something we have talked about already in the Sumatra scope. Before we can throw exceptions in GPUs we have to have some kind of work item logic. I think trying to throw exceptions without having properly set up work items and a way to undo or record which items have already been processed is premature and not something we want. > > We need to resume talking about work items and start to implement it. > >> >> From christian.humer at gmail.com Wed Dec 18 07:03:08 2013 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 18 Dec 2013 16:03:08 +0100 Subject: Regression for TraceTruffleCompilationDetails? In-Reply-To: References: Message-ID: Hi Stefan, I gave it another try even so you did not provide me with a more robust form for the command line. After I've hardcoded the Universe#fileSeparator to a "/" I managed to at least run something [1] . After I've fixed the class path provided in your -cp which is not where it should be if you do a clean checkout from git I came up with this command line: mx --vm server vm -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../TruffleSOM/build/classes;../TruffleSOM/libs/com.oracle.truffle.api.jar;../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../TruffleSOM/core-lib/Smalltalk ../TruffleSOM/core-lib/Examples/Benchmarks/BenchmarkHarness.som IntegerLoop 1 2 2000 However I got this output on the console: Warning: Primitive bitXor: is not in class definition for class Double Exception in thread "main" java.lang.RuntimeException: This should not happen in TruffleSOM at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.createCachedNode(BinarySendNode.java:162) at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.specialize(BinarySendNode.java:141) at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) at som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) at som.interpreter.Method.messageSendExecution(Method.java:89) at som.interpreter.Method.execute(Method.java:77) at com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) at com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) at com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) at com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) at som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233) at som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86) at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) at som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) at som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60) at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) at som.interpreter.Method.messageSendExecution(Method.java:89) at som.interpreter.Method.execute(Method.java:77) at com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) at com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) at com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) at com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) at som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233) at som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86) at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) at som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) at som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60) at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) at som.interpreter.Method.messageSendExecution(Method.java:89) at som.interpreter.Method.execute(Method.java:77) at com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) at com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) at com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) at com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) at com.oracle.truffle.api.CallTarget.call(CallTarget.java:62) at som.vmobjects.SMethod.invokeRoot(SMethod.java:86) at som.vm.Universe.execute(Universe.java:302) at som.vm.Universe.interpret(Universe.java:77) at som.vm.Universe.main(Universe.java:63) Whats this? I stopped investigating at this point. [1] Why didnt you just use the java.io.File API in the jdk to parse your pathes? Cheers, - Christian Humer On Mon, Dec 16, 2013 at 2:57 PM, Stefan Marr wrote: > Hi Christian: > > Since I don?t know exactly whether there is anything Windows related going > wrong, perhaps a few additional notes on my setup. > I think, the standard problems should be that either the paths in the > command line are not correct, or the git repo wasn?t checked out with its > submodules: > > To clone the git repo of TruffleSOM with its submodules: > git clone --recursive https://github.com/smarr/TruffleSOM.git > > In contrast to other Truffle languages, TruffleSOM wasn?t yet adapted to > the mx compilation infrastructure, but uses a simple ant script. > > Executing `ant tests` should compile the necessary files and execute a > simple test. > Note, it will download the necessary precompiled Truffle jars. I guess, > that should work on Windows. > > Afterwards, it will depend on where your Graal folder is located. > > The command line assumes that it is in a folder next to TruffleSOM, so in > the command line, `../TruffleSOM` would need to be replaced for other > locations accordingly. Perhaps the path separators need to be changed for > windows as well. > > > ./mx.sh --vm server vm -G:+TraceTruffleCompilationDetails > -Xbootclasspath/a:../TruffleSOM/build/classes:../TruffleSOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar > som.vm.Universe -cp ../TruffleSOM/Smalltalk > ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 > > > After the mx.sh arguments, the bootclass path is set to include the > Truffle libraries, as well as the compiled TruffleSOM classes (from the > build/classes folder). > The main class of TruffleSOM is som.vm.Universe, `-cp` gives a class path > to SOM to enabled to find its Smalltalk class library, and the main script > to be executed is ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som > with a name for the benchmark and infos on how many iterations, and warmup > cycles should be executed. > > Thanks for looking into the issue. I worked around it by just catching the > exception for the moment. > > Best regards > Stefan > > On 16 Dec 2013, at 11:51, Christian Humer > wrote: > > > Hi Stefan, > > > > Could you please provide a little more robust command line for the > problem? > > I just completely failed to run it on windows. > > > > > > - Christian Humer > > > > > > On Mon, Dec 16, 2013 at 11:13 AM, Stefan Marr > wrote: > > Hi: > > > > I am running here into a class cast exception when using > -G:+TraceTruffleCompilationDetails: > > > > java.lang.ClassCastException: > com.oracle.graal.truffle.nodes.frame.NewFrameNode cannot be cast to > com.oracle.graal.nodes.ConstantNode > > at > com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:193) > > > > The corresponding line is: > > ConstantNode constantNode = (ConstantNode) > methodCallTargetNode.arguments().first(); > > > > However, the first argument is not a ConstantNode but a NewFrameNode > (the new frame node looks like one of mine, i.e., for a TruffleSOM method > call). > > > > The targetMethod of is > `HotSpotMethod`. > > > > The problem can be triggered for instance with the following TruffleSOM > benchmark: > > > > ./mx.sh -d --vm server vm -G:+TraceTruffleCompilationDetails > -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar > som.vm.Universe -cp ../som/Smalltalk > ../som/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 > > > > I suppose the receiver is here expected to be constant to print out > tracing information, but it isn?t in my case. > > > > Is there perhaps some simple work-around possible? > > > > Thanks > > Stefan > > > > To check out TruffleSOM: > > > > git clone --recursive https://github.com/smarr/TruffleSOM.git > > cd TruffleSOM > > ant jar > > cd $GRAAL > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From java at stefan-marr.de Wed Dec 18 07:22:37 2013 From: java at stefan-marr.de (Stefan Marr) Date: Wed, 18 Dec 2013 16:22:37 +0100 Subject: Regression for TraceTruffleCompilationDetails? In-Reply-To: References: Message-ID: <00B651A1-1178-4171-BBA5-CD30FC916927@stefan-marr.de> Hi Christian: Sorry, yes, TruffleSOM is not tested on Windows, and there are certainly hidden problems. Since I don?t have access to a windows box, I unfortunately can?t provide you with something more robust, sorry. You are running here into problems because the TruffleSOM git repo uses symlinks and core-lib is the git submodule to which the symlinks should be pointing. And symlinks aren?t supported on NTFS? The problem you are seeing with the missing bitXor: primitive is probably caused by a mismatch between the core-lib version on the TruffleSOM version. Please note the `--recursive` in the git command line: `git clone --recursive https://github.com/smarr/TruffleSOM.git` The proper version should normally be loaded with the following commands after a non-recursive clone: git submodule init git submodule update With regard to [1]: The simple answer is, because I didn?t write that code. I?ll fix it. Either way, thanks for looking into it. Not sure whether it is an important issue, but I worked around it by just swallowing the exception. Best regards Stefan On 18 Dec 2013, at 16:03, Christian Humer wrote: > Hi Stefan, > > I gave it another try even so you did not provide me with a more robust form for the command line. After I've hardcoded the Universe#fileSeparator to a "/" I managed to at least run something [1] . After I've fixed the class path provided in your -cp which is not where it should be if you do a clean checkout from git I came up with this command line: > > mx --vm server vm -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../TruffleSOM/build/classes;../TruffleSOM/libs/com.oracle.truffle.api.jar;../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../TruffleSOM/core-lib/Smalltalk ../TruffleSOM/core-lib/Examples/Benchmarks/BenchmarkHarness.som IntegerLoop 1 2 2000 > > However I got this output on the console: > Warning: Primitive bitXor: is not in class definition for class Double > Exception in thread "main" java.lang.RuntimeException: This should not happen in TruffleSOM > at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.createCachedNode(BinarySendNode.java:162) > at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.specialize(BinarySendNode.java:141) > at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) > at som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) > at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) > at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) > at som.interpreter.Method.messageSendExecution(Method.java:89) > at som.interpreter.Method.execute(Method.java:77) > at com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) > at com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) > at com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) > at com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) > at som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233) > at som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86) > at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) > at som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) > at som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60) > at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) > at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) > at som.interpreter.Method.messageSendExecution(Method.java:89) > at som.interpreter.Method.execute(Method.java:77) > at com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) > at com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) > at com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) > at com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) > at som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233) > at som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86) > at som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) > at som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) > at som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60) > at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) > at som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) > at som.interpreter.Method.messageSendExecution(Method.java:89) > at som.interpreter.Method.execute(Method.java:77) > at com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) > at com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) > at com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) > at com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) > at com.oracle.truffle.api.CallTarget.call(CallTarget.java:62) > at som.vmobjects.SMethod.invokeRoot(SMethod.java:86) > at som.vm.Universe.execute(Universe.java:302) > at som.vm.Universe.interpret(Universe.java:77) > at som.vm.Universe.main(Universe.java:63) > > Whats this? I stopped investigating at this point. > > [1] Why didnt you just use the java.io.File API in the jdk to parse your pathes? > > > Cheers, > > - Christian Humer > > > On Mon, Dec 16, 2013 at 2:57 PM, Stefan Marr wrote: > Hi Christian: > > Since I don?t know exactly whether there is anything Windows related going wrong, perhaps a few additional notes on my setup. > I think, the standard problems should be that either the paths in the command line are not correct, or the git repo wasn?t checked out with its submodules: > > To clone the git repo of TruffleSOM with its submodules: > git clone --recursive https://github.com/smarr/TruffleSOM.git > > In contrast to other Truffle languages, TruffleSOM wasn?t yet adapted to the mx compilation infrastructure, but uses a simple ant script. > > Executing `ant tests` should compile the necessary files and execute a simple test. > Note, it will download the necessary precompiled Truffle jars. I guess, that should work on Windows. > > Afterwards, it will depend on where your Graal folder is located. > > The command line assumes that it is in a folder next to TruffleSOM, so in the command line, `../TruffleSOM` would need to be replaced for other locations accordingly. Perhaps the path separators need to be changed for windows as well. > > > ./mx.sh --vm server vm -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../TruffleSOM/build/classes:../TruffleSOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../TruffleSOM/Smalltalk ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 > > > After the mx.sh arguments, the bootclass path is set to include the Truffle libraries, as well as the compiled TruffleSOM classes (from the build/classes folder). > The main class of TruffleSOM is som.vm.Universe, `-cp` gives a class path to SOM to enabled to find its Smalltalk class library, and the main script to be executed is ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som with a name for the benchmark and infos on how many iterations, and warmup cycles should be executed. > > Thanks for looking into the issue. I worked around it by just catching the exception for the moment. > > Best regards > Stefan > > On 16 Dec 2013, at 11:51, Christian Humer wrote: > > > Hi Stefan, > > > > Could you please provide a little more robust command line for the problem? > > I just completely failed to run it on windows. > > > > > > - Christian Humer > > > > > > On Mon, Dec 16, 2013 at 11:13 AM, Stefan Marr wrote: > > Hi: > > > > I am running here into a class cast exception when using -G:+TraceTruffleCompilationDetails: > > > > java.lang.ClassCastException: com.oracle.graal.truffle.nodes.frame.NewFrameNode cannot be cast to com.oracle.graal.nodes.ConstantNode > > at com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:193) > > > > The corresponding line is: > > ConstantNode constantNode = (ConstantNode) methodCallTargetNode.arguments().first(); > > > > However, the first argument is not a ConstantNode but a NewFrameNode (the new frame node looks like one of mine, i.e., for a TruffleSOM method call). > > > > The targetMethod of is `HotSpotMethod`. > > > > The problem can be triggered for instance with the following TruffleSOM benchmark: > > > > ./mx.sh -d --vm server vm -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../som/Smalltalk ../som/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 > > > > I suppose the receiver is here expected to be constant to print out tracing information, but it isn?t in my case. > > > > Is there perhaps some simple work-around possible? > > > > Thanks > > Stefan > > > > To check out TruffleSOM: > > > > git clone --recursive https://github.com/smarr/TruffleSOM.git > > cd TruffleSOM > > ant jar > > cd $GRAAL > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From christian.humer at gmail.com Wed Dec 18 07:45:21 2013 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 18 Dec 2013 16:45:21 +0100 Subject: Regression for TraceTruffleCompilationDetails? In-Reply-To: <00B651A1-1178-4171-BBA5-CD30FC916927@stefan-marr.de> References: <00B651A1-1178-4171-BBA5-CD30FC916927@stefan-marr.de> Message-ID: Hi Stefan, That --recursive seemed to have fixed my problem. Thx! Will have a look. - Christian Humer On Wed, Dec 18, 2013 at 4:22 PM, Stefan Marr wrote: > Hi Christian: > > Sorry, yes, TruffleSOM is not tested on Windows, and there are certainly > hidden problems. > Since I don?t have access to a windows box, I unfortunately can?t provide > you with something more robust, sorry. > > You are running here into problems because the TruffleSOM git repo uses > symlinks and core-lib is the git submodule to which the symlinks should be > pointing. And symlinks aren?t supported on NTFS? > > The problem you are seeing with the missing bitXor: primitive is probably > caused by a mismatch between the core-lib version on the TruffleSOM version. > > Please note the `--recursive` in the git command line: `git clone > --recursive https://github.com/smarr/TruffleSOM.git` > The proper version should normally be loaded with the following commands > after a non-recursive clone: > git submodule init > git submodule update > > With regard to [1]: The simple answer is, because I didn?t write that > code. I?ll fix it. > > Either way, thanks for looking into it. Not sure whether it is an > important issue, but I worked around it by just swallowing the exception. > > Best regards > Stefan > > On 18 Dec 2013, at 16:03, Christian Humer > wrote: > > > Hi Stefan, > > > > I gave it another try even so you did not provide me with a more robust > form for the command line. After I've hardcoded the Universe#fileSeparator > to a "/" I managed to at least run something [1] . After I've fixed the > class path provided in your -cp which is not where it should be if you do a > clean checkout from git I came up with this command line: > > > > mx --vm server vm -G:+TraceTruffleCompilationDetails > -Xbootclasspath/a:../TruffleSOM/build/classes;../TruffleSOM/libs/com.oracle.truffle.api.jar;../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar > som.vm.Universe -cp ../TruffleSOM/core-lib/Smalltalk > ../TruffleSOM/core-lib/Examples/Benchmarks/BenchmarkHarness.som IntegerLoop > 1 2 2000 > > > > However I got this output on the console: > > Warning: Primitive bitXor: is not in class definition for class Double > > Exception in thread "main" java.lang.RuntimeException: This should not > happen in TruffleSOM > > at > som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.createCachedNode(BinarySendNode.java:162) > > at > som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.specialize(BinarySendNode.java:141) > > at > som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) > > at > som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) > > at > som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) > > at > som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) > > at som.interpreter.Method.messageSendExecution(Method.java:89) > > at som.interpreter.Method.execute(Method.java:77) > > at > com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) > > at > com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) > > at > com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) > > at > com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) > > at > som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233) > > at > som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86) > > at > som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) > > at > som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) > > at > som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60) > > at > som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) > > at > som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) > > at som.interpreter.Method.messageSendExecution(Method.java:89) > > at som.interpreter.Method.execute(Method.java:77) > > at > com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) > > at > com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) > > at > com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) > > at > com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) > > at > som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233) > > at > som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86) > > at > som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) > > at > som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) > > at > som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60) > > at > som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) > > at > som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) > > at som.interpreter.Method.messageSendExecution(Method.java:89) > > at som.interpreter.Method.execute(Method.java:77) > > at > com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) > > at > com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) > > at > com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) > > at > com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) > > at com.oracle.truffle.api.CallTarget.call(CallTarget.java:62) > > at som.vmobjects.SMethod.invokeRoot(SMethod.java:86) > > at som.vm.Universe.execute(Universe.java:302) > > at som.vm.Universe.interpret(Universe.java:77) > > at som.vm.Universe.main(Universe.java:63) > > > > Whats this? I stopped investigating at this point. > > > > [1] Why didnt you just use the java.io.File API in the jdk to parse your > pathes? > > > > > > Cheers, > > > > - Christian Humer > > > > > > On Mon, Dec 16, 2013 at 2:57 PM, Stefan Marr > wrote: > > Hi Christian: > > > > Since I don?t know exactly whether there is anything Windows related > going wrong, perhaps a few additional notes on my setup. > > I think, the standard problems should be that either the paths in the > command line are not correct, or the git repo wasn?t checked out with its > submodules: > > > > To clone the git repo of TruffleSOM with its submodules: > > git clone --recursive https://github.com/smarr/TruffleSOM.git > > > > In contrast to other Truffle languages, TruffleSOM wasn?t yet adapted to > the mx compilation infrastructure, but uses a simple ant script. > > > > Executing `ant tests` should compile the necessary files and execute a > simple test. > > Note, it will download the necessary precompiled Truffle jars. I guess, > that should work on Windows. > > > > Afterwards, it will depend on where your Graal folder is located. > > > > The command line assumes that it is in a folder next to TruffleSOM, so > in the command line, `../TruffleSOM` would need to be replaced for other > locations accordingly. Perhaps the path separators need to be changed for > windows as well. > > > > > ./mx.sh --vm server vm -G:+TraceTruffleCompilationDetails > -Xbootclasspath/a:../TruffleSOM/build/classes:../TruffleSOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar > som.vm.Universe -cp ../TruffleSOM/Smalltalk > ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 > > > > > > After the mx.sh arguments, the bootclass path is set to include the > Truffle libraries, as well as the compiled TruffleSOM classes (from the > build/classes folder). > > The main class of TruffleSOM is som.vm.Universe, `-cp` gives a class > path to SOM to enabled to find its Smalltalk class library, and the main > script to be executed is > ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som with a name for the > benchmark and infos on how many iterations, and warmup cycles should be > executed. > > > > Thanks for looking into the issue. I worked around it by just catching > the exception for the moment. > > > > Best regards > > Stefan > > > > On 16 Dec 2013, at 11:51, Christian Humer > wrote: > > > > > Hi Stefan, > > > > > > Could you please provide a little more robust command line for the > problem? > > > I just completely failed to run it on windows. > > > > > > > > > - Christian Humer > > > > > > > > > On Mon, Dec 16, 2013 at 11:13 AM, Stefan Marr > wrote: > > > Hi: > > > > > > I am running here into a class cast exception when using > -G:+TraceTruffleCompilationDetails: > > > > > > java.lang.ClassCastException: > com.oracle.graal.truffle.nodes.frame.NewFrameNode cannot be cast to > com.oracle.graal.nodes.ConstantNode > > > at > com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:193) > > > > > > The corresponding line is: > > > ConstantNode constantNode = (ConstantNode) > methodCallTargetNode.arguments().first(); > > > > > > However, the first argument is not a ConstantNode but a NewFrameNode > (the new frame node looks like one of mine, i.e., for a TruffleSOM method > call). > > > > > > The targetMethod of is > `HotSpotMethod`. > > > > > > The problem can be triggered for instance with the following > TruffleSOM benchmark: > > > > > > ./mx.sh -d --vm server vm -G:+TraceTruffleCompilationDetails > -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar > som.vm.Universe -cp ../som/Smalltalk > ../som/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 > > > > > > I suppose the receiver is here expected to be constant to print out > tracing information, but it isn?t in my case. > > > > > > Is there perhaps some simple work-around possible? > > > > > > Thanks > > > Stefan > > > > > > To check out TruffleSOM: > > > > > > git clone --recursive https://github.com/smarr/TruffleSOM.git > > > cd TruffleSOM > > > ant jar > > > cd $GRAAL > > > > > > -- > > > Stefan Marr > > > Software Languages Lab > > > Vrije Universiteit Brussel > > > Pleinlaan 2 / B-1050 Brussels / Belgium > > > http://soft.vub.ac.be/~smarr > > > Phone: +32 2 629 2974 > > > Fax: +32 2 629 3525 > > > > > > > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From christian.humer at gmail.com Wed Dec 18 08:10:55 2013 From: christian.humer at gmail.com (Christian Humer) Date: Wed, 18 Dec 2013 17:10:55 +0100 Subject: Regression for TraceTruffleCompilationDetails? In-Reply-To: References: <00B651A1-1178-4171-BBA5-CD30FC916927@stefan-marr.de> Message-ID: Hi Stefan, The problem is located in the VariableNode class. At the point where you access frame it escapes. So Graal will materialize the frame in front of the frame.getObject. Unfortunately the TraceTruffleCompilationDetails option fails to handle this case. I will fix that. However your implementation of VariableNode And VariableWriteNode is completely off the current Truffle way. If you access your variable by always materializing it first, you will end up having a lot materialization of frames. This is also why pretty simple methods produce a lot of code in your implementation. It does not really make much sense if you try to optimize your arithmetics until your variable accesses are not fixed. So I think you should focus on that problem first. If you want to store a pointer to the parent frame, a custom implementation of Arguments may be the place to store it. Please see SL as a reference, which also implements a custom Arguments. Try to only use VirtualFrames accesses on the fast path. For that you may also need to create proper FrameDescriptors etc. Hope this helps. Cheers, - Christian Humer On Wed, Dec 18, 2013 at 4:45 PM, Christian Humer wrote: > Hi Stefan, > > That --recursive seemed to have fixed my problem. Thx! > Will have a look. > > > - Christian Humer > > > On Wed, Dec 18, 2013 at 4:22 PM, Stefan Marr wrote: > >> Hi Christian: >> >> Sorry, yes, TruffleSOM is not tested on Windows, and there are certainly >> hidden problems. >> Since I don?t have access to a windows box, I unfortunately can?t provide >> you with something more robust, sorry. >> >> You are running here into problems because the TruffleSOM git repo uses >> symlinks and core-lib is the git submodule to which the symlinks should be >> pointing. And symlinks aren?t supported on NTFS? >> >> The problem you are seeing with the missing bitXor: primitive is probably >> caused by a mismatch between the core-lib version on the TruffleSOM version. >> >> Please note the `--recursive` in the git command line: `git clone >> --recursive https://github.com/smarr/TruffleSOM.git` >> The proper version should normally be loaded with the following commands >> after a non-recursive clone: >> git submodule init >> git submodule update >> >> With regard to [1]: The simple answer is, because I didn?t write that >> code. I?ll fix it. >> >> Either way, thanks for looking into it. Not sure whether it is an >> important issue, but I worked around it by just swallowing the exception. >> >> Best regards >> Stefan >> >> On 18 Dec 2013, at 16:03, Christian Humer >> wrote: >> >> > Hi Stefan, >> > >> > I gave it another try even so you did not provide me with a more robust >> form for the command line. After I've hardcoded the Universe#fileSeparator >> to a "/" I managed to at least run something [1] . After I've fixed the >> class path provided in your -cp which is not where it should be if you do a >> clean checkout from git I came up with this command line: >> > >> > mx --vm server vm -G:+TraceTruffleCompilationDetails >> -Xbootclasspath/a:../TruffleSOM/build/classes;../TruffleSOM/libs/com.oracle.truffle.api.jar;../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar >> som.vm.Universe -cp ../TruffleSOM/core-lib/Smalltalk >> ../TruffleSOM/core-lib/Examples/Benchmarks/BenchmarkHarness.som IntegerLoop >> 1 2 2000 >> > >> > However I got this output on the console: >> > Warning: Primitive bitXor: is not in class definition for class Double >> > Exception in thread "main" java.lang.RuntimeException: This should not >> happen in TruffleSOM >> > at >> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.createCachedNode(BinarySendNode.java:162) >> > at >> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.specialize(BinarySendNode.java:141) >> > at >> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) >> > at >> som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) >> > at >> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) >> > at >> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) >> > at som.interpreter.Method.messageSendExecution(Method.java:89) >> > at som.interpreter.Method.execute(Method.java:77) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) >> > at >> som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233) >> > at >> som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86) >> > at >> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) >> > at >> som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) >> > at >> som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60) >> > at >> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) >> > at >> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) >> > at som.interpreter.Method.messageSendExecution(Method.java:89) >> > at som.interpreter.Method.execute(Method.java:77) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) >> > at >> som.interpreter.nodes.messages.BinarySendNode$InlinableSendNode.executeEvaluated(BinarySendNode.java:233) >> > at >> som.interpreter.nodes.messages.BinarySendNode$CachedSendNode.executeEvaluated(BinarySendNode.java:86) >> > at >> som.interpreter.nodes.messages.BinarySendNode$UninitializedSendNode.executeEvaluated(BinarySendNode.java:117) >> > at >> som.interpreter.nodes.messages.BinarySendNode.executeGeneric(BinarySendNode.java:58) >> > at >> som.interpreter.nodes.messages.TernarySendNode.executeGeneric(TernarySendNode.java:60) >> > at >> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:43) >> > at >> som.interpreter.nodes.SequenceNode.executeGeneric(SequenceNode.java:1) >> > at som.interpreter.Method.messageSendExecution(Method.java:89) >> > at som.interpreter.Method.execute(Method.java:77) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:214) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.interpreterCall(OptimizedCallTarget.java:143) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.callHelper(OptimizedCallTarget.java:98) >> > at >> com.oracle.graal.truffle.OptimizedCallTarget.call(OptimizedCallTarget.java:75) >> > at com.oracle.truffle.api.CallTarget.call(CallTarget.java:62) >> > at som.vmobjects.SMethod.invokeRoot(SMethod.java:86) >> > at som.vm.Universe.execute(Universe.java:302) >> > at som.vm.Universe.interpret(Universe.java:77) >> > at som.vm.Universe.main(Universe.java:63) >> > >> > Whats this? I stopped investigating at this point. >> > >> > [1] Why didnt you just use the java.io.File API in the jdk to parse >> your pathes? >> > >> > >> > Cheers, >> > >> > - Christian Humer >> > >> > >> > On Mon, Dec 16, 2013 at 2:57 PM, Stefan Marr >> wrote: >> > Hi Christian: >> > >> > Since I don?t know exactly whether there is anything Windows related >> going wrong, perhaps a few additional notes on my setup. >> > I think, the standard problems should be that either the paths in the >> command line are not correct, or the git repo wasn?t checked out with its >> submodules: >> > >> > To clone the git repo of TruffleSOM with its submodules: >> > git clone --recursive https://github.com/smarr/TruffleSOM.git >> > >> > In contrast to other Truffle languages, TruffleSOM wasn?t yet adapted >> to the mx compilation infrastructure, but uses a simple ant script. >> > >> > Executing `ant tests` should compile the necessary files and execute a >> simple test. >> > Note, it will download the necessary precompiled Truffle jars. I >> guess, that should work on Windows. >> > >> > Afterwards, it will depend on where your Graal folder is located. >> > >> > The command line assumes that it is in a folder next to TruffleSOM, so >> in the command line, `../TruffleSOM` would need to be replaced for other >> locations accordingly. Perhaps the path separators need to be changed for >> windows as well. >> > >> > > ./mx.sh --vm server vm -G:+TraceTruffleCompilationDetails >> -Xbootclasspath/a:../TruffleSOM/build/classes:../TruffleSOM/libs/com.oracle.truffle.api.jar:../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar >> som.vm.Universe -cp ../TruffleSOM/Smalltalk >> ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 >> > >> > >> > After the mx.sh arguments, the bootclass path is set to include the >> Truffle libraries, as well as the compiled TruffleSOM classes (from the >> build/classes folder). >> > The main class of TruffleSOM is som.vm.Universe, `-cp` gives a class >> path to SOM to enabled to find its Smalltalk class library, and the main >> script to be executed is >> ../TruffleSOM/Examples/Benchmarks/BenchmarkHarness.som with a name for the >> benchmark and infos on how many iterations, and warmup cycles should be >> executed. >> > >> > Thanks for looking into the issue. I worked around it by just catching >> the exception for the moment. >> > >> > Best regards >> > Stefan >> > >> > On 16 Dec 2013, at 11:51, Christian Humer >> wrote: >> > >> > > Hi Stefan, >> > > >> > > Could you please provide a little more robust command line for the >> problem? >> > > I just completely failed to run it on windows. >> > > >> > > >> > > - Christian Humer >> > > >> > > >> > > On Mon, Dec 16, 2013 at 11:13 AM, Stefan Marr >> wrote: >> > > Hi: >> > > >> > > I am running here into a class cast exception when using >> -G:+TraceTruffleCompilationDetails: >> > > >> > > java.lang.ClassCastException: >> com.oracle.graal.truffle.nodes.frame.NewFrameNode cannot be cast to >> com.oracle.graal.nodes.ConstantNode >> > > at >> com.oracle.graal.truffle.PartialEvaluator.expandTree(PartialEvaluator.java:193) >> > > >> > > The corresponding line is: >> > > ConstantNode constantNode = (ConstantNode) >> methodCallTargetNode.arguments().first(); >> > > >> > > However, the first argument is not a ConstantNode but a NewFrameNode >> (the new frame node looks like one of mine, i.e., for a TruffleSOM method >> call). >> > > >> > > The targetMethod of is >> `HotSpotMethod`. >> > > >> > > The problem can be triggered for instance with the following >> TruffleSOM benchmark: >> > > >> > > ./mx.sh -d --vm server vm -G:+TraceTruffleCompilationDetails >> -Xbootclasspath/a:../som/build/classes:../som/libs/com.oracle.truffle.api.jar:../som/libs/com.oracle.truffle.api.dsl.jar >> som.vm.Universe -cp ../som/Smalltalk >> ../som/Examples/Benchmarks/BenchmarkHarness.som Loop 1 100 100 >> > > >> > > I suppose the receiver is here expected to be constant to print out >> tracing information, but it isn?t in my case. >> > > >> > > Is there perhaps some simple work-around possible? >> > > >> > > Thanks >> > > Stefan >> > > >> > > To check out TruffleSOM: >> > > >> > > git clone --recursive https://github.com/smarr/TruffleSOM.git >> > > cd TruffleSOM >> > > ant jar >> > > cd $GRAAL >> > > >> > > -- >> > > Stefan Marr >> > > Software Languages Lab >> > > Vrije Universiteit Brussel >> > > Pleinlaan 2 / B-1050 Brussels / Belgium >> > > http://soft.vub.ac.be/~smarr >> > > Phone: +32 2 629 2974 >> > > Fax: +32 2 629 3525 >> > > >> > > >> > >> > -- >> > Stefan Marr >> > Software Languages Lab >> > Vrije Universiteit Brussel >> > Pleinlaan 2 / B-1050 Brussels / Belgium >> > http://soft.vub.ac.be/~smarr >> > Phone: +32 2 629 2974 >> > Fax: +32 2 629 3525 >> > >> > >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > From tom.deneau at amd.com Wed Dec 18 09:43:05 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 18 Dec 2013 17:43:05 +0000 Subject: --vm graal Message-ID: Sometimes I want to test an AMD64 compilation thru --vm graal. What flags can I use to make graal compile a method sooner? -- Tom From doug.simon at oracle.com Wed Dec 18 11:00:47 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 18 Dec 2013 20:00:47 +0100 Subject: --vm graal In-Reply-To: References: Message-ID: <2317FFC5-138F-46F2-8E1A-2A26BE3F757F@oracle.com> The -Xcomp option in combination with -XX:CompileOnly should do it. On Dec 18, 2013, at 6:43 PM, Deneau, Tom wrote: > Sometimes I want to test an AMD64 compilation thru --vm graal. What flags can I use to make graal compile a method sooner? > > -- Tom From tom.deneau at amd.com Wed Dec 18 11:43:09 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Wed, 18 Dec 2013 19:43:09 +0000 Subject: --vm graal In-Reply-To: <2317FFC5-138F-46F2-8E1A-2A26BE3F757F@oracle.com> References: <2317FFC5-138F-46F2-8E1A-2A26BE3F757F@oracle.com> Message-ID: And if I want it to interpret for a while (but not too long) to get profile information, do I just use one of the -XX: compile thresholds? > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Wednesday, December 18, 2013 1:01 PM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: --vm graal > > The -Xcomp option in combination with -XX:CompileOnly should do it. > > On Dec 18, 2013, at 6:43 PM, Deneau, Tom wrote: > > > Sometimes I want to test an AMD64 compilation thru --vm graal. What > flags can I use to make graal compile a method sooner? > > > > -- Tom > From christian.thalinger at oracle.com Wed Dec 18 11:59:15 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 18 Dec 2013 11:59:15 -0800 Subject: --vm graal In-Reply-To: References: <2317FFC5-138F-46F2-8E1A-2A26BE3F757F@oracle.com> Message-ID: <3C9CBFBA-BF4F-4D74-98F3-3FECBE7A8103@oracle.com> On Dec 18, 2013, at 11:43 AM, Deneau, Tom wrote: > And if I want it to interpret for a while (but not too long) to get profile information, do I just use one of the -XX: compile thresholds? Yes. > > >> -----Original Message----- >> From: Doug Simon [mailto:doug.simon at oracle.com] >> Sent: Wednesday, December 18, 2013 1:01 PM >> To: Deneau, Tom >> Cc: graal-dev at openjdk.java.net >> Subject: Re: --vm graal >> >> The -Xcomp option in combination with -XX:CompileOnly should do it. >> >> On Dec 18, 2013, at 6:43 PM, Deneau, Tom wrote: >> >>> Sometimes I want to test an AMD64 compilation thru --vm graal. What >> flags can I use to make graal compile a method sooner? >>> >>> -- Tom >> > > From eric.caspole at amd.com Thu Dec 19 13:59:12 2013 From: eric.caspole at amd.com (Eric Caspole) Date: Thu, 19 Dec 2013 16:59:12 -0500 Subject: How we are diverting parallel stream forEach() Message-ID: <52B36C30.3030409@amd.com> As we discussed today on the skype, this webrev of the stream API will give you an idea of how we are diverting ForEachOp into HSA: http://cr.openjdk.java.net/~ecaspole/sumatrajdk.02/webrev/ This might be bit-rot just a bit off the jdk tip but it has not changed that much in the last several months. Regards, Eric From doug.simon at oracle.com Thu Dec 19 14:27:33 2013 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 19 Dec 2013 23:27:33 +0100 Subject: actions In-Reply-To: References: Message-ID: <60EB4D24-67A5-4007-921A-CC6C65853563@oracle.com> As a result of the Sumatra Skype meeting today on the topic of how to handle deopt for HSAIL & PTX, I?ve signed up to investigate changes in the C++ layer of Graal to accommodate installing code whose debug info is not in terms of host machine state (e.g. uses a different register set than the host register set). -Doug On Dec 19, 2013, at 11:02 PM, Deneau, Tom wrote: > Gilles, Doug -- > > Could you post to the graal-dev list what the two action items you took were? > > -- Tom From duboscq at ssw.jku.at Fri Dec 20 02:30:52 2013 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 20 Dec 2013 11:30:52 +0100 Subject: actions In-Reply-To: <60EB4D24-67A5-4007-921A-CC6C65853563@oracle.com> References: <60EB4D24-67A5-4007-921A-CC6C65853563@oracle.com> Message-ID: As for me, I'll look into the C++ changes needed to easily rebuild the interpreter frames from a raw buffer provided by the GPU during deoptimization. -Gilles On Thu, Dec 19, 2013 at 11:27 PM, Doug Simon wrote: > As a result of the Sumatra Skype meeting today on the topic of how to > handle deopt for HSAIL & PTX, I?ve signed up to investigate changes in the > C++ layer of Graal to accommodate installing code whose debug info is not > in terms of host machine state (e.g. uses a different register set than the > host register set). > > -Doug > > On Dec 19, 2013, at 11:02 PM, Deneau, Tom wrote: > > > Gilles, Doug -- > > > > Could you post to the graal-dev list what the two action items you took > were? > > > > -- Tom > > From tom.deneau at amd.com Fri Dec 20 06:29:03 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 20 Dec 2013 14:29:03 +0000 Subject: UnwindNode and deoptimization Message-ID: Just to close the loop on this, this was answered in the Skype call with Gilles and Doug, and the proper way to handle this is to transform the UnwindNode into a DeoptimizeNode in one of the earlier lowering phases. (which should make things much simpler). -- Tom > -----Original Message----- > From: Deneau, Tom > Sent: Monday, December 16, 2013 10:14 AM > To: graal-dev at openjdk.java.net > Subject: UnwindNode and deoptimization > > Gilles, Doug, etc. --- > > In our recent hsail backend deoptimization experiments, as mentioned > previously, we noticed that something like a BoundsCheckException can be > presented to the LIR as either a DeoptimizeNode or an UnwindNode (the > UnwindNodes came if there was profiling information I think). > > Anyway, since we want to handle both of these the same way, namely > deoptimizing, when we saw un UnwindNode, we were getting our > LIRFrameState by looking at the deoptState of the ForeignCallNode > exception that is part of the unwindNode. > > I noticed in a sync with the latest trunk that this infrastructure has > changed now and the ForeignCallNode will often have a deoptState of > null. I see that there is a deoptState on the ForeignCallNode.next > which is a NullCheckNode which I suppose could be used but I'm not sure > that's the right approach. > > I was wondering what is the "right" way to handle this. I think the > high level summary is that if in the HSAIL backend we are presented with > an UnwindNode with an associated ForeignCallNode, we cannot handle the > ForeignCall in HSAIL and would like to treat this as a deoptimization. > Is there some node transformation perhaps that we should be doing to > accomplish this? > > -- Tom > From tom.deneau at amd.com Fri Dec 20 06:41:22 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Fri, 20 Dec 2013 14:41:22 +0000 Subject: graalCodeInstaller questions, recording scopes, etc. Message-ID: Closing the loop again, for my original questions, adding answers below that were relayed in the Skype call on Thursday... > -----Original Message----- > From: Deneau, Tom > Sent: Monday, December 16, 2013 3:58 PM > To: graal-dev at openjdk.java.net > Subject: graalCodeInstaller questions, recording scopes, etc. > > Wanted to run a sketch of our plans by the rest of the graal team and > get some advice... > > When there are situations we cannot handle on the HSAIL backend, we want > to deoptimize and handle them in the interpreter.? Our thoughts were > that at codeInstall time, we could record the various infopoints in the > compilationResult and then the graalCodeInstaller would then record > these in some way in the nmethod or in some structure that we could > access at runtime.? Then at runtime, if a workitem requests a deopt, it > would save its HSAIL state, including all the appropriate HSAIL > registers in a place that the host side could access. > > If the JVM code that invokes the kernel sees that one or more workitems > have requested a deopt, for each one we could > > ?? * map the HSAIL "PC" back to the appropriate infopoint > > ?? * use the infopoint and the saved HSAIL registers to construct the, > ???? host-based interpreter frames > > ?? * and then let things continue in the interpreter. > > Some questions: > > ?? * What reason should we use for the InfopointReason?? In > ???? graalCodeInstaller.cpp, it seems that some types get "recorded" > ???? in the debug_recorder via site_Safepoint or site_Call, while > ???? others like InfopointReason::LINE_NUMBER do not.? I am assuming > ???? we should "record" ours but am not sure how this all plays > ???? together.? Can we map back to an infopoint that has not been > ???? recorded? > Looking back we didn't really answer this question. I know now we do need to map to some Infopoint type that does get recorded in ScopeDesc. The AMD64 backend for DeoptimizeNode issues a InfopointReason::CALL which is a side effect of making a Direct Foreign call. On the HSAIL side, we are not really making a foreign call and I am unsure of the full semantics of the other types. As an experiment I tried InfopointReason.IMPLICIT_EXCEPTION which does get recorded in the ScopeDesc thru site_Safepoint. But again, not sure if that is the recommendation. > ?? * Our infopoints have byteCodePositions.? The ones that get > ???? "recorded" go thru record_scope which has all sorts of > ???? host-specific checking on the scope info.? For instance, > ???? get_hotspot_value will compare a register # with > ???? RegisterImpl::number_of_registers (which refers to the host) and > ???? if it is, assert that the type is FLOAT or DOUBLE.? None of this > ???? holds with HSAIL registers.? What is the best way to resolve > ???? this? > This issue will be handled by the virtualization of some of the calls in graalCodeInstaller that Doug will be implementing. > -- Tom From java at stefan-marr.de Fri Dec 20 10:01:15 2013 From: java at stefan-marr.de (Stefan Marr) Date: Fri, 20 Dec 2013 19:01:15 +0100 Subject: TruffleSOM Status Update Message-ID: <1C08AF8E-F351-4BB2-B03C-9E01D55B6E4B@stefan-marr.de> Hi: Brief Summary: I finally got around to adapt the TruffleSOM parser to handle access to the outer lexical scopes of blocks differently. This avoids the use of materialized frames. Together with the type specializations for primitive operations/builtins, this completes my list of open known issues that need to be solved in TruffleSOM. However, the performance results are less then impressive: TruffleSOM is roughly 20-30x slower than RPySOM. And, I have no idea where to start fixing that. Ok, so a few more details. Upvalues: Access to Lexical Block Scopes ---------------------------------------- In SOM Smalltalk, control structures are implemented with message sends and blocks, so it is common to have some nesting of blocks, and access variables in their lexical scope. For instance: foobar: arg = ( | a | arg ifTrue: [ a := #bar ] ifFalse: [ a := #foo ]. ^ a ) This simple example relies in the worst case on a library implementation of #ifTrue:ifFalse:, in TruffleSOM it is already specialized with a distinct AST node. But still, we have the issue that two blocks need to access `a` outside of its direct scope. Originally, I solved that the classic way and kept pointers to materialized frames in each block in order to find the lexical scope. Now, I solved it differently: methods and blocks know during compilation whether a variable is accessed outside of its context. If so, the variable will be turned into an `upvalue`. Thus, it is not stored in the frame, but in a so-called `upvalue` array. In this example, the method foobar has an upvalue array with one element: `a`. The two blocks do not have any variables, so, they also don?t have any upvalues. But, the blocks need a reference to the outer lexical scope, in order to access the upvalues. The upvalues arrays itself is kept in an `Arguments` object [1] pass on method invocation. Since each method/block knows the number of upvalues it has, the array can be created together with the `Arguments` object for it. While this approach avoids the materialization of frames, it probably has its own issue. First, the `Arguments` object is now stored in block objects as the lexical outer context, in order to allow the necessary access to upvalues. Thus, the `Arguments` object ?escapes?, which might be problematic, because the JavaDoc of com.oracle.truffle.api.Arguments says it shouldn?t. Second, the `Arguments` object uses a plain Object[] array, and thus, all values that it stores need to be boxed, which might not be desirable for simple integer loops. Arguments Object Use -------------------- Another aspect of my Arguments use might be problematic as well. I now use it as one combined structure to store all relevant information of the activation (method or block). Thus, it also has the reference to `self`, the method arguments as an Object array, and my marker to indicate whether a frame is on the stack or not. Earlier, I stored all this information in separate slots in the frame. But now, to simplify the handling of context, I keep everything together in the `Arguments` object. I am not sure whether I could actually do it any other way without having to materialize frames at one point. But, this means, `Arguments` objects do escape, and self is always some boxed Java object, even thought it might be ideally an unboxed primitive int. But, since arguments are passed as an Object[] as in the SimpleLanguage, I guess that this is common practice? Type Specialization ------------------- For the type specialization, I already mentioned a few details. Now with having the materialized frames solved, I hoped the type specialization would also lead to better performance, but it is only in the 30% range, and thus, doesn?t really help to fix the huge gap with RPySOM. I think, something else is still going very wrong here. Overall, my design with implicit casts to unwrap SOM objects leads to the situation that most of the time, there are just Java objects floating around. Only when an object gets assigned to a SOM object field, it gets wrapped as a SOM object. So, I think, that reaches one of the relevant goals, however, it is Java objects instead of Java primitive values. I don?t know how that could be fixed, and whether it actually needs to be fixed. My memory tells my that one of the main rules was that a parent node should not make assumptions about a child node. This manifests itself in using `executeGeneric(.)` or equivalent methods to execute child nodes. However, I don?t see how the boxing could be avoided then, if we actually have nicely specialized primitives that implement for instance the addition of two Java unboxed ints. I guess, the partial evaluator will see such patterns and just do the right thing? Well, I don?t know. I also spend a bit of time with igv and -G:Dump= to poke around in the graphs to try to understand where it is going wrong, but without much success so far. The Truffle ASTs look nice and as I would expect them to look. Inlining seems to work, as well as specialization. However, it still generates enormous amounts of stuff for simple integer loops. And I don?t how to start reducing that to the necessary things. Any help on how to speed things up, and what could be wrong are highly appreciate. Thanks Stefan [1] https://github.com/SOM-st/TruffleSOM/blob/master/src/som/interpreter/Arguments.java#L33 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From ndrzmansn at gmail.com Fri Dec 20 13:25:27 2013 From: ndrzmansn at gmail.com (Wei Zhang) Date: Fri, 20 Dec 2013 13:25:27 -0800 Subject: ZipPy status update Message-ID: Hi all, I want to give you a short update about the status of ZipPy, the Python truffle implementation we've working on at UC Irvine. I attached the performance charts that compare ZipPy to the other major Python 2 or 3 implementations like CPython and PyPy. The best speedup over CPython3.3 so far is over 100x on fannkuchredux. Please refer to the link below for more numbers: http://goo.gl/NeuIrf In general, we are getting fairly close to PyPy with a few benchmarks running even faster. Built-in function specialization and inlining give a substantial boost on performance. Thanks to Gulfem Savrun Yeniceri for rewriting all the built-ins. In terms of optimizations, ZipPy currently uses shape based object model, unboxed collection type storage for list and array. I implemented inline caching for attribute accesses in Python, but still having compilation problems. This is the reason why I didn't include more object intensive benchmarks like richards. We also plan to apply some specific optimizations for Python generators. Hope you all have a great holiday! Thanks, /Wei From thomas.wuerthinger at oracle.com Fri Dec 20 14:03:29 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Fri, 20 Dec 2013 23:03:29 +0100 Subject: ZipPy status update In-Reply-To: References: Message-ID: <9B000DF0-4BF6-4609-8FCE-39718F87D7A7@oracle.com> Thanks for the update, Wei. This looks great! - thomas On 20 Dec 2013, at 22:25, Wei Zhang wrote: > Hi all, > > I want to give you a short update about the status of ZipPy, the > Python truffle implementation we've working on at UC Irvine. > > I attached the performance charts that compare ZipPy to the other > major Python 2 or 3 implementations like CPython and PyPy. > The best speedup over CPython3.3 so far is over 100x on fannkuchredux. > Please refer to the link below for more numbers: > http://goo.gl/NeuIrf > > In general, we are getting fairly close to PyPy with a few benchmarks > running even faster. > > Built-in function specialization and inlining give a substantial boost > on performance. Thanks to Gulfem Savrun Yeniceri for rewriting all the > built-ins. > > In terms of optimizations, ZipPy currently uses shape based object > model, unboxed collection type storage for list and array. I > implemented inline caching for attribute accesses in Python, but > still having compilation problems. This is the reason why I didn't > include more object intensive benchmarks like richards. > We also plan to apply some specific optimizations for Python generators. > > Hope you all have a great holiday! > Thanks, > > /Wei From java at stefan-marr.de Fri Dec 20 16:09:17 2013 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 21 Dec 2013 01:09:17 +0100 Subject: ZipPy status update In-Reply-To: References: Message-ID: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Hi Wei: On 20 Dec 2013, at 22:25, Wei Zhang wrote: > I attached the performance charts that compare ZipPy to the other > major Python 2 or 3 implementations like CPython and PyPy. > The best speedup over CPython3.3 so far is over 100x on fannkuchredux. > Please refer to the link below for more numbers: > http://goo.gl/NeuIrf > > In general, we are getting fairly close to PyPy with a few benchmarks > running even faster. After looking at the code, I am kind of surprised that you are seeing so great performance. The first thing, I tried to see is what your `Arguments` objects look like and how you use frames. And I see that you actually rely heavily on materialized frames.[1] The only difference I can make out, compared to what I had, is that you materialize conditionally. I do wonder, what is the typical granularity of a Python method? At least in SOM, methods seem to be rather small. Perhaps a few AST nodes on average. Could that make a difference? Another detail I noticed is that you are using another strategy for type handling in the type system. You use a combination of @TypeCheck and @TypeCast, while I use @ImplicitCast. What is the difference of these two approaches? > Hope you all have a great holiday! Same to you! Thanks Stefan [1] https://bitbucket.org/ssllab/zippy/src/43cbb6f6410da598623074dc3ce50414cd762567/graal/edu.uci.python.runtime/src/edu/uci/python/runtime/function/PArguments.java?at=default#cl-37 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From java at stefan-marr.de Fri Dec 20 16:09:39 2013 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 21 Dec 2013 01:09:39 +0100 Subject: ZipPy status update In-Reply-To: References: Message-ID: <340F25A0-65D8-46C2-B238-08C9DDBBC16F@stefan-marr.de> Hi Wei: On 20 Dec 2013, at 22:25, Wei Zhang wrote: > I attached the performance charts that compare ZipPy to the other > major Python 2 or 3 implementations like CPython and PyPy. > The best speedup over CPython3.3 so far is over 100x on fannkuchredux. > Please refer to the link below for more numbers: > http://goo.gl/NeuIrf > > In general, we are getting fairly close to PyPy with a few benchmarks > running even faster. After looking at the code, I am kind of surprised that you are seeing so great performance. The first thing, I tried to see is what your `Arguments` objects look like and how you use frames. And I see that you actually rely heavily on materialized frames.[1] The only difference I can make out, compared to what I had, is that you materialize conditionally. I do wonder, what is the typical granularity of a Python method? At least in SOM, methods seem to be rather small. Perhaps a few AST nodes on average. Could that make a difference? Another detail I noticed is that you are using another strategy for type handling in the type system. You use a combination of @TypeCheck and @TypeCast, while I use @ImplicitCast. What is the difference of these two approaches? > Hope you all have a great holiday! Same to you! Thanks Stefan [1] https://bitbucket.org/ssllab/zippy/src/43cbb6f6410da598623074dc3ce50414cd762567/graal/edu.uci.python.runtime/src/edu/uci/python/runtime/function/PArguments.java?at=default#cl-37 -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From ndrzmansn at gmail.com Fri Dec 20 16:45:49 2013 From: ndrzmansn at gmail.com (Wei Zhang) Date: Fri, 20 Dec 2013 16:45:49 -0800 Subject: ZipPy status update In-Reply-To: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Hi Stefan, > After looking at the code, I am kind of surprised that you are seeing so great performance. > The first thing, I tried to see is what your `Arguments` objects look like and how you use frames. And I see that you actually rely heavily on materialized frames.[1] > The only difference I can make out, compared to what I had, is that you materialize conditionally. Only functions that close over its declaration frame (closures) use PArguments#declarationFrame. This doesn't happen so often in my benchmarks. In most cases, zippy accesses local variable using VirtualFrames, which is optimized by Truffle/Graal. > I do wonder, what is the typical granularity of a Python method? > At least in SOM, methods seem to be rather small. Perhaps a few AST nodes on average. > Could that make a difference? Zippy inlines function calls when they become hot. Inlining helps performance a lot. I strongly recommend you to apply inlining in TruffleSOM if you haven't yet. > Another detail I noticed is that you are using another strategy for type handling in the type system. You use a combination of @TypeCheck and @TypeCast, while I use @ImplicitCast. > What is the difference of these two approaches? I use @TypeCheck and @TypeCast to customize type checks and conversions in ZipPy. I just followed the SimpleLanguage examples in Truffle API. @ImplicitCast is new to me. I don't know how to use it, since there isn't any related document or example. Hope this helps. Thanks, /Wei On Fri, Dec 20, 2013 at 4:09 PM, Stefan Marr wrote: > Hi Wei: > > On 20 Dec 2013, at 22:25, Wei Zhang wrote: > >> I attached the performance charts that compare ZipPy to the other >> major Python 2 or 3 implementations like CPython and PyPy. >> The best speedup over CPython3.3 so far is over 100x on fannkuchredux. >> Please refer to the link below for more numbers: >> http://goo.gl/NeuIrf >> >> In general, we are getting fairly close to PyPy with a few benchmarks >> running even faster. > > After looking at the code, I am kind of surprised that you are seeing so great performance. > The first thing, I tried to see is what your `Arguments` objects look like and how you use frames. And I see that you actually rely heavily on materialized frames.[1] > The only difference I can make out, compared to what I had, is that you materialize conditionally. > > I do wonder, what is the typical granularity of a Python method? > At least in SOM, methods seem to be rather small. Perhaps a few AST nodes on average. > Could that make a difference? > > Another detail I noticed is that you are using another strategy for type handling in the type system. You use a combination of @TypeCheck and @TypeCast, while I use @ImplicitCast. > What is the difference of these two approaches? > >> Hope you all have a great holiday! > > Same to you! > > Thanks > Stefan > > [1] https://bitbucket.org/ssllab/zippy/src/43cbb6f6410da598623074dc3ce50414cd762567/graal/edu.uci.python.runtime/src/edu/uci/python/runtime/function/PArguments.java?at=default#cl-37 > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > From mario.wolczko at oracle.com Fri Dec 20 17:52:18 2013 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Fri, 20 Dec 2013 17:52:18 -0800 Subject: Graal on Mavericks In-Reply-To: <5296BEDF.8010004@Oracle.COM> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> Message-ID: <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. My mx/env contains: DEFAULT_VM=server COMPILER_WARNINGS_FATAL=false USE_CLANG=true LFLAGS=-Xlinker -lstdc++ USE_PRECOMPILED_HEADER=0 Here's the log: Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) cd /Users/mario/Work/Eclipse/graal/make; \ /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd cd /Users/mario/Work/Eclipse/graal/build/bsd; \ /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. make[4]: Nothing to be done for `all'. make[4]: Nothing to be done for `all'. if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ -a "x86" != "arm" \ -a "x86" != "ppc" \ -a "x86" != "zero" ] ; then \ /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ fi make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. echo "dtrace headers generated" dtrace headers generated Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp Compiling ../generated/adfiles/ad_x86_64.cpp Compiling ../generated/adfiles/ad_x86_64_clone.cpp Compiling ../generated/adfiles/ad_x86_64_expand.cpp Compiling ../generated/adfiles/ad_x86_64_format.cpp Compiling ../generated/adfiles/ad_x86_64_gen.cpp Compiling ../generated/adfiles/ad_x86_64_misc.cpp clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh clang: note: diagnostic msg: ******************** make[4]: *** [ad_x86_64_misc.o] Error 254 make[4]: *** Waiting for unfinished jobs.... clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh clang: note: diagnostic msg: ******************** make[4]: *** [ad_x86_64_gen.o] Error 254 clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh clang: note: diagnostic msg: ******************** make[4]: *** [ad_x86_64.o] Error 254 clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh clang: note: diagnostic msg: ******************** make[4]: *** [ad_x86_64_expand.o] Error 254 clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh clang: note: diagnostic msg: ******************** make[4]: *** [abstractCompiler.o] Error 254 clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh clang: note: diagnostic msg: ******************** make[4]: *** [accessFlags.o] Error 254 clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh clang: note: diagnostic msg: ******************** make[4]: *** [ad_x86_64_clone.o] Error 254 clang: error: unable to execute command: Segmentation fault: 11 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh clang: note: diagnostic msg: ******************** make[4]: *** [ad_x86_64_format.o] Error 254 make[3]: *** [the_vm] Error 2 make[2]: *** [product] Error 2 make[1]: *** [generic_build2] Error 2 make: *** [product] Error 2 From christian.thalinger at oracle.com Fri Dec 20 18:02:13 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 20 Dec 2013 18:02:13 -0800 Subject: Graal on Mavericks In-Reply-To: <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: > I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. > > My mx/env contains: > > DEFAULT_VM=server > COMPILER_WARNINGS_FATAL=false > USE_CLANG=true > LFLAGS=-Xlinker -lstdc++ > USE_PRECOMPILED_HEADER=0 > > Here's the log: > > Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) > Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) > cd /Users/mario/Work/Eclipse/graal/make; \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > > python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared > Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) > Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) > mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd > cd /Users/mario/Work/Eclipse/graal/build/bsd; \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ > LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > > cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " > /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product > Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. > make[4]: Nothing to be done for `all'. > make[4]: Nothing to be done for `all'. > if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ > -a "x86" != "arm" \ > -a "x86" != "ppc" \ > -a "x86" != "zero" ] ; then \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ > fi > make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. > echo "dtrace headers generated" > dtrace headers generated > Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp > Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp > Compiling ../generated/adfiles/ad_x86_64.cpp > Compiling ../generated/adfiles/ad_x86_64_clone.cpp > Compiling ../generated/adfiles/ad_x86_64_expand.cpp > Compiling ../generated/adfiles/ad_x86_64_format.cpp > Compiling ../generated/adfiles/ad_x86_64_gen.cpp > Compiling ../generated/adfiles/ad_x86_64_misc.cpp > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_misc.o] Error 254 > > make[4]: *** Waiting for unfinished jobs.... > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_gen.o] Error 254 > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_expand.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [abstractCompiler.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [accessFlags.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_clone.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_format.o] Error 254 > > make[3]: *** [the_vm] Error 2 > > make[2]: *** [product] Error 2 > > make[1]: *** [generic_build2] Error 2 > > make: *** [product] Error 2 > > > > > From mario.wolczko at oracle.com Fri Dec 20 18:10:19 2013 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Fri, 20 Dec 2013 18:10:19 -0800 Subject: Graal on Mavericks In-Reply-To: References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: <4E722901-5B42-41D9-AF4D-70B81E71A767@oracle.com> Yes, it's happened a couple of times, with a mx clean in between. Are you using the latest Xcode? > On Dec 20, 2013, at 6:02 PM, Christian Thalinger wrote: > > This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? > >> On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: >> >> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >> >> My mx/env contains: >> >> DEFAULT_VM=server >> COMPILER_WARNINGS_FATAL=false >> USE_CLANG=true >> LFLAGS=-Xlinker -lstdc++ >> USE_PRECOMPILED_HEADER=0 >> >> Here's the log: >> >> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >> cd /Users/mario/Work/Eclipse/graal/make; \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> >> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> >> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >> make[4]: Nothing to be done for `all'. >> make[4]: Nothing to be done for `all'. >> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >> -a "x86" != "arm" \ >> -a "x86" != "ppc" \ >> -a "x86" != "zero" ] ; then \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >> fi >> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >> echo "dtrace headers generated" >> dtrace headers generated >> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >> Compiling ../generated/adfiles/ad_x86_64.cpp >> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >> Compiling ../generated/adfiles/ad_x86_64_format.cpp >> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_misc.o] Error 254 >> >> make[4]: *** Waiting for unfinished jobs.... >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_gen.o] Error 254 >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_expand.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [abstractCompiler.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [accessFlags.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_clone.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_format.o] Error 254 >> >> make[3]: *** [the_vm] Error 2 >> >> make[2]: *** [product] Error 2 >> >> make[1]: *** [generic_build2] Error 2 >> >> make: *** [product] Error 2 >> >> >> >> >> > From headius at headius.com Fri Dec 20 18:21:34 2013 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 21 Dec 2013 13:21:34 +1100 Subject: Graal on Mavericks In-Reply-To: <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: I built graal today on mavericks and it went well, but I don't think I am on updated xcode. - Charlie (mobile) On Dec 20, 2013 8:08 PM, "Mario Wolczko" wrote: > I'm getting my build environment going again since upgrading to Mavericks. > I'm getting a clang crash while compiling HotSpot - anyone seen this and > know the fix? This is while building the graal version associated with > fast_r. > > My mx/env contains: > > DEFAULT_VM=server > COMPILER_WARNINGS_FATAL=false > USE_CLANG=true > LFLAGS=-Xlinker -lstdc++ > USE_PRECOMPILED_HEADER=0 > > Here's the log: > > Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance > level 1.8 required) > Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance > level 1.8 required) > cd /Users/mario/Work/Eclipse/graal/make; \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make > BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 > BUILD_FLAVOR=product VM_TARGET=product generic_build2 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > > python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build > --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared > Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance > level 1.8 required) > Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance > level 1.8 required) > mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd > cd /Users/mario/Work/Eclipse/graal/build/bsd; \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f > /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ > LP64=1 MACOSX_UNIVERSAL=true > BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home > OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd > GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= > HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" > HOTSPOT_BUILD_VERSION=internal product > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > > cd bsd_amd64_compiler2/product && > /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " > /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product > Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. > make[4]: Nothing to be done for `all'. > make[4]: Nothing to be done for `all'. > if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ > -a "x86" != "arm" \ > -a "x86" != "ppc" \ > -a "x86" != "zero" ] ; then \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f > sa.make > /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; > \ > fi > make[5]: > `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' > is up to date. > echo "dtrace headers generated" > dtrace headers generated > Compiling > /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp > Compiling > /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp > Compiling ../generated/adfiles/ad_x86_64.cpp > Compiling ../generated/adfiles/ad_x86_64_clone.cpp > Compiling ../generated/adfiles/ad_x86_64_expand.cpp > Compiling ../generated/adfiles/ad_x86_64_format.cpp > Compiling ../generated/adfiles/ad_x86_64_gen.cpp > Compiling ../generated/adfiles/ad_x86_64_misc.cpp > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to > http://developer.apple.com/bugreporter/ and include the crash backtrace, > preprocessed source, and associated run script. > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to > http://developer.apple.com/bugreporter/ and include the crash backtrace, > preprocessed source, and associated run script. > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to > http://developer.apple.com/bugreporter/ and include the crash backtrace, > preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_misc.o] Error 254 > > make[4]: *** Waiting for unfinished jobs.... > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_gen.o] Error 254 > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to > http://developer.apple.com/bugreporter/ and include the crash backtrace, > preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_expand.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to > http://developer.apple.com/bugreporter/ and include the crash backtrace, > preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [abstractCompiler.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to > http://developer.apple.com/bugreporter/ and include the crash backtrace, > preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [accessFlags.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to > http://developer.apple.com/bugreporter/ and include the crash backtrace, > preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_clone.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see > invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to > http://developer.apple.com/bugreporter/ and include the crash backtrace, > preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp > > clang: note: diagnostic msg: > /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_format.o] Error 254 > > make[3]: *** [the_vm] Error 2 > > make[2]: *** [product] Error 2 > > make[1]: *** [generic_build2] Error 2 > > make: *** [product] Error 2 > > > > > > From java at stefan-marr.de Fri Dec 20 23:35:08 2013 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 21 Dec 2013 08:35:08 +0100 Subject: Graal on Mavericks In-Reply-To: References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: The last issue I saw on Mavericks was caused by an outdated JDK version being used. After updating to the latest version of Java 7, it went away. Best regards Stefan On 21 Dec 2013, at 03:21, Charles Oliver Nutter wrote: > I built graal today on mavericks and it went well, but I don't think I am > on updated xcode. > > - Charlie (mobile) > On Dec 20, 2013 8:08 PM, "Mario Wolczko" wrote: > >> I'm getting my build environment going again since upgrading to Mavericks. >> I'm getting a clang crash while compiling HotSpot - anyone seen this and >> know the fix? This is while building the graal version associated with >> fast_r. >> >> My mx/env contains: >> >> DEFAULT_VM=server >> COMPILER_WARNINGS_FATAL=false >> USE_CLANG=true >> LFLAGS=-Xlinker -lstdc++ >> USE_PRECOMPILED_HEADER=0 >> >> Here's the log: >> >> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance >> level 1.8 required) >> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance >> level 1.8 required) >> cd /Users/mario/Work/Eclipse/graal/make; \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make >> BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 >> BUILD_FLAVOR=product VM_TARGET=product generic_build2 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> >> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build >> --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance >> level 1.8 required) >> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance >> level 1.8 required) >> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f >> /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >> LP64=1 MACOSX_UNIVERSAL=true >> BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home >> OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd >> GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= >> HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" >> HOTSPOT_BUILD_VERSION=internal product >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> >> cd bsd_amd64_compiler2/product && >> /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >> make[4]: Nothing to be done for `all'. >> make[4]: Nothing to be done for `all'. >> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >> -a "x86" != "arm" \ >> -a "x86" != "ppc" \ >> -a "x86" != "zero" ] ; then \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f >> sa.make >> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; >> \ >> fi >> make[5]: >> `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' >> is up to date. >> echo "dtrace headers generated" >> dtrace headers generated >> Compiling >> /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >> Compiling >> /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >> Compiling ../generated/adfiles/ad_x86_64.cpp >> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >> Compiling ../generated/adfiles/ad_x86_64_format.cpp >> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see >> invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://developer.apple.com/bugreporter/ and include the crash backtrace, >> preprocessed source, and associated run script. >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see >> invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://developer.apple.com/bugreporter/ and include the crash backtrace, >> preprocessed source, and associated run script. >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see >> invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://developer.apple.com/bugreporter/ and include the crash backtrace, >> preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_misc.o] Error 254 >> >> make[4]: *** Waiting for unfinished jobs.... >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_gen.o] Error 254 >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see >> invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://developer.apple.com/bugreporter/ and include the crash backtrace, >> preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_expand.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see >> invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://developer.apple.com/bugreporter/ and include the crash backtrace, >> preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [abstractCompiler.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see >> invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://developer.apple.com/bugreporter/ and include the crash backtrace, >> preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [accessFlags.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see >> invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://developer.apple.com/bugreporter/ and include the crash backtrace, >> preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_clone.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see >> invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to >> http://developer.apple.com/bugreporter/ and include the crash backtrace, >> preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >> >> clang: note: diagnostic msg: >> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_format.o] Error 254 >> >> make[3]: *** [the_vm] Error 2 >> >> make[2]: *** [product] Error 2 >> >> make[1]: *** [generic_build2] Error 2 >> >> make: *** [product] Error 2 >> >> >> >> >> >> -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From java at stefan-marr.de Fri Dec 20 23:55:05 2013 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 21 Dec 2013 08:55:05 +0100 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Hi Wei: On 21 Dec 2013, at 01:45, Wei Zhang wrote: > Only functions that close over its declaration frame (closures) use > PArguments#declarationFrame. This doesn't happen so often in my > benchmarks. > In most cases, zippy accesses local variable using VirtualFrames, > which is optimized by Truffle/Graal. Well, closures are much more common in Smalltalk, I think. >> I do wonder, what is the typical granularity of a Python method? >> At least in SOM, methods seem to be rather small. Perhaps a few AST nodes on average. >> Could that make a difference? > > Zippy inlines function calls when they become hot. Inlining helps > performance a lot. > I strongly recommend you to apply inlining in TruffleSOM if you haven?t yet. TruffleSOM does inlining. I only see two difference when browsing your code. The first should actually be a benefit for TruffleSOM: I also inline trivial methods immediately, i.e., if a method just contains a literal or something similar, it is directly inlined without even a function call overhead, only protected by a polymorphic inline cache check node. The second difference I see is that you have a `prepareBodyNode()` operation that rewrites local variable access nodes. Why is that necessary? > >> Another detail I noticed is that you are using another strategy for type handling in the type system. You use a combination of @TypeCheck and @TypeCast, while I use @ImplicitCast. >> What is the difference of these two approaches? > > I use @TypeCheck and @TypeCast to customize type checks and > conversions in ZipPy. I just followed the SimpleLanguage examples in > Truffle API. > @ImplicitCast is new to me. I don't know how to use it, since there > isn?t any related document or example. There is a tiny example in SimpleLanguage? That?s where I took it from. But I have the feeling the generated code when using @TypeCheck and @TypeCast looks quite a bit simpler. Thanks for the comments Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From doug.simon at oracle.com Sat Dec 21 02:15:07 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 21 Dec 2013 11:15:07 +0100 Subject: Graal on Mavericks In-Reply-To: <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: <7CC66D91-A576-4F01-8FA3-3BE2E9E2CE6F@oracle.com> I see this problem and it?s almost certainly a bug in clang. Redoing the build (without a clean in between) fixes it for me. On Dec 21, 2013, at 2:52 AM, Mario Wolczko wrote: > I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. > > My mx/env contains: > > DEFAULT_VM=server > COMPILER_WARNINGS_FATAL=false > USE_CLANG=true > LFLAGS=-Xlinker -lstdc++ > USE_PRECOMPILED_HEADER=0 > > Here's the log: > > Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) > Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) > cd /Users/mario/Work/Eclipse/graal/make; \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > > python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared > Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) > Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) > mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd > cd /Users/mario/Work/Eclipse/graal/build/bsd; \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ > LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > > cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " > /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product > Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. > make[4]: Nothing to be done for `all'. > make[4]: Nothing to be done for `all'. > if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ > -a "x86" != "arm" \ > -a "x86" != "ppc" \ > -a "x86" != "zero" ] ; then \ > /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ > fi > make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. > echo "dtrace headers generated" > dtrace headers generated > Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp > Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp > Compiling ../generated/adfiles/ad_x86_64.cpp > Compiling ../generated/adfiles/ad_x86_64_clone.cpp > Compiling ../generated/adfiles/ad_x86_64_expand.cpp > Compiling ../generated/adfiles/ad_x86_64_format.cpp > Compiling ../generated/adfiles/ad_x86_64_gen.cpp > Compiling ../generated/adfiles/ad_x86_64_misc.cpp > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_misc.o] Error 254 > > make[4]: *** Waiting for unfinished jobs.... > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_gen.o] Error 254 > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_expand.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [abstractCompiler.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [accessFlags.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_clone.o] Error 254 > > clang: error: unable to execute command: Segmentation fault: 11 > > clang: error: clang frontend command failed due to signal (use -v to see invocation) > > Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) > > Target: x86_64-apple-darwin13.0.0 > > Thread model: posix > > clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. > > clang: note: diagnostic msg: > > ******************** > > > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > > Preprocessed source(s) and associated run script(s) are located at: > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp > > clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh > > clang: note: diagnostic msg: > > > > ******************** > > make[4]: *** [ad_x86_64_format.o] Error 254 > > make[3]: *** [the_vm] Error 2 > > make[2]: *** [product] Error 2 > > make[1]: *** [generic_build2] Error 2 > > make: *** [product] Error 2 > > > > > From chris at chrisseaton.com Sat Dec 21 03:59:53 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Sat, 21 Dec 2013 11:59:53 +0000 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Ruby has very extensive use of closures (they call them blocks), and the materialised frame is needed probably more often than not. This is used in benchmarks and it's very much on the fast path. I avoid materialising the frame where I know no local variables from the declaring scope are used, but apart from that I haven't been worrying about the performance impact yet. Your idea of making your own explicit up-values sounds interesting, but I wonder if that's working around Truffle rather than working with it. You will miss out on any performance improvements to MaterializedFrame in the future, and you'll have more complex code. In Ruby I also plan to inline all trivial methods immediately - but at the moment I'm only doing it for getters, setters and all core methods. One problem - if you inline straight away how do you stop the number of nodes blowing up beyond the limit? Christian Humer will be able to give a better explanation of @TypeCheck, @TypeCast and @ImplicitCast, but as I understand it @ImplicitCast tells the DSL that it can convert from one type to another via this method at any point to satisfy specialisation signatures. So I think you could implement the same thing using @TypeCheck and @TypeCast, but the @ImplicitCast is often simpler and clearer. In Ruby I use @ImplicitCast to convert between RubyFixnum and int. There is no difference between these two types - the RubyFixnum version is just so I can have a real object sometimes to simplify some other code. This tells the DSL whenever you see a RubyFixnum, feel free to convert it to an int to make things work. @ImplicitCast public int unboxFixnum(RubyFixnum value) { return value.getValue(); } I don't use @TypeCheck or @TypeCast anywhere in Ruby since I started using @ImplicitCast instead. Chris On 21 December 2013 07:55, Stefan Marr wrote: > Hi Wei: > > On 21 Dec 2013, at 01:45, Wei Zhang wrote: > > > Only functions that close over its declaration frame (closures) use > > PArguments#declarationFrame. This doesn't happen so often in my > > benchmarks. > > In most cases, zippy accesses local variable using VirtualFrames, > > which is optimized by Truffle/Graal. > > Well, closures are much more common in Smalltalk, I think. > > >> I do wonder, what is the typical granularity of a Python method? > >> At least in SOM, methods seem to be rather small. Perhaps a few AST > nodes on average. > >> Could that make a difference? > > > > Zippy inlines function calls when they become hot. Inlining helps > > performance a lot. > > I strongly recommend you to apply inlining in TruffleSOM if you haven?t > yet. > > TruffleSOM does inlining. I only see two difference when browsing your > code. > The first should actually be a benefit for TruffleSOM: I also inline > trivial methods immediately, i.e., if a method just contains a literal or > something similar, it is directly inlined without even a function call > overhead, only protected by a polymorphic inline cache check node. > The second difference I see is that you have a `prepareBodyNode()` > operation that rewrites local variable access nodes. Why is that necessary? > > > > >> Another detail I noticed is that you are using another strategy for > type handling in the type system. You use a combination of @TypeCheck and > @TypeCast, while I use @ImplicitCast. > >> What is the difference of these two approaches? > > > > I use @TypeCheck and @TypeCast to customize type checks and > > conversions in ZipPy. I just followed the SimpleLanguage examples in > > Truffle API. > > @ImplicitCast is new to me. I don't know how to use it, since there > > isn?t any related document or example. > > There is a tiny example in SimpleLanguage? That?s where I took it from. > But I have the feeling the generated code when using @TypeCheck and > @TypeCast looks quite a bit simpler. > > Thanks for the comments > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From java at stefan-marr.de Sat Dec 21 04:16:08 2013 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 21 Dec 2013 13:16:08 +0100 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: <5ED3E24A-CE8A-4D63-847E-5F93A0E05D55@stefan-marr.de> Hi Chris: On 21 Dec 2013, at 12:59, Chris Seaton wrote: > I avoid materialising the frame where I know no local variables from the declaring scope are used, but apart from that I haven't been worrying about the performance impact yet. Your idea of making your own explicit up-values sounds interesting, but I wonder if that's working around Truffle rather than working with it. You will miss out on any performance improvements to MaterializedFrame in the future, and you?ll have more complex code. I guess, I can revert it then and add materializing on demand instead. But, that?s not going to fix my performance problems. Which are, from what I have seen in SimpleLanguage and ZipPy kind of mysterious. > In Ruby I also plan to inline all trivial methods immediately - but at the moment I'm only doing it for getters, setters and all core methods. One problem - if you inline straight away how do you stop the number of nodes blowing up beyond the limit? I actually haven?t inlined getters and setters automatically yet. Just literals and reads of globals. So, there is no node explosion. > In Ruby I use @ImplicitCast to convert between RubyFixnum and int. There is no difference between these two types - the RubyFixnum version is just so I can have a real object sometimes to simplify some other code. This tells the DSL whenever you see a RubyFixnum, feel free to convert it to an int to make things work. > > @ImplicitCast > public int unboxFixnum(RubyFixnum value) { > return value.getValue(); > } That?s exactly what I am doing in TruffleSOM: @ImplicitCast public int castInteger(final SInteger i) { return i.getEmbeddedInteger(); } @ImplicitCast public BigInteger castBigInteger(final SBigInteger i) { return i.getEmbeddedBiginteger(); } @ImplicitCast public String castString(final SString str) { return str.getEmbeddedString(); } @ImplicitCast public double castDouble(final SDouble d) { return d.getEmbeddedDouble(); } Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From chris at chrisseaton.com Sat Dec 21 04:33:15 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Sat, 21 Dec 2013 12:33:15 +0000 Subject: ZipPy status update In-Reply-To: <5ED3E24A-CE8A-4D63-847E-5F93A0E05D55@stefan-marr.de> References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> <5ED3E24A-CE8A-4D63-847E-5F93A0E05D55@stefan-marr.de> Message-ID: What is the minimal benchmark where you think it's most obvious that Truffle isn't giving the performance that it should, and how do I run it? Preferably something numerically intensive, as I know that works well in ZipPy and RubyTruffle, but minimal is also important. Chris On 21 December 2013 12:16, Stefan Marr wrote: > Hi Chris: > > On 21 Dec 2013, at 12:59, Chris Seaton wrote: > > > I avoid materialising the frame where I know no local variables from the > declaring scope are used, but apart from that I haven't been worrying about > the performance impact yet. Your idea of making your own explicit up-values > sounds interesting, but I wonder if that's working around Truffle rather > than working with it. You will miss out on any performance improvements to > MaterializedFrame in the future, and you?ll have more complex code. > > I guess, I can revert it then and add materializing on demand instead. > But, that?s not going to fix my performance problems. Which are, from what > I have seen in SimpleLanguage and ZipPy kind of mysterious. > > > In Ruby I also plan to inline all trivial methods immediately - but at > the moment I'm only doing it for getters, setters and all core methods. One > problem - if you inline straight away how do you stop the number of nodes > blowing up beyond the limit? > > I actually haven?t inlined getters and setters automatically yet. Just > literals and reads of globals. So, there is no node explosion. > > > In Ruby I use @ImplicitCast to convert between RubyFixnum and int. There > is no difference between these two types - the RubyFixnum version is just > so I can have a real object sometimes to simplify some other code. This > tells the DSL whenever you see a RubyFixnum, feel free to convert it to an > int to make things work. > > > > @ImplicitCast > > public int unboxFixnum(RubyFixnum value) { > > return value.getValue(); > > } > > That?s exactly what I am doing in TruffleSOM: > > @ImplicitCast > public int castInteger(final SInteger i) { > return i.getEmbeddedInteger(); > } > > @ImplicitCast > public BigInteger castBigInteger(final SBigInteger i) { > return i.getEmbeddedBiginteger(); > } > > @ImplicitCast > public String castString(final SString str) { > return str.getEmbeddedString(); > } > > @ImplicitCast > public double castDouble(final SDouble d) { > return d.getEmbeddedDouble(); > } > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From christian.humer at gmail.com Sat Dec 21 05:53:42 2013 From: christian.humer at gmail.com (Christian Humer) Date: Sat, 21 Dec 2013 14:53:42 +0100 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Hi Stefan, The Problem you are dealing with is that there is too much logic in your Nodes. Truffle heavily relies on clean and short code that is produced from the truffle tree to be fast. So most of the corner cases should be specialized away and therefore should not be visible to the compiler. Use the compiled method size which is printed after each compilation as a rough metric for improvements in this area. I analysed the potential performance problems in your code by using -G:+TraceTruffleExpansion. If enabled the trace truffle expansion feature prints the actual tree of your methods that got expanded while truffle compilation. There is also another option -G:+TraceTruffleExpansionSource which adds additional line numbers and source locations. This enables to copy the output [1] into an eclipse stack trace console to easily navigate between the methods. I randomly took a method that got compiled when running [2] on the windows command line. I think it was method [3]. I list a number of of minor and major things that I've seen that should be optimized: 1) Major: (OptimizedCallTarget.java:214) Method.execute(Method.java:72) This method calls a method #messageSendExecution which contains a lot of control flow and allocations [4] . Speculate on the fact that all of this code is not required. It contains a while loop + a lot of exception catches. I think on the fast-path it could just call the body of the method. 2) Major: Another major problem here is that you are mutating the Arguments object using that FrameOnStackMarker [4]. Arguments should be usually immutable. This also applies to Arguments#upValues. I am not sure if all of this is a good idea performance wise.I think you can stick with it until the other problems are fixed. However if you are still not getting good performance we should revisit this thing. 3) Minor: You should also get rid of the array allocation in the Arguments constructor. Or at least use @ExplodeLoop on it. 4) Minor: (Method.java:72) Method.initializeFrame(Method.java:110) I am not sure, but this could be a potential problem as well. Graal may not be able to escape analyse the array of FrameSlots because graal does not see its allocation. I recommend you to rewrite this to an execute of an array of WriteLocalVariableNodes. For an array of @Children nodes graal does assume that also the contents of the array are constant and do not escape. 5) Minor: (SequenceNode.java:41) UnarySendNode.executeGeneric(UnarySendNode.java:43) In UnarySendNode, no need to mark your @Children also @CompilationFinal. In general @CompilationFinal only helps for non final fields which are not marked as @Child or @Children but should be considered constant for the compiler. Please remember to call CompilerDirectives.transferToInterpreterAndInvalidate before writing to a @CompilationFinal field from a compiled path. 6) Major (UnarySendNode.java) UnaryInlinedMethod.executeEvaluated(Method.java:228) Same Problems as 1 and 4 is duplicated for all inlined method calls. This code is repeated 5 times over the hole compiled method. 7) Minor (KeywordSendNode.java:54) ArgumentEvaluationNode.executeArray(ArgumentEvaluationNode.java:31) Do not use null values. For Nil you should use a singleton instead of null. Then you can just remove the initial check: if (arguments == null || arguments.length == 0) { return null; } completely. It does not matter too much if you allocate an empty Object array. It gets escape analysed anyway. 8) Major (SequenceNode.java:41) BinarySendNode.executeGeneric(BinarySendNode.java:56) The implementation of WhileTrueMessageSBlockNode (I think of all While nodes) does not inline the call to the While body block, which gives a serious performance penalty of course. Instead of directly calling the block you should use a message send as child node which invokes the while block. This way the call/send can be inlined. 9) Minor (SequenceNode.java:41) SelfReadNode.executeGeneric(SelfReadNode.java:12) ContextualNode#determineOuterSelf and ContextualNode#determineOuterArguments should use @ExplodeLoop. Despite the open issues, I am confident that we can get this thing fast ;-) Feel free to ask further questions on how to fix these issues. Lets do another review iteration after you have fixed these issues. I will write a separate email to the list regarding @ImplicitCasts. Cheers! [1] expansion tree OptimizedCallTarget.executeHelper(OptimizedCallTarget.java:213) (OptimizedCallTarget.java:214) Method.execute(Method.java:72) (Method.java:72) Method.initializeFrame(Method.java:110) (Method.java:73) SequenceNode.executeGeneric(SequenceNode.java:38) (SequenceNode.java:41) UnarySendNode.executeGeneric(UnarySendNode.java:43) (UnarySendNode.java:43) SelfReadNode.executeGeneric(SelfReadNode.java:12) (UnarySendNode.java) UnaryInlinedMethod.executeEvaluated(Method.java:228) (Method.java:228) SequenceNode.executeGeneric(SequenceNode.java:38) (SequenceNode.java:41) LocalVariableWriteIntNode.executeGeneric(LocalVariableNodeFactory.java:621) (LocalVariableNodeFactory.java:623) IntegerLiteralDefaultNode.executeInteger(IntegerLiteralNodeFactory.java:81) (SequenceNode.java:41) KeywordSendNode.executeGeneric(KeywordSendNode.java:53) (KeywordSendNode.java:53) UnarySendNode.executeGeneric(UnarySendNode.java:43) (UnarySendNode.java:43) LocalVariableReadIntNode.executeGeneric(LocalVariableNodeFactory.java:190) (UnarySendNode.java) UnaryInlinedMethod.executeEvaluated(Method.java:228) (Method.java:228) BinarySendNode.executeGeneric(BinarySendNode.java:56) (BinarySendNode.java:56) IntegerLiteralDefaultNode.executeGeneric(IntegerLiteralNodeFactory.java:88) (BinarySendNode.java:57) SelfReadNode.executeGeneric(SelfReadNode.java:12) (BinarySendNode.java:58) SubtractionPrimIntNode.executeEvaluated(SubtractionPrimFactory.java:696) (BinarySendNode.java) UninitializedSendNode.executeEvaluated(BinarySendNode.java:116) (Method.java:230) UnaryInlinedMethod.initializeFrame(Method.java:215) (UnarySendNode.java) UninitializedSendNode.executeEvaluated(UnarySendNode.java:98) (KeywordSendNode.java:54) ArgumentEvaluationNode.executeArray(ArgumentEvaluationNode.java:31) (ArgumentEvaluationNode.java:38) LocalVariableReadIntNode.executeGeneric(LocalVariableNodeFactory.java:190) (ArgumentEvaluationNode.java:38) IntegerLiteralDefaultNode.executeGeneric(IntegerLiteralNodeFactory.java:88) (ArgumentEvaluationNode.java:38) BlockNode.executeGeneric(BlockNode.java:1) (BlockNode.java) Universe.newBlock(Universe.java:418) (KeywordSendNode.java:55) KeywordInlinedMethod.executeEvaluated(Method.java:502) (Method.java:503) SequenceNode.executeGeneric(SequenceNode.java:38) (SequenceNode.java:41) NonLocalVariableWriteNode.executeGeneric(NonLocalVariableNode.java:39) (NonLocalVariableNode.java:39) SelfReadNode.executeGeneric(SelfReadNode.java:12) (SequenceNode.java:41) BinarySendNode.executeGeneric(BinarySendNode.java:56) (BinarySendNode.java:56) BlockNode.executeGeneric(BlockNode.java:1) (BlockNode.java) Universe.newBlock(Universe.java:418) (BinarySendNode.java:57) BlockNode.executeGeneric(BlockNode.java:1) (BlockNode.java) Universe.newBlock(Universe.java:418) (BinarySendNode.java:58) Universe.newBlock(Universe.java:418) (BinarySendNode.java:58) Universe.newBlock(Universe.java:418) (BinarySendNode.java:58) Universe.newBlock(Universe.java:418) (SequenceNode.java:41) SelfReadNode.executeGeneric(SelfReadNode.java:12) (Method.java:506) KeywordInlinedMethod.initializeFrame(Method.java:482) (KeywordSendNode.java) UninitializedSendNode.executeEvaluated(KeywordSendNode.java:113) (SequenceNode.java:41) SelfReadNode.executeGeneric(SelfReadNode.java:12) (Method.java:230) UnaryInlinedMethod.initializeFrame(Method.java:215) (UnarySendNode.java) UninitializedSendNode.executeEvaluated(UnarySendNode.java:98) (SequenceNode.java:41) NonLocalVariableWriteNode.executeGeneric(NonLocalVariableNode.java:39) (NonLocalVariableNode.java:39) BinarySendNode.executeGeneric(BinarySendNode.java:56) (BinarySendNode.java:56) NonLocalVariableReadNode.executeGeneric(NonLocalVariableNode.java:23) (BinarySendNode.java:57) IntegerLiteralDefaultNode.executeGeneric(IntegerLiteralNodeFactory.java:88) (BinarySendNode.java:58) AdditionPrimIntNode.executeEvaluated(AdditionPrimFactory.java:695) (BinarySendNode.java) UninitializedSendNode.executeEvaluated(BinarySendNode.java:116) [2] mx --vm server vm -G:+TraceTruffleExpansion -G:+TraceTruffleExpansionSource -Xbootclasspath/a:../TruffleSOM/build/classes;../TruffleSOM/libs/com.oracle.truffle.api.jar;../TruffleSOM/libs/com.oracle.truffle.api.dsl.jar som.vm.Universe -cp ../TruffleSOM/core-lib/Smalltalk ../TruffleSOM/core-lib/Examples/Benchmarks/BenchmarkHarness.som IntegerLoop 1 2 2000 [3] innerBenchmarkLoop = ( | i | i := 0. [ i < innerIterations ] whileTrue: [ self benchmark. i := i + 1. ]. ) [4] protected static Object messageSendExecution(final VirtualFrame frame, final ExpressionNode expr) { FrameOnStackMarker marker = Arguments.get(frame).getFrameOnStackMarker(); Object result; boolean restart; do { restart = false; try { result = expr.executeGeneric(frame); } catch (ReturnException e) { if (!e.reachedTarget(marker)) { marker.frameNoLongerOnStack(); throw e; } else { result = e.result(); } } catch (RestartLoopException e) { restart = true; result = null; } } while (restart); marker.frameNoLongerOnStack(); return result; } - Christian Humer On Sat, Dec 21, 2013 at 12:59 PM, Chris Seaton wrote: > Ruby has very extensive use of closures (they call them blocks), and the > materialised frame is needed probably more often than not. This is used in > benchmarks and it's very much on the fast path. > > I avoid materialising the frame where I know no local variables from the > declaring scope are used, but apart from that I haven't been worrying about > the performance impact yet. Your idea of making your own explicit up-values > sounds interesting, but I wonder if that's working around Truffle rather > than working with it. You will miss out on any performance improvements to > MaterializedFrame in the future, and you'll have more complex code. > > In Ruby I also plan to inline all trivial methods immediately - but at the > moment I'm only doing it for getters, setters and all core methods. One > problem - if you inline straight away how do you stop the number of nodes > blowing up beyond the limit? > > Christian Humer will be able to give a better explanation of @TypeCheck, > @TypeCast and @ImplicitCast, but as I understand it @ImplicitCast tells the > DSL that it can convert from one type to another via this method at any > point to satisfy specialisation signatures. So I think you could implement > the same thing using @TypeCheck and @TypeCast, but the @ImplicitCast is > often simpler and clearer. > > In Ruby I use @ImplicitCast to convert between RubyFixnum and int. There is > no difference between these two types - the RubyFixnum version is just so I > can have a real object sometimes to simplify some other code. This tells > the DSL whenever you see a RubyFixnum, feel free to convert it to an int to > make things work. > > @ImplicitCast > > public int unboxFixnum(RubyFixnum value) { > > return value.getValue(); > > } > > I don't use @TypeCheck or @TypeCast anywhere in Ruby since I started using > @ImplicitCast instead. > > Chris > > > On 21 December 2013 07:55, Stefan Marr wrote: > > > Hi Wei: > > > > On 21 Dec 2013, at 01:45, Wei Zhang wrote: > > > > > Only functions that close over its declaration frame (closures) use > > > PArguments#declarationFrame. This doesn't happen so often in my > > > benchmarks. > > > In most cases, zippy accesses local variable using VirtualFrames, > > > which is optimized by Truffle/Graal. > > > > Well, closures are much more common in Smalltalk, I think. > > > > >> I do wonder, what is the typical granularity of a Python method? > > >> At least in SOM, methods seem to be rather small. Perhaps a few AST > > nodes on average. > > >> Could that make a difference? > > > > > > Zippy inlines function calls when they become hot. Inlining helps > > > performance a lot. > > > I strongly recommend you to apply inlining in TruffleSOM if you haven?t > > yet. > > > > TruffleSOM does inlining. I only see two difference when browsing your > > code. > > The first should actually be a benefit for TruffleSOM: I also inline > > trivial methods immediately, i.e., if a method just contains a literal > or > > something similar, it is directly inlined without even a function call > > overhead, only protected by a polymorphic inline cache check node. > > The second difference I see is that you have a `prepareBodyNode()` > > operation that rewrites local variable access nodes. Why is that > necessary? > > > > > > > >> Another detail I noticed is that you are using another strategy for > > type handling in the type system. You use a combination of @TypeCheck and > > @TypeCast, while I use @ImplicitCast. > > >> What is the difference of these two approaches? > > > > > > I use @TypeCheck and @TypeCast to customize type checks and > > > conversions in ZipPy. I just followed the SimpleLanguage examples in > > > Truffle API. > > > @ImplicitCast is new to me. I don't know how to use it, since there > > > isn?t any related document or example. > > > > There is a tiny example in SimpleLanguage? That?s where I took it from. > > But I have the feeling the generated code when using @TypeCheck and > > @TypeCast looks quite a bit simpler. > > > > Thanks for the comments > > Stefan > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > From java at stefan-marr.de Sat Dec 21 06:35:36 2013 From: java at stefan-marr.de (Stefan Marr) Date: Sat, 21 Dec 2013 15:35:36 +0100 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> <5ED3E24A-CE8A-4D63-847E-5F93A0E05D55@stefan-marr.de> Message-ID: Hi Chris: On 21 Dec 2013, at 13:33, Chris Seaton wrote: > What is the minimal benchmark where you think it's most obvious that Truffle isn't giving the performance that it should, and how do I run it? Preferably something numerically intensive, as I know that works well in ZipPy and RubyTruffle, but minimal is also important. Numerically intensive and minimal? Not sure what you are thinking of exactly. But the simple WhileLoop benchmark in Examples/Benchmarks is I think my first focus. Will try to go though Christian?s extensive list of comments. Thanks a lot Christian! With a properly set up graal.sh (in the TruffleSOM repo), it can be executed with: ./graal.sh -cp `pwd`/Smalltalk `pwd`/Examples/Benchmarks/BenchmarkHarness.som WhileLoop 1 3 3000 But note, there is still a SOM benchmark harness. And the standard library gets loaded partially as well. For more computational intensive benchmarks, there is Fannkuch perhaps, or the Queens benchmark? Not sure what you got in mind concretely, but perhaps I can just port something that you think would be useful to guide my work? In general, the benchmarks can be execute by either just calling their script, or using the harness which allows to define the number of measurements, the number of warmup runs ahead, and the number of inner iterations each benchmark is executed. In the command line above, represented in order by 1, 3, and 3000. To get a proper TruffleSOM checkout, please checkout the submodule with the SOM standard library in the proper version. For instance this does the trick (note the `--recursive): git clone --recursive https://github.com/smarr/TruffleSOM.git Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From chris at chrisseaton.com Sat Dec 21 06:43:16 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Sat, 21 Dec 2013 14:43:16 +0000 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> <5ED3E24A-CE8A-4D63-847E-5F93A0E05D55@stefan-marr.de> Message-ID: Christian has covered all the points I was going to look for, but I was going to suggest that if you get something like fannkuch running we can make some general comparisons. Smalltalk and Ruby have similar properties that mean they probably look pretty similar in their ASTs, such as closures for control structures and operators being method calls, so I can relate what I know about using Truffle for those kinds of problems to Smalltalk. Chris On 21 December 2013 14:35, Stefan Marr wrote: > Hi Chris: > > On 21 Dec 2013, at 13:33, Chris Seaton wrote: > > > What is the minimal benchmark where you think it's most obvious that > Truffle isn't giving the performance that it should, and how do I run it? > Preferably something numerically intensive, as I know that works well in > ZipPy and RubyTruffle, but minimal is also important. > > Numerically intensive and minimal? > Not sure what you are thinking of exactly. But the simple WhileLoop > benchmark in Examples/Benchmarks is I think my first focus. Will try to go > though Christian?s extensive list of comments. Thanks a lot Christian! > > With a properly set up graal.sh (in the TruffleSOM repo), it can be > executed with: > ./graal.sh -cp `pwd`/Smalltalk > `pwd`/Examples/Benchmarks/BenchmarkHarness.som WhileLoop 1 3 3000 > > But note, there is still a SOM benchmark harness. And the standard library > gets loaded partially as well. > > For more computational intensive benchmarks, there is Fannkuch perhaps, or > the Queens benchmark? > Not sure what you got in mind concretely, but perhaps I can just port > something that you think would be useful to guide my work? > > In general, the benchmarks can be execute by either just calling their > script, or using the harness which allows to define the number of > measurements, the number of warmup runs ahead, and the number of inner > iterations each benchmark is executed. In the command line above, > represented in order by 1, 3, and 3000. > > To get a proper TruffleSOM checkout, please checkout the submodule with > the SOM standard library in the proper version. For instance this does the > trick (note the `--recursive): git clone --recursive > https://github.com/smarr/TruffleSOM.git > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From doug.simon at oracle.com Sat Dec 21 06:57:22 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 21 Dec 2013 15:57:22 +0100 Subject: graalCodeInstaller questions, recording scopes, etc. In-Reply-To: References: Message-ID: <63D4172D-B61A-4314-BEA0-FB2AD4258BAF@oracle.com> On Dec 20, 2013, at 3:41 PM, Deneau, Tom wrote: > Closing the loop again, for my original questions, adding answers > below that were relayed in the Skype call on Thursday... > >> -----Original Message----- >> From: Deneau, Tom >> Sent: Monday, December 16, 2013 3:58 PM >> To: graal-dev at openjdk.java.net >> Subject: graalCodeInstaller questions, recording scopes, etc. >> >> Wanted to run a sketch of our plans by the rest of the graal team and >> get some advice... >> >> When there are situations we cannot handle on the HSAIL backend, we want >> to deoptimize and handle them in the interpreter. Our thoughts were >> that at codeInstall time, we could record the various infopoints in the >> compilationResult and then the graalCodeInstaller would then record >> these in some way in the nmethod or in some structure that we could >> access at runtime. Then at runtime, if a workitem requests a deopt, it >> would save its HSAIL state, including all the appropriate HSAIL >> registers in a place that the host side could access. >> >> If the JVM code that invokes the kernel sees that one or more workitems >> have requested a deopt, for each one we could >> >> * map the HSAIL "PC" back to the appropriate infopoint >> >> * use the infopoint and the saved HSAIL registers to construct the, >> host-based interpreter frames >> >> * and then let things continue in the interpreter. >> >> Some questions: >> >> * What reason should we use for the InfopointReason? In >> graalCodeInstaller.cpp, it seems that some types get "recorded" >> in the debug_recorder via site_Safepoint or site_Call, while >> others like InfopointReason::LINE_NUMBER do not. I am assuming >> we should "record" ours but am not sure how this all plays >> together. Can we map back to an infopoint that has not been >> recorded? >> > > Looking back we didn't really answer this question. > I know now we do need to map to some Infopoint type that does get recorded in ScopeDesc. > The AMD64 backend for DeoptimizeNode issues a InfopointReason::CALL which > is a side effect of making a Direct Foreign call. > > On the HSAIL side, we are not really making a foreign call and I am unsure of the > full semantics of the other types. As an experiment I tried InfopointReason.IMPLICIT_EXCEPTION > which does get recorded in the ScopeDesc thru site_Safepoint. > But again, not sure if that is the recommendation. What you need is for deoptimization to record in a buffer all the values described by a ScopeDesc that will be accessible to the subsystem that inspects the deoptimization state (ie. where the ScopeDesc is used). Deopt points in host compiled code will either be safepoints (e.g. AMD64HotSpotSafepoint) or calls. On HSAIL, you need to expand on the concept implemented in Eric?s webrev[1] where code explicitly stores state to a memory block (i.e. %_deoptInfo). This state will be at least the HSAIL register values. I don?t know what memory is used for the stack in HSAIL, but if it is not accessible by the host or will not be live when the host needs to access the debug info, then the values on the stack also need to be written to the deopt info block. In addition, the identifier of the relevant ScopeDesc will also be written to the deopt info block. For host execution, this is not needed since the identifier is the program counter (pc) which is always available to the debug info consumer. One thing I?m not sure about is how to handle safepoints in GPU code. Can HSAIL/PTX code use signals? If not, we?ll probably need some global address that GPU will actively poll at safepoints. If this poll determines safepoints are ?triggered?, a deoptimization path will be taken, doing all the frame state saving mentioned above. This may be less than ideal as it means any time safepoints are triggered (e.g. for a garbage collection or for a biased lock revocation), all running GPU code will be deoptimized. Or is there some mechanism for continuing GPU code at safepoints? >> * Our infopoints have byteCodePositions. The ones that get >> "recorded" go thru record_scope which has all sorts of >> host-specific checking on the scope info. For instance, >> get_hotspot_value will compare a register # with >> RegisterImpl::number_of_registers (which refers to the host) and >> if it is, assert that the type is FLOAT or DOUBLE. None of this >> holds with HSAIL registers. What is the best way to resolve >> this? >> > > This issue will be handled by the virtualization of some of the calls > in graalCodeInstaller that Doug will be implementing. -Doug [1] http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/webrev/ From christian.humer at gmail.com Sat Dec 21 08:49:11 2013 From: christian.humer at gmail.com (Christian Humer) Date: Sat, 21 Dec 2013 17:49:11 +0100 Subject: Implict Casts in Truffle DSL Message-ID: Hey folks, There were some questions floating around about the ImplicitCast feature in Truffle DSL. So here is a short description of what it does: The idea behind ImplicitCasts is that it tries to reduce the number of specializations required to define an operation. Imagine you got arithmetics with tree different types. That could be int, double and complex. However in our guest language we have several different representations of the same type for optimization reasons. For instance an int could be represented as Java int, IntSequence, IntVector or even as LogicalToIntVectorClosure (this example is borrowed from R). This makes a lot of combinations of types in binary operation to fully specialize itself. So assuming that double and complex have the same number of different representations and their number may even rise, the number of specializations will explode at some point in time. The solution for this problem was to introduce a new concept to the DSL, namely @ImplicitCast. The idea behind is that you can define casts that are inserted before a specialization is called on demand. So assume we have defined the specializations for a binary operation which fully specializes for the types int and IntVector. Without implicit casts you would have to define these four specializations. @Specialization int doOp(int left, int right) {...} @Specialization int doOp(IntVector left, int right) {...} @Specialization int doOp(int left, IntVector right) {...} @Specialization int doOp(IntVector left, IntVector right) {...} However if we assume that all four specializations would want to specialize to basically the same code we can use implicit casts to declare this more elegantly. For this we introduce a new interface called AbstractIntVector which is the base interface for IntVector, IntSequence etc. and we have to define some implicit casts in the type system like this: @ImplicitCast public AbstractIntVector toAbstractIntVector(int value) { return DataFactory.createIntVectorFromScalar(value); } @ImplicitCast public AbstractIntVector toAbstractIntVector(IntVector vector) { return vector; } @Specialization int doOp(AbstractIntVector left, AbstractIntVector right) {...} Now we can just define one specialization and we get the same specialization combinations as in the first example. Please be aware that this is not completely the same thing as before since the implicit cast method toAbstractIntVector is invoked prior to the invocation of the specialization. However Graal/Truffle is pretty good in removing unnecessary allocations for boxing if it sees the position of boxing as well as the position of the unboxing. You may even combine both the upper with the lower approach, like this: @Specialization int doOp(int left, int right) {...} @Specialization int doOp(AbstractIntVector left, AbstractIntVector right) {...} In this case you can provide a more optimized version for (int, int) but not having to specialize all the other combinations. Implicit casts are even more useful if the number of representations of the same logical type is high. This enables you to keep the number of specializations in binary nodes under control without breaking your fingers. Please note: On the contrary to custom @TypeCheck and @TypeCast methods, @ImplicitCasts are inserted on-demand. This means that they do not introduce additional overhead in compiled code as custom @TypeCheck or @TypeCast methods would. Feel free to ask further questions. - Christian Humer From mario.wolczko at oracle.com Sat Dec 21 17:56:32 2013 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Sat, 21 Dec 2013 17:56:32 -0800 Subject: Graal on Mavericks In-Reply-To: <7CC66D91-A576-4F01-8FA3-3BE2E9E2CE6F@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> <7CC66D91-A576-4F01-8FA3-3BE2E9E2CE6F@oracle.com> Message-ID: <5BF3FD31-0C07-4FD5-B7B5-6ED4FD69216F@oracle.com> No such luck. On Dec 21, 2013, at 2:15 AM, Doug Simon wrote: > I see this problem and it?s almost certainly a bug in clang. Redoing the build (without a clean in between) fixes it for me. > > On Dec 21, 2013, at 2:52 AM, Mario Wolczko wrote: > >> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >> >> My mx/env contains: >> >> DEFAULT_VM=server >> COMPILER_WARNINGS_FATAL=false >> USE_CLANG=true >> LFLAGS=-Xlinker -lstdc++ >> USE_PRECOMPILED_HEADER=0 >> >> Here's the log: >> >> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >> cd /Users/mario/Work/Eclipse/graal/make; \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> >> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> >> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >> make[4]: Nothing to be done for `all'. >> make[4]: Nothing to be done for `all'. >> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >> -a "x86" != "arm" \ >> -a "x86" != "ppc" \ >> -a "x86" != "zero" ] ; then \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >> fi >> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >> echo "dtrace headers generated" >> dtrace headers generated >> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >> Compiling ../generated/adfiles/ad_x86_64.cpp >> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >> Compiling ../generated/adfiles/ad_x86_64_format.cpp >> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_misc.o] Error 254 >> >> make[4]: *** Waiting for unfinished jobs.... >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_gen.o] Error 254 >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_expand.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [abstractCompiler.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [accessFlags.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_clone.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_format.o] Error 254 >> >> make[3]: *** [the_vm] Error 2 >> >> make[2]: *** [product] Error 2 >> >> make[1]: *** [generic_build2] Error 2 >> >> make: *** [product] Error 2 >> >> >> >> >> > From mario.wolczko at oracle.com Sat Dec 21 17:57:50 2013 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Sat, 21 Dec 2013 17:57:50 -0800 Subject: Graal on Mavericks In-Reply-To: References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: Given that this is a crash in the C++ compiler that would be a very surprising fix... On Dec 20, 2013, at 11:35 PM, Stefan Marr wrote: > The last issue I saw on Mavericks was caused by an outdated JDK version being used. After updating to the latest version of Java 7, it went away. > > Best regards > Stefan > > On 21 Dec 2013, at 03:21, Charles Oliver Nutter wrote: > >> I built graal today on mavericks and it went well, but I don't think I am >> on updated xcode. >> >> - Charlie (mobile) >> On Dec 20, 2013 8:08 PM, "Mario Wolczko" wrote: >> >>> I'm getting my build environment going again since upgrading to Mavericks. >>> I'm getting a clang crash while compiling HotSpot - anyone seen this and >>> know the fix? This is while building the graal version associated with >>> fast_r. >>> >>> My mx/env contains: >>> >>> DEFAULT_VM=server >>> COMPILER_WARNINGS_FATAL=false >>> USE_CLANG=true >>> LFLAGS=-Xlinker -lstdc++ >>> USE_PRECOMPILED_HEADER=0 >>> >>> Here's the log: >>> >>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance >>> level 1.8 required) >>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance >>> level 1.8 required) >>> cd /Users/mario/Work/Eclipse/graal/make; \ >>> /Applications/Xcode.app/Contents/Developer/usr/bin/make >>> BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 >>> BUILD_FLAVOR=product VM_TARGET=product generic_build2 >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> >>> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build >>> --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance >>> level 1.8 required) >>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance >>> level 1.8 required) >>> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >>> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f >>> /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >>> LP64=1 MACOSX_UNIVERSAL=true >>> BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home >>> OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd >>> GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= >>> HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" >>> HOTSPOT_BUILD_VERSION=internal product >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> >>> cd bsd_amd64_compiler2/product && >>> /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >>> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >>> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >>> make[4]: Nothing to be done for `all'. >>> make[4]: Nothing to be done for `all'. >>> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >>> -a "x86" != "arm" \ >>> -a "x86" != "ppc" \ >>> -a "x86" != "zero" ] ; then \ >>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f >>> sa.make >>> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; >>> \ >>> fi >>> make[5]: >>> `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' >>> is up to date. >>> echo "dtrace headers generated" >>> dtrace headers generated >>> Compiling >>> /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>> Compiling >>> /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >>> Compiling ../generated/adfiles/ad_x86_64.cpp >>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see >>> invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to >>> http://developer.apple.com/bugreporter/ and include the crash backtrace, >>> preprocessed source, and associated run script. >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see >>> invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to >>> http://developer.apple.com/bugreporter/ and include the crash backtrace, >>> preprocessed source, and associated run script. >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see >>> invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to >>> http://developer.apple.com/bugreporter/ and include the crash backtrace, >>> preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_misc.o] Error 254 >>> >>> make[4]: *** Waiting for unfinished jobs.... >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_gen.o] Error 254 >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see >>> invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to >>> http://developer.apple.com/bugreporter/ and include the crash backtrace, >>> preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_expand.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see >>> invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to >>> http://developer.apple.com/bugreporter/ and include the crash backtrace, >>> preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [abstractCompiler.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see >>> invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to >>> http://developer.apple.com/bugreporter/ and include the crash backtrace, >>> preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [accessFlags.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see >>> invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to >>> http://developer.apple.com/bugreporter/ and include the crash backtrace, >>> preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_clone.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see >>> invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to >>> http://developer.apple.com/bugreporter/ and include the crash backtrace, >>> preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >>> >>> clang: note: diagnostic msg: >>> /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_format.o] Error 254 >>> >>> make[3]: *** [the_vm] Error 2 >>> >>> make[2]: *** [product] Error 2 >>> >>> make[1]: *** [generic_build2] Error 2 >>> >>> make: *** [product] Error 2 >>> >>> >>> >>> >>> >>> > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > From doug.simon at oracle.com Sat Dec 21 18:00:45 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 22 Dec 2013 02:00:45 +0000 Subject: hg: graal/graal: 126 new changesets Message-ID: <20131222020646.7139A62E73@hg.openjdk.java.net> Changeset: e3b0608d6ab8 Author: Doug Simon Date: 2013-12-16 10:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e3b0608d6ab8 fixed pylint warnings ! mx/mx_graal.py Changeset: b1712d10c8ef Author: Doug Simon Date: 2013-12-16 13:23 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b1712d10c8ef moved loads of constants out of loops ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/CommonedConstantsTest.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 3ce69f7364a7 Author: Erik Eckstein Date: 2013-12-16 17:18 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3ce69f7364a7 temporarily disabled redundant move elimination because of a problem in specjvm2008 ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java Changeset: 2c3b59f34619 Author: Tom Rodriguez Date: 2013-12-16 09:31 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2c3b59f34619 add CPUFeature EnumSet to target description with appropriate asserts ! graal/com.oracle.graal.amd64/src/com/oracle/graal/amd64/AMD64.java ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Changeset: 7345e9672dc3 Author: Tom Rodriguez Date: 2013-12-16 10:22 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/7345e9672dc3 refactor computation of architecture features ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotBackendFactory.java Changeset: cd22c6bb4a35 Author: Tom Rodriguez Date: 2013-12-16 12:10 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/cd22c6bb4a35 use test instead of mov for poll ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotSafepointOp.java Changeset: 0e5c4f9fa9a5 Author: Doug Simon Date: 2013-12-16 23:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0e5c4f9fa9a5 enabled non-hosted CompileTheWorld execution with complete bootstrapping and the ability to override compilation options separately for CTW compilations ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompileTheWorldTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! src/share/vm/graal/graalCompiler.cpp Changeset: 5a7508f1a7ff Author: Matthias Grimmer Date: 2013-12-17 10:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5a7508f1a7ff Fix LIR assertion (distance between an operation with an exception edge and the last introduction of a LIR block) ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/LIR.java Changeset: e3f15a21b7a1 Author: Gilles Duboscq Date: 2013-12-13 19:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e3f15a21b7a1 Cosmetic javadoc changes to StateSplit and NodeWithState ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/StateSplit.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/spi/NodeWithState.java Changeset: 47d184ba15b6 Author: Gilles Duboscq Date: 2013-12-17 11:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/47d184ba15b6 HotSpotResolvedJavaField already implements LocationIdentity through ResolvedJavaField ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java Changeset: dad7737243c6 Author: Gilles Duboscq Date: 2013-12-17 11:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/dad7737243c6 Canonicalize CompareAndSwapNode to a more precise location identity than ANY if possible ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java Changeset: e1a50eac0eac Author: Gilles Duboscq Date: 2013-12-17 14:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e1a50eac0eac Add a version number for the mxtool and support for requesting a minimum mx version in a suite ! mx/projects ! mxtool/mx.py Changeset: 136df94b5aa8 Author: Christian Humer Date: 2013-12-17 15:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/136df94b5aa8 SL: updated outdated implementation of write local variable nodes in SL. ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/nodes/WriteLocalNode.java Changeset: cf7b5b507541 Author: Christian Humer Date: 2013-12-17 15:44 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cf7b5b507541 Merge. Changeset: 5a6c617a66ac Author: Doug Simon Date: 2013-12-17 16:41 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5a6c617a66ac added -G:+CompileTheWorldVerbose and -G:CompileTheWorldIterations options ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 9fd85def8368 Author: Doug Simon Date: 2013-12-17 16:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9fd85def8368 made CompileTheWorld ignore profiling info ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java Changeset: 5c891b2983c5 Author: Doug Simon Date: 2013-12-17 16:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5c891b2983c5 improved comment explaining why CompileTheWorld is set to false during bootstrapping ! src/share/vm/graal/graalCompiler.cpp Changeset: 5a4293f24642 Author: Doug Simon Date: 2013-12-17 16:45 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5a4293f24642 added -G:PrintCompRate option for periodically printing out the current compilation rate ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: bfc5acea3c12 Author: Doug Simon Date: 2013-12-17 17:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bfc5acea3c12 consolidated mechanism for overriding options in CompileTheWorld ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/CompileTheWorldTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 1480cfe97462 Author: Doug Simon Date: 2013-12-17 18:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1480cfe97462 CTWCompilationTask should not be removed from compilation queue ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 413040ab993e Author: Bernhard Urban Date: 2013-12-17 16:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/413040ab993e remove some usages of HashSet ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.java/src/com/oracle/graal/java/BciBlockMapping.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/TailDuplicationPhase.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/GraphEffectList.java Changeset: 79298b99df02 Author: Bernhard Urban Date: 2013-12-17 16:09 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/79298b99df02 IncrementalCanonicalizer: use HashSetNodeChangeListener ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/IncrementalCanonicalizerPhase.java Changeset: c3ecad078114 Author: Bernhard Urban Date: 2013-12-17 16:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c3ecad078114 utils: introduce ArraySet. use it instead of HashSet at some places ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/graph/ComputeProbabilityClosure.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java + graal/com.oracle.graal.phases/src/com/oracle/graal/phases/util/ArraySet.java ! graal/com.oracle.graal.virtual/src/com/oracle/graal/virtual/phases/ea/PartialEscapeClosure.java Changeset: 3e67710a6d08 Author: Bernhard Urban Date: 2013-12-17 21:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/3e67710a6d08 SchedulePhase: remove old memory aware scheudling ! graal/com.oracle.graal.compiler.test/src/com/oracle/graal/compiler/test/MemoryScheduleTest.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/schedule/SchedulePhase.java Changeset: 4db09b7304da Author: Doug Simon Date: 2013-12-17 22:37 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4db09b7304da read DontCompileHugeMethods and HugeMethodLimit from VM ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Changeset: af10ee69a8ac Author: twisti Date: 2013-12-17 17:58 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/af10ee69a8ac fixed JDK-7079626: x64 emits unnecessary REX prefix ! graal/com.oracle.graal.asm.amd64/src/com/oracle/graal/asm/amd64/AMD64Assembler.java Changeset: 430c9f08728d Author: twisti Date: 2013-12-17 19:09 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/430c9f08728d moved most CompilerToVM.getUniqueConcreteMethod logic up to Java and replace getUniqueConcreteMethod with findUniqueConcreteMethod ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaMethod.java ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: ad187607b784 Author: twisti Date: 2013-12-17 21:25 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ad187607b784 make CompilerToVM.resolveMethod return a metadata method instead of a Java type ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: e8c4a6ea3f77 Author: twisti Date: 2013-12-17 20:58 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e8c4a6ea3f77 cleaned up VMToCompiler.createResolvedJavaType ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompiler.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/graalVMToCompiler.cpp ! src/share/vm/graal/graalVMToCompiler.hpp Changeset: 24ae4e7ecf03 Author: Erik Eckstein Date: 2013-12-18 08:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/24ae4e7ecf03 fixed wrong redundant move elimination after loop safepoints, re-enabled redundant move elimination ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java Changeset: 40530019af02 Author: Erik Eckstein Date: 2013-12-18 09:02 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/40530019af02 enable rematerialization of constants in LinearScan, including a bug fix ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/gen/LIRGenerator.java Changeset: 16d99e9d77ad Author: Bernhard Urban Date: 2013-12-18 11:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/16d99e9d77ad Options: rename flag (AOTCompilation -> ImmutableCode) ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/HighTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/LowTier.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/phases/MidTier.java ! graal/com.oracle.graal.hotspot.test/src/com/oracle/graal/hotspot/test/AheadOfTimeCompilationTest.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaField.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotSuitesProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/ObjectGetClassNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java ! graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/InliningUtil.java ! graal/com.oracle.graal.phases/src/com/oracle/graal/phases/GraalOptions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/BoxingSnippets.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/CompositeValueClassSubstitutions.java ! graal/com.oracle.graal.replacements/src/com/oracle/graal/replacements/NodeClassSubstitutions.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/PartialEvaluator.java ! graal/com.oracle.graal.truffle/src/com/oracle/graal/truffle/TruffleCache.java ! mx/mx_graal.py Changeset: 6a4160635fef Author: Gilles Duboscq Date: 2013-12-18 11:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6a4160635fef Backed out changeset: dad7737243c6 ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/CompareAndSwapNode.java Changeset: 55be5aac78e2 Author: cl Date: 2013-11-21 09:22 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/55be5aac78e2 Added tag jdk8-b117 for changeset f573d00213b7 ! .hgtags Changeset: 854a42db7069 Author: amurillo Date: 2013-11-15 07:58 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/854a42db7069 8028444: new hotspot build - hs25-b60 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 570aaefce624 Author: morris Date: 2013-11-18 12:26 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/570aaefce624 8028319: ConflictingDefaultsTest.testReabstract spins when running with -mode invoke and -Xcomp Summary: Change _abstract_method_handler to return AbstractMethodError i2c, c2i and c2iv entries. Reviewed-by: kvn, vlivanov ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 938e1e64e28f Author: anoll Date: 2013-11-14 19:27 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/938e1e64e28f 8028306: nsk stress tests, CodeCache fills, then safepoint asserts Summary: Move handle_full_code_cache() out of block that forbids safepoints Reviewed-by: kvn, iveresov ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/runtime/sweeper.cpp Changeset: fca8f4799229 Author: roland Date: 2013-11-20 12:46 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fca8f4799229 8028308: nsk regression, assert(obj->is_oop()) failed: not an oop Summary: rbp not restored when stack overflow is thrown from deopt/uncommon trap blobs Reviewed-by: kvn, iveresov ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp + test/compiler/uncommontrap/TestStackBangRbp.java Changeset: cdf20166ec45 Author: minqi Date: 2013-11-13 16:24 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/cdf20166ec45 8025632: Remove all references to MagicLambdaImpl from Hotspot Summary: MagicLambdaImpl was removed from jdk side, this should be done in vm side too Reviewed-by: coleenp, hseigel, rdurbin ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! test/compiler/jsr292/ConcurrentClassLoadingTest.java Changeset: 3edddbff4865 Author: minqi Date: 2013-11-13 16:35 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3edddbff4865 Merge Changeset: b03f33670080 Author: sla Date: 2013-11-14 19:30 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/b03f33670080 6606002: jinfo doesn't detect dynamic vm flags changing Reviewed-by: coleenp, jbachorik, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/tools/JInfo.java Changeset: 5280822ddfcd Author: sla Date: 2013-11-14 20:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5280822ddfcd 6626412: jstack using SA prints some info messages into err stream Reviewed-by: coleenp, farvidsson, jbachorik, dsamersoff, sspitsyn ! agent/src/share/classes/sun/jvm/hotspot/tools/Tool.java Changeset: 438fe38c63c8 Author: mgronlun Date: 2013-11-15 21:39 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/438fe38c63c8 Merge ! src/share/vm/runtime/globals.hpp Changeset: d61a1a166f44 Author: coleenp Date: 2013-11-15 17:20 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/d61a1a166f44 8028347: Rewriter::scan_method asserts with array oob in RT_Baseline Summary: Fix reversing rewriting for invokespecial Reviewed-by: jrose, hseigel ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp Changeset: 0b9ea9a72436 Author: sla Date: 2013-11-18 10:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/0b9ea9a72436 8027630: SIGSEGV in const char*Klass::external_name() Reviewed-by: coleenp, sspitsyn, mgronlun ! src/share/vm/classfile/metadataOnStackMark.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 396564992823 Author: sgabdura Date: 2013-11-18 08:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/396564992823 8028341: PSR:FUNC: SCOPE PARAMETER MISSING FROM THE -XX:+PRINTFLAGSFINAL Reviewed-by: dcubed, sla ! src/share/vm/runtime/globals.cpp Changeset: aa933e6b061d Author: mgronlun Date: 2013-11-22 20:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aa933e6b061d Merge Changeset: abad3b2d905d Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/abad3b2d905d Merge Changeset: c9f439732b18 Author: amurillo Date: 2013-11-22 13:34 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c9f439732b18 Added tag hs25-b60 for changeset abad3b2d905d ! .hgtags Changeset: e6dfcdf37ef2 Author: cl Date: 2013-11-28 08:23 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e6dfcdf37ef2 Added tag jdk8-b118 for changeset c9f439732b18 ! .hgtags Changeset: e51d73189692 Author: amurillo Date: 2013-11-22 13:42 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e51d73189692 8028815: new hotspot build - hs25-b61 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 19146c82b6fc Author: hseigel Date: 2013-11-21 14:41 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/19146c82b6fc 8028520: JVM should not throw VerifyError when a private method overrides a final method Summary: Exclude private methods when checking for final method override. Reviewed-by: kamg, coleenp, dholmes, mseledtsov ! src/share/vm/classfile/classFileParser.cpp Changeset: 260ac69dc096 Author: mgronlun Date: 2013-11-23 09:56 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/260ac69dc096 Merge Changeset: 86e6d691f2e1 Author: mgronlun Date: 2013-11-23 12:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/86e6d691f2e1 8028128: Add a type safe alternative for working with counter based data Reviewed-by: dholmes, egahlin ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/gcTimer.cpp ! src/share/vm/gc_implementation/shared/gcTimer.hpp ! src/share/vm/gc_implementation/shared/gcTrace.cpp ! src/share/vm/gc_implementation/shared/gcTrace.hpp ! src/share/vm/gc_implementation/shared/gcTraceSend.cpp ! src/share/vm/gc_implementation/shared/gcTraceTime.cpp ! src/share/vm/gc_implementation/shared/gcTraceTime.hpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp ! src/share/vm/gc_implementation/shared/objectCountEventSender.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/runtime/sweeper.cpp ! src/share/vm/runtime/sweeper.hpp ! src/share/vm/trace/noTraceBackend.hpp ! src/share/vm/trace/trace.xml ! src/share/vm/trace/traceBackend.hpp ! src/share/vm/trace/traceEvent.hpp ! src/share/vm/trace/traceEventClasses.xsl ! src/share/vm/trace/traceTime.hpp ! src/share/vm/trace/traceTypes.xsl ! src/share/vm/trace/tracetypes.xml + src/share/vm/utilities/ticks.cpp + src/share/vm/utilities/ticks.hpp + src/share/vm/utilities/ticks.inline.hpp Changeset: 22eaa15b7960 Author: hseigel Date: 2013-11-26 09:52 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/22eaa15b7960 8026065: InterfaceMethodref for invokespecial must name a direct superinterface Summary: Add verification to check that invokespecial of an InterfaceMethodref names a method in a direct superinterface of the current class or interface in accordance with JSR 335, JVMS 4.9.2 Structural Constraints. Reviewed-by: acorn, hseigel, coleenp Contributed-by: lois.foltan at oracle.com ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: e567d5afd4dd Author: hseigel Date: 2013-11-26 16:03 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/e567d5afd4dd 8028160: [TESTBUG] Exclude failing (runtime) jtreg tests using @ignore Summary: Use @ignore to exclude failing tests Reviewed-by: coleenp, ctornqvi, mseledtsov Contributed-by: george.triantafillou at oracle.com ! test/runtime/6626217/Test6626217.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/CDSCompressedKPtrs/XShareAuto.java ! test/runtime/InitialThreadOverflow/testme.sh ! test/runtime/LoadClass/LoadClassNegative.java ! test/runtime/XCheckJniJsig/XCheckJSig.java ! test/runtime/jsig/Test8017498.sh ! test/runtime/memory/ReadFromNoaccessArea.java Changeset: 9d15b81d5d1b Author: drchase Date: 2013-11-26 18:16 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/9d15b81d5d1b 8016839: JSR292: AME instead of IAE when calling a method Summary: Catch missing-because-illegal case for itable entries and use an exception-throwing method instead of null. Reviewed-by: acorn, jrose, coleenp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/klassVtable.cpp ! test/compiler/jsr292/methodHandleExceptions/ByteClassLoader.java - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java ! test/compiler/jsr292/methodHandleExceptions/TestAMEnotNPE.java + test/compiler/jsr292/methodHandleExceptions/p/C.java + test/compiler/jsr292/methodHandleExceptions/p/Dok.java + test/compiler/jsr292/methodHandleExceptions/p/E.java + test/compiler/jsr292/methodHandleExceptions/p/F.java + test/compiler/jsr292/methodHandleExceptions/p/I.java + test/compiler/jsr292/methodHandleExceptions/p/Tdirect.java + test/compiler/jsr292/methodHandleExceptions/p/Treflect.java Changeset: 2315fab779ca Author: drchase Date: 2013-11-29 11:32 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/2315fab779ca Merge ! src/share/vm/classfile/systemDictionary.hpp - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: b2426da30009 Author: amurillo Date: 2013-11-29 11:10 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b2426da30009 Merge - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: ce42d815dd21 Author: amurillo Date: 2013-11-29 11:10 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ce42d815dd21 Added tag hs25-b61 for changeset b2426da30009 ! .hgtags Changeset: a3dc98dc4d21 Author: katleman Date: 2013-12-04 23:11 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/a3dc98dc4d21 Added tag jdk8-b119 for changeset ce42d815dd21 ! .hgtags Changeset: b6b9a5d4cda0 Author: amurillo Date: 2013-11-29 11:20 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b6b9a5d4cda0 8029367: new hotspot build - hs25-b62 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 77b028ba548c Author: jprovino Date: 2013-11-19 16:26 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/77b028ba548c 8028396: Minimal VM: undefined symbol: _ZN23JvmtiCurrentBreakpoints11metadata_doEPFvP8MetadataE Summary: Minimal VM doesn't run Reviewed-by: coleenp, dholmes ! src/share/vm/prims/jvmtiImpl.hpp Changeset: 3fbb71fdc6e5 Author: vladidan Date: 2013-12-01 22:35 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/3fbb71fdc6e5 Merge Changeset: 8a42e81e2f9d Author: dsamersoff Date: 2013-11-27 14:26 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/8a42e81e2f9d 7050685: jsdbproc64.sh has a typo in the package name Summary: fixed typeo Reviewed-by: sla, kmo, sspitsyn ! agent/make/jsdbproc64.sh Changeset: 6ce6a0d23467 Author: mgronlun Date: 2013-12-02 11:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6ce6a0d23467 Merge - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: 7a58803b5069 Author: acorn Date: 2013-12-03 08:36 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/7a58803b5069 8026066: ICCE for invokeinterface static Reviewed-by: coleenp, lfoltan, hseigel ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! test/TEST.groups ! test/runtime/8024804/RegisterNatives.java Changeset: 379f11bc04fc Author: acorn Date: 2013-12-03 11:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/379f11bc04fc 8028438: static superclass method masks default methods Reviewed-by: hseigel, lfoltan, coleenp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp Changeset: c8c2d6b82499 Author: sspitsyn Date: 2013-12-03 15:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c8c2d6b82499 8028126: nsk/jvmti/scenarios/hotswap/HS101/hs101t006 Crashed the vm on Solaris-sparc64 fastdebug builds: only current thread can flush its registers Summary: Fix a race between VMOp_GetCurrentLocation reaching a safepoint and arget thread exiting from Java execution Reviewed-by: sla, dholmes, dsamersoff Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiEnvThreadState.cpp Changeset: e84d2afb2fb0 Author: sspitsyn Date: 2013-12-03 13:56 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/e84d2afb2fb0 Merge Changeset: 55a0da3d420b Author: sjohanss Date: 2013-11-26 14:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/55a0da3d420b 8027675: Full collections with Serial slower in JDK 8 compared to 7u40 Summary: Reduced the number of calls to follow_class_loader and instead marked and pushed the klass holder directly. Also removed unneeded calls to adjust_klass. Reviewed-by: coleenp, jmasa, mgerdin, tschatzl ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp Changeset: 9fc985481d78 Author: ehelin Date: 2013-12-02 15:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9fc985481d78 Merge ! src/share/vm/oops/instanceKlass.cpp - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: 50287b659eb8 Author: sjohanss Date: 2013-12-03 12:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/50287b659eb8 8029329: tmtools tests fail with NPE (in the tool) when run with G1 and FlightRecorder Summary: Now iterating over all committed (used) G1 regions instead of all reserved. Reviewed-by: brutisso, dsamersoff, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/G1HeapRegionTable.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/g1/HeapRegionSeq.java Changeset: 816c89d5957d Author: ehelin Date: 2013-12-05 17:49 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/816c89d5957d Merge ! src/share/vm/oops/instanceKlass.cpp Changeset: 9949533a8623 Author: rbackman Date: 2013-11-22 14:14 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/9949533a8623 8028997: mathexact intrinsics are unstable Reviewed-by: iveresov, kvn ! src/share/vm/opto/c2_globals.hpp ! test/compiler/intrinsics/mathexact/AddExactICondTest.java ! test/compiler/intrinsics/mathexact/AddExactIConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactILoadTest.java ! test/compiler/intrinsics/mathexact/AddExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/AddExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/AddExactLConstantTest.java ! test/compiler/intrinsics/mathexact/AddExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/CompareTest.java ! test/compiler/intrinsics/mathexact/DecExactITest.java ! test/compiler/intrinsics/mathexact/DecExactLTest.java ! test/compiler/intrinsics/mathexact/GVNTest.java ! test/compiler/intrinsics/mathexact/IncExactITest.java ! test/compiler/intrinsics/mathexact/IncExactLTest.java ! test/compiler/intrinsics/mathexact/MulExactICondTest.java ! test/compiler/intrinsics/mathexact/MulExactIConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactILoadTest.java ! test/compiler/intrinsics/mathexact/MulExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/MulExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/MulExactLConstantTest.java ! test/compiler/intrinsics/mathexact/MulExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactIConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactILoadTest.java ! test/compiler/intrinsics/mathexact/NegExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/NegExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactLConstantTest.java ! test/compiler/intrinsics/mathexact/NegExactLNonConstantTest.java ! test/compiler/intrinsics/mathexact/NestedMathExactTest.java ! test/compiler/intrinsics/mathexact/SplitThruPhiTest.java ! test/compiler/intrinsics/mathexact/SubExactICondTest.java ! test/compiler/intrinsics/mathexact/SubExactIConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactILoadTest.java ! test/compiler/intrinsics/mathexact/SubExactILoopDependentTest.java ! test/compiler/intrinsics/mathexact/SubExactINonConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactIRepeatTest.java ! test/compiler/intrinsics/mathexact/SubExactLConstantTest.java ! test/compiler/intrinsics/mathexact/SubExactLNonConstantTest.java Changeset: 55dd6e77b399 Author: rbackman Date: 2013-11-22 15:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/55dd6e77b399 8028624: [TESTBUG] compiler/intrinsics/mathexact/DecExactLTest executes DecExactITest Reviewed-by: kvn, twisti ! test/compiler/intrinsics/mathexact/DecExactLTest.java Changeset: eae426d683f6 Author: simonis Date: 2013-12-02 11:12 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/eae426d683f6 8029190: VM_Version::determine_features() asserts on Fujitsu Sparc64 CPUs Summary: fix code to allow testing on Fujitsu Sparc64 CPUs Reviewed-by: kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 61746b5f0ed3 Author: anoll Date: 2013-12-04 09:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/61746b5f0ed3 8028109: compiler/codecache/CheckReservedInitialCodeCacheSizeArgOrder.java crashes in RT_Baseline Summary: Use non-relocatable code to load byte_map_base Reviewed-by: kvn, roland ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 6a8941dbd26f Author: anoll Date: 2013-12-05 12:49 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/6a8941dbd26f Merge Changeset: 05fedd51e40d Author: amurillo Date: 2013-12-06 09:29 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/05fedd51e40d Merge Changeset: fca262db9c43 Author: amurillo Date: 2013-12-06 09:29 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/fca262db9c43 Added tag hs25-b62 for changeset 05fedd51e40d ! .hgtags Changeset: ce2d7e46f3c7 Author: katleman Date: 2013-12-12 05:20 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/ce2d7e46f3c7 Added tag jdk8-b120 for changeset fca262db9c43 ! .hgtags Changeset: 3aa20cee331a Author: amurillo Date: 2013-12-06 09:41 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/3aa20cee331a 8029693: new hotspot build - hs25-b63 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9a60f4ac6a37 Author: hseigel Date: 2013-12-04 08:10 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/9a60f4ac6a37 8027458: VM anonymous classes: wrong context for protected access checks Summary: Use the anonymous class's host class for protected access checks Reviewed-by: acorn, coleenp, lfoltan ! src/share/vm/runtime/reflection.cpp Changeset: a4f036ef52e8 Author: sla Date: 2013-12-04 14:43 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/a4f036ef52e8 8029395: SA: jstack throws WrongTypeException Summary: SA missed some TLABs Reviewed-by: dsamersoff, mgerdin, brutisso ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java Changeset: c586f8a7322f Author: mgronlun Date: 2013-12-05 12:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/c586f8a7322f 8028412: AsyncGetCallTrace() is broken on x86 in JDK 7u40 Reviewed-by: kvn, sspitsyn ! src/cpu/x86/vm/frame_x86.cpp Changeset: 769557390c43 Author: hseigel Date: 2013-12-06 11:33 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/769557390c43 8029415: java/lang/reflect/Method/invoke/TestPrivateInterfaceMethodReflect.java fails on all platforms with hs25-b61 Summary: Check first that a class is not a dynamically-generated bytecode associated with 1.4 reflection implementation, to emitting an ICCE of an invokespecial IMR of a method in an indirect superinterface. Reviewed-by: acorn, hseigel Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp Changeset: a150ff9e8efc Author: hseigel Date: 2013-12-06 11:49 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/a150ff9e8efc Merge Changeset: bf15208b72a5 Author: mgronlun Date: 2013-12-08 18:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/bf15208b72a5 Merge Changeset: 9fbabcbb875b Author: hseigel Date: 2013-12-10 16:18 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/9fbabcbb875b 8028741: Interface Method Resolution should skip static and non-public methods in j.l.Object Summary: Implementation of JDK 8 JVMS 5.4.3.4 specification change to skip static and non-public methods of java.lang.Object for interface method resolution. Reviewed-by: acorn, coleenp Contributed-by: lois.foltan at oracle.com ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! test/runtime/8024804/RegisterNatives.java Changeset: 1de8e5356754 Author: ehelin Date: 2013-12-09 08:20 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1de8e5356754 8029326: G1 does not check if threads gets created Reviewed-by: brutisso, jmasa, jwilhelm ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: ad72068ac41e Author: sjohanss Date: 2013-12-10 10:31 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/ad72068ac41e 8028993: Full collections with ParallelScavenge slower in JDK 8 compared to 7u40 Summary: Reducing the number of calls to follow_class_loader to speed up the marking phase. Also removed some unnecessary calls to adjust_klass. Reviewed-by: stefank, jmasa, mgerdin ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/oops/instanceClassLoaderKlass.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceMirrorKlass.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.pcgc.inline.hpp Changeset: fa76dce60db7 Author: stefank Date: 2013-12-09 10:03 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/fa76dce60db7 8029106: JVM crashes in Metachunk::Metachunk during parallel class redefinition (PrivateMLetController, anonymous-simple_copy_1) Summary: Fixed overflow bug in VirtualSpaceNode::is_available Reviewed-by: mgerdin, brutisso, coleenp, jmasa ! src/share/vm/memory/metaspace.cpp Changeset: e3995ab44393 Author: ehelin Date: 2013-12-12 16:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e3995ab44393 Merge Changeset: df832bd8edb9 Author: kvn Date: 2013-12-06 12:11 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/df832bd8edb9 8028107: Kitchensink crashed with EAV Summary: check the state of caller and callee nmethods and skip call site patching if any of them is not alive Reviewed-by: jrose, twisti ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: b87211e33ebb Author: twisti Date: 2013-12-06 16:43 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/b87211e33ebb 8029366: ShouldNotReachHere error when creating an array with component type of void Reviewed-by: kvn ! src/share/vm/opto/memnode.cpp + test/compiler/reflection/ArrayNewInstanceOfVoid.java Changeset: ad45ebfba060 Author: iignatyev Date: 2013-12-11 01:04 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/ad45ebfba060 8028122: [TESTBUG] compiler/regalloc/C1ObjectSpillInLogicOp.java Reviewed-by: kvn, twisti ! test/compiler/regalloc/C1ObjectSpillInLogicOp.java Changeset: 62084ffe573b Author: iignatyev Date: 2013-12-11 01:09 +0400 URL: http://hg.openjdk.java.net/graal/graal/rev/62084ffe573b 8029153: [TESTBUG] test/compiler/7141637/SpreadNullArg.java fails because it expects NullPointerException Reviewed-by: twisti ! test/compiler/7141637/SpreadNullArg.java Changeset: bc8b01f98ae3 Author: anoll Date: 2013-12-12 11:22 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/bc8b01f98ae3 Merge Changeset: fa6d364024c2 Author: jprovino Date: 2013-12-11 13:51 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/fa6d364024c2 8029566: PPC: OrderAccess::load_acquire(julong) is broken Summary: JFR needs this fix to run on PPC Reviewed-by: sla, mikael ! src/share/vm/utilities/globalDefinitions_gcc.hpp Changeset: dc09e905db20 Author: vladidan Date: 2013-12-12 17:08 -0500 URL: http://hg.openjdk.java.net/graal/graal/rev/dc09e905db20 Merge Changeset: 2a21bf819fea Author: vladidan Date: 2013-12-12 14:06 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/2a21bf819fea Merge Changeset: 41f4cad94c58 Author: amurillo Date: 2013-12-13 09:40 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/41f4cad94c58 Merge Changeset: 5f07ec8bb982 Author: amurillo Date: 2013-12-13 09:40 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/5f07ec8bb982 Added tag hs25-b63 for changeset 41f4cad94c58 ! .hgtags Changeset: 02f27ecb4f3a Author: Doug Simon Date: 2013-12-18 00:00 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/02f27ecb4f3a Merge with http://hg.openjdk.java.net/hsx/hsx25/hotspot/ ! .hgtags ! make/hotspot_version ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/sweeper.cpp - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: 8275a0d0c90a Author: Doug Simon Date: 2013-12-18 11:26 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/8275a0d0c90a create profiling info, phase plan and optimistic opts when running a CompilationTask, not when creating it (GRAAL-640) ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompileTheWorld.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: e3ec81d3e976 Author: Doug Simon Date: 2013-12-18 11:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e3ec81d3e976 Merge. ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! src/share/vm/classfile/vmSymbols.hpp Changeset: aba12e3603b4 Author: Doug Simon Date: 2013-12-18 13:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/aba12e3603b4 Merge. Changeset: 69d2e4baa215 Author: Michael Van De Vanter Date: 2013-12-17 20:22 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/69d2e4baa215 Truffle: new infrastructure related to instrumentation, and in particular debugging: support for managing Source objects; framework for generalized "instrumentation proxy nodes" (to be inserted into ASTs with no runtime cost when inactive), and "probes" (which can be attached to proxy nodes to receive event notification); a rudimentary interface and abstract implementation for a "debug manager" (mostly a placeholder at this point); and the beginning of a language-agnostic ExecutionContext interface. + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/DebugManager.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/ExecutionContext.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/Source.java ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/SourceSection.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/EmptyProbe.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationNode.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProbeEvents.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProbeNode.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/nodes/instrument/InstrumentationProxyNode.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceLineLocation.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceManager.java + graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/TextMap.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/AbstractTest.java ! graal/com.oracle.truffle.sl.test/src/com/oracle/truffle/sl/test/FibonacciTest.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SLScript.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/SimpleLanguage.java ! graal/com.oracle.truffle.sl/src/com/oracle/truffle/sl/runtime/SLContext.java Changeset: 9c88b1138240 Author: Michael Van De Vanter Date: 2013-12-17 21:26 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/9c88b1138240 Merge with 430c9f08728d9efa37f4311aa712e969f9e5e254 - graal/com.oracle.graal.compiler.hsail.test/src/com/oracle/graal/compiler/hsail/test/FloatSqrtTest.java Changeset: d3f662f9b7d6 Author: Michael Van De Vanter Date: 2013-12-17 22:26 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/d3f662f9b7d6 Merge with ad187607b784c7ee65c4832923619461c3243148 Changeset: f45452c87b52 Author: Michael Van De Vanter Date: 2013-12-18 03:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f45452c87b52 Merge with 40530019af024ad7ac77c392a161a6ad91ed50cb Changeset: f76593e3fedb Author: Michael Van De Vanter Date: 2013-12-18 03:16 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/f76593e3fedb Truffle: make the new class SourceManager.SourceImpl public temporarily until some related changes propagate completely. ! graal/com.oracle.truffle.api/src/com/oracle/truffle/api/source/SourceManager.java Changeset: 163b418ec095 Author: Michael Van De Vanter Date: 2013-12-18 06:06 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/163b418ec095 Merge with aba12e3603b48feda21b2a09fd4e03710c83eace - test/compiler/jsr292/methodHandleExceptions/C.java - test/compiler/jsr292/methodHandleExceptions/I.java Changeset: 52eb34dd84d7 Author: Christian Wirth Date: 2013-12-18 17:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/52eb34dd84d7 JS: fix, evaluating jboolean directly gives a warning (and thus error) on Windows ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 5f54b8a68346 Author: Erik Eckstein Date: 2013-12-19 08:35 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/5f54b8a68346 limit complexity of redundant move elimination ! graal/com.oracle.graal.lir/src/com/oracle/graal/lir/RedundantMoveElimination.java Changeset: 424e2bfecb72 Author: Erik Eckstein Date: 2013-12-19 08:40 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/424e2bfecb72 fix compiletime-expensive debug log message in LinearScan ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java Changeset: 2236d18302e0 Author: Doug Simon Date: 2013-12-19 11:38 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/2236d18302e0 made -G:PrintCompRate incompatible with -XX:+CITime and -XX:+CITimeEach ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/CompilationTask.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotOptions.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: e2a14719e833 Author: Doug Simon Date: 2013-12-19 11:42 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e2a14719e833 refactored FastNodeClassRegistry to work around javac bug where it could not resolve NodeClass.Registry Compiling Java sources for com.oracle.graal.hotspot with javac... /Users/dsimon/linz/basic-graal/graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java:216: error: package NodeClass does not exist static class FastNodeClassRegistry extends NodeClass.Registry { ^ + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/FastNodeClassRegistry.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java Changeset: 51d31106cd5e Author: Erik Eckstein Date: 2013-12-20 08:06 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/51d31106cd5e fix wrong register definition in AMD64 TableSwitchOp ! graal/com.oracle.graal.compiler.amd64/src/com/oracle/graal/compiler/amd64/AMD64LIRGenerator.java ! graal/com.oracle.graal.lir.amd64/src/com/oracle/graal/lir/amd64/AMD64ControlFlow.java Changeset: 7c694e3e97e5 Author: Erik Eckstein Date: 2013-12-20 08:08 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/7c694e3e97e5 remove remaining old style TTY debug logging in LinearScan and remove TraceLinearScan option ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/Interval.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/IntervalWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScan.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/LinearScanWalker.java ! graal/com.oracle.graal.compiler/src/com/oracle/graal/compiler/alloc/RegisterVerifier.java Changeset: 1d53e766f71a Author: Doug Simon Date: 2013-12-20 10:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/1d53e766f71a added more tests for GETFIELD + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_b.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_c.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_d.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_f.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_i.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_l.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_o.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_s.java + graal/com.oracle.graal.jtt/src/com/oracle/graal/jtt/bytecode/BC_getfield_z.java Changeset: cdde71dc5381 Author: Thomas Wuerthinger Date: 2013-12-20 23:01 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/cdde71dc5381 Move IGV to NetBeans platform 7.4 to support also JDK8. ! src/share/tools/IdealGraphVisualizer/FilterWindow/nbproject/build-impl.xml ! src/share/tools/IdealGraphVisualizer/FilterWindow/nbproject/genfiles.properties ! src/share/tools/IdealGraphVisualizer/Graal/build.xml ! src/share/tools/IdealGraphVisualizer/Graal/nbproject/build-impl.xml ! src/share/tools/IdealGraphVisualizer/Graal/nbproject/genfiles.properties ! src/share/tools/IdealGraphVisualizer/NetworkConnection/nbproject/build-impl.xml ! src/share/tools/IdealGraphVisualizer/NetworkConnection/nbproject/genfiles.properties ! src/share/tools/IdealGraphVisualizer/SelectionCoordinator/nbproject/build-impl.xml ! src/share/tools/IdealGraphVisualizer/SelectionCoordinator/nbproject/genfiles.properties ! src/share/tools/IdealGraphVisualizer/nbproject/genfiles.properties ! src/share/tools/IdealGraphVisualizer/nbproject/platform.properties ! src/share/tools/IdealGraphVisualizer/nbproject/platform.xml Changeset: eb7bc1fd38de Author: Doug Simon Date: 2013-12-21 13:28 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/eb7bc1fd38de made mx.py (first line) more portable ! mxtool/mx.py Changeset: 020099961eb4 Author: Doug Simon Date: 2013-12-21 13:33 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/020099961eb4 renamed JavaVersion to VersionSpec ! mx/mx_graal.py ! mxtool/mx.py Changeset: 72e2ec923b7b Author: Doug Simon Date: 2013-12-21 13:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/72e2ec923b7b added support to replace NetBeans platform used by IGV if it is out of date (GRAAL-420) ! mx/mx_graal.py From ndrzmansn at gmail.com Sat Dec 21 23:44:58 2013 From: ndrzmansn at gmail.com (Wei Zhang) Date: Sat, 21 Dec 2013 23:44:58 -0800 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Hi Stefan, > The second difference I see is that you have a `prepareBodyNode()` operation that rewrites local variable access nodes. Why is that necessary? Inlined function in ZipPy has its own copy of the FrameDescriptor. I did this to make sure that it doesn't share any frame state with the original function. 'prepareBodyNode()' updates local variable accesses to use the new FrameDescriptor. It is just a correctness thing. I'm actually curious about how easy/difficult was it for you to use RPython? Compare to Truffle was it easier to get the performance that you are happy with? or you also got some help from the PyPy guys? Thanks, /Wei On Fri, Dec 20, 2013 at 11:55 PM, Stefan Marr wrote: > Hi Wei: > > On 21 Dec 2013, at 01:45, Wei Zhang wrote: > >> Only functions that close over its declaration frame (closures) use >> PArguments#declarationFrame. This doesn't happen so often in my >> benchmarks. >> In most cases, zippy accesses local variable using VirtualFrames, >> which is optimized by Truffle/Graal. > > Well, closures are much more common in Smalltalk, I think. > >>> I do wonder, what is the typical granularity of a Python method? >>> At least in SOM, methods seem to be rather small. Perhaps a few AST nodes on average. >>> Could that make a difference? >> >> Zippy inlines function calls when they become hot. Inlining helps >> performance a lot. >> I strongly recommend you to apply inlining in TruffleSOM if you haven?t yet. > > TruffleSOM does inlining. I only see two difference when browsing your code. > The first should actually be a benefit for TruffleSOM: I also inline trivial methods immediately, i.e., if a method just contains a literal or something similar, it is directly inlined without even a function call overhead, only protected by a polymorphic inline cache check node. > The second difference I see is that you have a `prepareBodyNode()` operation that rewrites local variable access nodes. Why is that necessary? > >> >>> Another detail I noticed is that you are using another strategy for type handling in the type system. You use a combination of @TypeCheck and @TypeCast, while I use @ImplicitCast. >>> What is the difference of these two approaches? >> >> I use @TypeCheck and @TypeCast to customize type checks and >> conversions in ZipPy. I just followed the SimpleLanguage examples in >> Truffle API. >> @ImplicitCast is new to me. I don't know how to use it, since there >> isn?t any related document or example. > > There is a tiny example in SimpleLanguage? That?s where I took it from. But I have the feeling the generated code when using @TypeCheck and @TypeCast looks quite a bit simpler. > > Thanks for the comments > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > From doug.simon at oracle.com Sun Dec 22 01:11:50 2013 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 22 Dec 2013 10:11:50 +0100 Subject: Graal on Mavericks In-Reply-To: References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: You can be sure it is the compilation of ad_x86_64.cpp by invoking the build as such: mx -v build -D HOTSPOT_BUILD_JOBS=1 This will also show exactly the compile command being issued. -Doug On Dec 21, 2013, at 3:02 AM, Christian Thalinger wrote: > This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? > > On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: > >> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >> >> My mx/env contains: >> >> DEFAULT_VM=server >> COMPILER_WARNINGS_FATAL=false >> USE_CLANG=true >> LFLAGS=-Xlinker -lstdc++ >> USE_PRECOMPILED_HEADER=0 >> >> Here's the log: >> >> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >> cd /Users/mario/Work/Eclipse/graal/make; \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> >> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> >> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >> make[4]: Nothing to be done for `all'. >> make[4]: Nothing to be done for `all'. >> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >> -a "x86" != "arm" \ >> -a "x86" != "ppc" \ >> -a "x86" != "zero" ] ; then \ >> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >> fi >> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >> echo "dtrace headers generated" >> dtrace headers generated >> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >> Compiling ../generated/adfiles/ad_x86_64.cpp >> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >> Compiling ../generated/adfiles/ad_x86_64_format.cpp >> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_misc.o] Error 254 >> >> make[4]: *** Waiting for unfinished jobs.... >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_gen.o] Error 254 >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_expand.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [abstractCompiler.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [accessFlags.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_clone.o] Error 254 >> >> clang: error: unable to execute command: Segmentation fault: 11 >> >> clang: error: clang frontend command failed due to signal (use -v to see invocation) >> >> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >> >> Target: x86_64-apple-darwin13.0.0 >> >> Thread model: posix >> >> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >> >> clang: note: diagnostic msg: >> >> ******************** >> >> >> >> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >> >> Preprocessed source(s) and associated run script(s) are located at: >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >> >> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >> >> clang: note: diagnostic msg: >> >> >> >> ******************** >> >> make[4]: *** [ad_x86_64_format.o] Error 254 >> >> make[3]: *** [the_vm] Error 2 >> >> make[2]: *** [product] Error 2 >> >> make[1]: *** [generic_build2] Error 2 >> >> make: *** [product] Error 2 >> >> >> >> >> > From java at stefan-marr.de Sun Dec 22 03:00:00 2013 From: java at stefan-marr.de (Stefan Marr) Date: Sun, 22 Dec 2013 12:00:00 +0100 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Hi Wei: On 22 Dec 2013, at 08:44, Wei Zhang wrote: > Hi Stefan, > >> The second difference I see is that you have a `prepareBodyNode()` operation that rewrites local variable access nodes. Why is that necessary? > > Inlined function in ZipPy has its own copy of the FrameDescriptor. I > did this to make sure that it doesn't share any frame state with the > original function. > 'prepareBodyNode()' updates local variable accesses to use the new > FrameDescriptor. > It is just a correctness thing. Hm, ok. I still don?t exactly see why that is necessary. Is the frame layout different? I thought the FrameDescriptor is more or less just a declaration of what goes where, and that should be identical for inlined functions as well, no? > I'm actually curious about how easy/difficult was it for you to use RPython? > Compare to Truffle was it easier to get the performance that you are > happy with? or you also got some help from the PyPy guys? Well, there were a couple of phases, that are different from my work on TruffleSOM. RPython is different enough from Python so that it took some work to get the interpreter running. There are a couple of things the type inference requires help with for instance lambdas need to be put in a scope static enough to be analyzable, and a stricter language for instance tuples and lists are not exchangeable, and another set of libraries. So some minor functionality such as reading from the REPL had to be implemented differently. For that, the RPython error messages were useful ?enough?, but I also got a hand from a colleague who has been using RPython for a while, and had been involved with SOM before. After that was done, I worked a bit on the object model of SOM. Especially in areas that were useful for TruffleSOM as well. So, actually, I changed the language a bit and hid more implementation details of the object layout behind methods (primitives) instead of representing them by fields in the objects. The third phase was then to add RPythons annotations throughout the code in order to communicate to the tracer what is constant, what is not going to change in the context of a trace, where to look for trace starts etc. And here, I actually got a hand from one of the core RPython guys, who had a look at the code and did the collect all the low hanging fruit. Looking at his changes, many of them I could have done based on good document, and guidelines, I think. But some of them are experience I would say. If you are curious for the details, have a look at: https://github.com/SOM-st/RPySOM/commits/non-recursive-with-jumps The changes by Carl Friedrich Bolz (cfbolz) around October 21st are probably most interesting for the performance. As a current result, the last time I measured, DeltaBlue wasn?t to far off from the PyPy numbers anymore. And at the moment, we expect to still get a little more out of RPySOM. I made the interpreter recursive, similar to the basic execution model in Truffle, which should give the tracer some more context. But currently we are hitting some problems, because that approach requires at least two general points for trace starts. One in the interpreter loop, and one in the loop primitives. However, that?s something not commonly used in other RPython languages, and it seems to be broken. So, for very recursive programs it doesn?t work that well, while benchmarks with loops benefit from this change a lot. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From java at stefan-marr.de Mon Dec 23 06:47:06 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 23 Dec 2013 15:47:06 +0100 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Hi Christian, Hi Chris: I was wondering about alternative solutions for non-local returns. Christian, you said: > 1) Major: (OptimizedCallTarget.java:214) Method.execute(Method.java:72) > This method calls a method #messageSendExecution which contains a lot of control flow and allocations [4] . Speculate on the fact that all of this code is not required. It contains a while loop + a lot of exception catches. I think on the fast-path it could just call the body of the method. The first thing, I noticed after you pointing me there, is that I was able to remove some of the complexity, because I intrinsified while loops, and don?t need support for the control flow exception anymore. However, that still leaves me with this: protected static Object messageSendExecution(final VirtualFrame frame, final ExpressionNode expr) { FrameOnStackMarker marker = Arguments.get(frame).getFrameOnStackMarker(); Object result; try { result = expr.executeGeneric(frame); } catch (ReturnException e) { if (!e.reachedTarget(marker)) { marker.frameNoLongerOnStack(); throw e; } else { result = e.result(); } } marker.frameNoLongerOnStack(); return result; } So, the while loop is gone. We just got the exception handling for non-local returns. You said, speculate that you don?t need that. And I am now wondering whether I could go further than what you see above. Chris, how did you solve non-local returns for Ruby? I suppose Ruby?s return is more or less similar to Smalltalk?s? For SOM, I need to be able to return to the correct lexical scope, i.e., I want to return from the outer lexical method that?s still on the stack. However, in addition, I need to unwind the stack, and mark frames as ?unwound?/removed from the stack in order to be able to handle blocks correctly that were return from a method, and were the outer activation does not exist anymore. Here, a non-local return just doesn?t have a good semantic, and needs to raise an error. So, I guess, this means, the only time I do not need this exception handling here is when a method does not define any blocks in its body. Chris, do you do that kind of special casing? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From chris at chrisseaton.com Mon Dec 23 07:41:35 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Mon, 23 Dec 2013 15:41:35 +0000 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Specialising on not needing to catch the return exception: Not all methods need to catch and handle ReturnException. Christian's suggestion is that you speculate that they will not need it. You could do this with two nodes - one that transfer to interpreter in the handler, and one that actually does something in the handler. More simply you can do it with just one node, and a BranchProfile in the handler. See the BranchProfile class and tests to see how this works, and ask again if that's not clear, but basically it's like final BranchProfile catchBranchProfile = new BranchProfile() ... catch (ReturnException e) { catchBranchProfile.enter(); ... } This cuts of compilation of the catch node when it isn't ever used, reducing code size. Reducing code size is an especially good proxy for increasing code speed in Trufffle. Non-local returns in Ruby: Each method has a unique identifier allocated in the parser. The throw nodes also store this integer, and they put it into the ReturnException when they construct it. Then the ReturnException handlers check if the exception is meant for them, and if it's not they re-throw it. In Ruby it's very common to go through at least one scope like this - returns in a block within a method return from the method, not the block, even though the block is really a method in its own right. When the exception is finally caught I just return it as the return value from the execute method and it becomes a normal returned value. Note that in Ruby the return handler is a node all on its own. This logic isn't in RubyRootNode, RubyMethod, or the send node, like it looks like you are here. Methods which need it have a CatchReturnNode in their prelude. I also use this technique for things like checking that the number of arguments is correct. Then nodes which don't ever catch returns, like blocks, don't even have this node to begin with. Chris On 23 December 2013 14:47, Stefan Marr wrote: > Hi Christian, > Hi Chris: > > I was wondering about alternative solutions for non-local returns. > Christian, you said: > > > 1) Major: (OptimizedCallTarget.java:214) Method.execute(Method.java:72) > > This method calls a method #messageSendExecution which contains a lot of > control flow and allocations [4] . Speculate on the fact that all of this > code is not required. It contains a while loop + a lot of exception > catches. I think on the fast-path it could just call the body of the method. > > The first thing, I noticed after you pointing me there, is that I was able > to remove some of the complexity, because I intrinsified while loops, and > don?t need support for the control flow exception anymore. However, that > still leaves me with this: > > protected static Object messageSendExecution(final VirtualFrame frame, > final ExpressionNode expr) { > FrameOnStackMarker marker = > Arguments.get(frame).getFrameOnStackMarker(); > Object result; > > try { > result = expr.executeGeneric(frame); > } catch (ReturnException e) { > if (!e.reachedTarget(marker)) { > marker.frameNoLongerOnStack(); > throw e; > } else { > result = e.result(); > } > } > > marker.frameNoLongerOnStack(); > return result; > } > > So, the while loop is gone. We just got the exception handling for > non-local returns. > You said, speculate that you don?t need that. And I am now wondering > whether I could go further than what you see above. > > Chris, how did you solve non-local returns for Ruby? I suppose Ruby?s > return is more or less similar to Smalltalk?s? > > For SOM, I need to be able to return to the correct lexical scope, i.e., I > want to return from the outer lexical method that?s still on the stack. > However, in addition, I need to unwind the stack, and mark frames as > ?unwound?/removed from the stack in order to be able to handle blocks > correctly that were return from a method, and were the outer activation > does not exist anymore. Here, a non-local return just doesn?t have a good > semantic, and needs to raise an error. > > So, I guess, this means, the only time I do not need this exception > handling here is when a method does not define any blocks in its body. > Chris, do you do that kind of special casing? > > Thanks > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From mario.wolczko at oracle.com Mon Dec 23 11:56:52 2013 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Mon, 23 Dec 2013 11:56:52 -0800 Subject: Graal on Mavericks In-Reply-To: References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: It's failing on abtractCompiler.cpp. This is what I get: clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/mario/Work/Eclipse/graal/src/share/vm/prims -I/Users/mario/Work/Eclipse/graal/src/share/vm -I/Users/mario/Work/Eclipse/graal/src/share/vm/precompiled -I/Users/mario/Work/Eclipse/graal/src/cpu/x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_cpu/bsd_x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_gpu/bsd_ptx/vm -I/Users/mario/Work/Eclipse/graal/src/os/bsd/vm -I/Users/mario/Work/Eclipse/graal/src/os/posix/vm -I/Users/mario/Work/Eclipse/graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b59-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mario\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp clang: error: unable to execute command: Segmentation fault: 11 Does this match the invocation you get? On Dec 22, 2013, at 1:11 AM, Doug Simon wrote: > You can be sure it is the compilation of ad_x86_64.cpp by invoking the build as such: > > mx -v build -D HOTSPOT_BUILD_JOBS=1 > > This will also show exactly the compile command being issued. > > -Doug > > On Dec 21, 2013, at 3:02 AM, Christian Thalinger wrote: > >> This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? >> >> On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: >> >>> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >>> >>> My mx/env contains: >>> >>> DEFAULT_VM=server >>> COMPILER_WARNINGS_FATAL=false >>> USE_CLANG=true >>> LFLAGS=-Xlinker -lstdc++ >>> USE_PRECOMPILED_HEADER=0 >>> >>> Here's the log: >>> >>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>> cd /Users/mario/Work/Eclipse/graal/make; \ >>> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> >>> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >>> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >>> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>> >>> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >>> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >>> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >>> make[4]: Nothing to be done for `all'. >>> make[4]: Nothing to be done for `all'. >>> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >>> -a "x86" != "arm" \ >>> -a "x86" != "ppc" \ >>> -a "x86" != "zero" ] ; then \ >>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >>> fi >>> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >>> echo "dtrace headers generated" >>> dtrace headers generated >>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >>> Compiling ../generated/adfiles/ad_x86_64.cpp >>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_misc.o] Error 254 >>> >>> make[4]: *** Waiting for unfinished jobs.... >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_gen.o] Error 254 >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_expand.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [abstractCompiler.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [accessFlags.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_clone.o] Error 254 >>> >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>> >>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>> >>> Target: x86_64-apple-darwin13.0.0 >>> >>> Thread model: posix >>> >>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>> >>> clang: note: diagnostic msg: >>> >>> ******************** >>> >>> >>> >>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>> >>> Preprocessed source(s) and associated run script(s) are located at: >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >>> >>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >>> >>> clang: note: diagnostic msg: >>> >>> >>> >>> ******************** >>> >>> make[4]: *** [ad_x86_64_format.o] Error 254 >>> >>> make[3]: *** [the_vm] Error 2 >>> >>> make[2]: *** [product] Error 2 >>> >>> make[1]: *** [generic_build2] Error 2 >>> >>> make: *** [product] Error 2 >>> >>> >>> >>> >>> >> > From doug.simon at oracle.com Mon Dec 23 12:19:28 2013 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 23 Dec 2013 21:19:28 +0100 Subject: Graal on Mavericks In-Reply-To: References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> Message-ID: <12FDE9D6-B545-468C-AEB5-4D8255A880EE@oracle.com> Here?s what I get: clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/dsimon/linz/basic-graal/src/share/vm/prims -I/Users/dsimon/linz/basic-graal/src/share/vm -I/Users/dsimon/linz/basic-graal/src/share/vm/precompiled -I/Users/dsimon/linz/basic-graal/src/cpu/x86/vm -I/Users/dsimon/linz/basic-graal/src/os_cpu/bsd_x86/vm -I/Users/dsimon/linz/basic-graal/src/os_gpu/bsd_ptx/vm -I/Users/dsimon/linz/basic-graal/src/os/bsd/vm -I/Users/dsimon/linz/basic-graal/src/os/posix/vm -I/Users/dsimon/linz/basic-graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b63-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"dsimon\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/dsimon/linz/basic-graal/src/share/vm/compiler/abstractCompiler.cpp The only real difference is a different HotSpot build number which comes from make/hotspot_version. This is because fast_r must not have pulled from https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/ recently. Once someone does this, try again and see if the problem goes away. Not sure what else to do at this stage - write someone at Apple a nice email? ;-) I?ve attached my output and yours with the user dir prefix replaced by $GRAAL_HOME so you can see the difference better. -Doug -------------- next part -------------- On Dec 23, 2013, at 8:56 PM, Mario Wolczko wrote: > It's failing on abtractCompiler.cpp. This is what I get: > > clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/mario/Work/Eclipse/graal/src/share/vm/prims -I/Users/mario/Work/Eclipse/graal/src/share/vm -I/Users/mario/Work/Eclipse/graal/src/share/vm/precompiled -I/Users/mario/Work/Eclipse/graal/src/cpu/x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_cpu/bsd_x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_gpu/bsd_ptx/vm -I/Users/mario/Work/Eclipse/graal/src/os/bsd/vm -I/Users/mario/Work/Eclipse/graal/src/os/posix/vm -I/Users/mario/Work/Eclipse/graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b59-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mario\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp > clang: error: unable to execute command: Segmentation fault: 11 > > Does this match the invocation you get? > > > On Dec 22, 2013, at 1:11 AM, Doug Simon wrote: > >> You can be sure it is the compilation of ad_x86_64.cpp by invoking the build as such: >> >> mx -v build -D HOTSPOT_BUILD_JOBS=1 >> >> This will also show exactly the compile command being issued. >> >> -Doug >> >> On Dec 21, 2013, at 3:02 AM, Christian Thalinger wrote: >> >>> This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? >>> >>> On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: >>> >>>> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >>>> >>>> My mx/env contains: >>>> >>>> DEFAULT_VM=server >>>> COMPILER_WARNINGS_FATAL=false >>>> USE_CLANG=true >>>> LFLAGS=-Xlinker -lstdc++ >>>> USE_PRECOMPILED_HEADER=0 >>>> >>>> Here's the log: >>>> >>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>> cd /Users/mario/Work/Eclipse/graal/make; \ >>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> >>>> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >>>> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >>>> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>> >>>> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >>>> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >>>> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >>>> make[4]: Nothing to be done for `all'. >>>> make[4]: Nothing to be done for `all'. >>>> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >>>> -a "x86" != "arm" \ >>>> -a "x86" != "ppc" \ >>>> -a "x86" != "zero" ] ; then \ >>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >>>> fi >>>> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >>>> echo "dtrace headers generated" >>>> dtrace headers generated >>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >>>> Compiling ../generated/adfiles/ad_x86_64.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>> >>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>> >>>> Target: x86_64-apple-darwin13.0.0 >>>> >>>> Thread model: posix >>>> >>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>> >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>> >>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>> >>>> Target: x86_64-apple-darwin13.0.0 >>>> >>>> Thread model: posix >>>> >>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>> >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>> >>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>> >>>> Target: x86_64-apple-darwin13.0.0 >>>> >>>> Thread model: posix >>>> >>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>> >>>> clang: note: diagnostic msg: >>>> >>>> ******************** >>>> >>>> >>>> >>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>> >>>> Preprocessed source(s) and associated run script(s) are located at: >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >>>> >>>> clang: note: diagnostic msg: >>>> >>>> >>>> >>>> ******************** >>>> >>>> make[4]: *** [ad_x86_64_misc.o] Error 254 >>>> >>>> make[4]: *** Waiting for unfinished jobs.... >>>> >>>> clang: note: diagnostic msg: >>>> >>>> ******************** >>>> >>>> >>>> >>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>> >>>> Preprocessed source(s) and associated run script(s) are located at: >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >>>> >>>> clang: note: diagnostic msg: >>>> >>>> >>>> >>>> ******************** >>>> >>>> make[4]: *** [ad_x86_64_gen.o] Error 254 >>>> >>>> clang: note: diagnostic msg: >>>> >>>> ******************** >>>> >>>> >>>> >>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>> >>>> Preprocessed source(s) and associated run script(s) are located at: >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >>>> >>>> clang: note: diagnostic msg: >>>> >>>> >>>> >>>> ******************** >>>> >>>> make[4]: *** [ad_x86_64.o] Error 254 >>>> >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>> >>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>> >>>> Target: x86_64-apple-darwin13.0.0 >>>> >>>> Thread model: posix >>>> >>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>> >>>> clang: note: diagnostic msg: >>>> >>>> ******************** >>>> >>>> >>>> >>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>> >>>> Preprocessed source(s) and associated run script(s) are located at: >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >>>> >>>> clang: note: diagnostic msg: >>>> >>>> >>>> >>>> ******************** >>>> >>>> make[4]: *** [ad_x86_64_expand.o] Error 254 >>>> >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>> >>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>> >>>> Target: x86_64-apple-darwin13.0.0 >>>> >>>> Thread model: posix >>>> >>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>> >>>> clang: note: diagnostic msg: >>>> >>>> ******************** >>>> >>>> >>>> >>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>> >>>> Preprocessed source(s) and associated run script(s) are located at: >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >>>> >>>> clang: note: diagnostic msg: >>>> >>>> >>>> >>>> ******************** >>>> >>>> make[4]: *** [abstractCompiler.o] Error 254 >>>> >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>> >>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>> >>>> Target: x86_64-apple-darwin13.0.0 >>>> >>>> Thread model: posix >>>> >>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>> >>>> clang: note: diagnostic msg: >>>> >>>> ******************** >>>> >>>> >>>> >>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>> >>>> Preprocessed source(s) and associated run script(s) are located at: >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >>>> >>>> clang: note: diagnostic msg: >>>> >>>> >>>> >>>> ******************** >>>> >>>> make[4]: *** [accessFlags.o] Error 254 >>>> >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>> >>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>> >>>> Target: x86_64-apple-darwin13.0.0 >>>> >>>> Thread model: posix >>>> >>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>> >>>> clang: note: diagnostic msg: >>>> >>>> ******************** >>>> >>>> >>>> >>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>> >>>> Preprocessed source(s) and associated run script(s) are located at: >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >>>> >>>> clang: note: diagnostic msg: >>>> >>>> >>>> >>>> ******************** >>>> >>>> make[4]: *** [ad_x86_64_clone.o] Error 254 >>>> >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>> >>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>> >>>> Target: x86_64-apple-darwin13.0.0 >>>> >>>> Thread model: posix >>>> >>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>> >>>> clang: note: diagnostic msg: >>>> >>>> ******************** >>>> >>>> >>>> >>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>> >>>> Preprocessed source(s) and associated run script(s) are located at: >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >>>> >>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >>>> >>>> clang: note: diagnostic msg: >>>> >>>> >>>> >>>> ******************** >>>> >>>> make[4]: *** [ad_x86_64_format.o] Error 254 >>>> >>>> make[3]: *** [the_vm] Error 2 >>>> >>>> make[2]: *** [product] Error 2 >>>> >>>> make[1]: *** [generic_build2] Error 2 >>>> >>>> make: *** [product] Error 2 >>>> >>>> >>>> >>>> >>>> >>> >> > From tom.deneau at amd.com Mon Dec 23 13:24:11 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Dec 2013 21:24:11 +0000 Subject: NullCheckOp Message-ID: I am trying to get null checks working on the hsail backend. What is required of NullCheckOp in the HSAILLIRGenerator? On Hsail, we can't support an implicit exception for this like amd64 does so I think we would just want to end up with an explicit compare and branch if null to something that would be similar to the code emitted for a deoptimizing node. How much of that does NullCheckOp have to do? -- Tom From tom.deneau at amd.com Mon Dec 23 13:36:53 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Mon, 23 Dec 2013 21:36:53 +0000 Subject: graalCodeInstaller questions, recording scopes, etc. In-Reply-To: <63D4172D-B61A-4314-BEA0-FB2AD4258BAF@oracle.com> References: <63D4172D-B61A-4314-BEA0-FB2AD4258BAF@oracle.com> Message-ID: > -----Original Message----- > From: Doug Simon [mailto:doug.simon at oracle.com] > Sent: Saturday, December 21, 2013 8:57 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net > Subject: Re: graalCodeInstaller questions, recording scopes, etc. > > > On Dec 20, 2013, at 3:41 PM, Deneau, Tom wrote: > > > Closing the loop again, for my original questions, adding answers > > below that were relayed in the Skype call on Thursday... > > > >> -----Original Message----- > >> From: Deneau, Tom > >> Sent: Monday, December 16, 2013 3:58 PM > >> To: graal-dev at openjdk.java.net > >> Subject: graalCodeInstaller questions, recording scopes, etc. > >> > >> Wanted to run a sketch of our plans by the rest of the graal team and > >> get some advice... > >> > >> When there are situations we cannot handle on the HSAIL backend, we > >> want to deoptimize and handle them in the interpreter. Our thoughts > >> were that at codeInstall time, we could record the various infopoints > >> in the compilationResult and then the graalCodeInstaller would then > >> record these in some way in the nmethod or in some structure that we > >> could access at runtime. Then at runtime, if a workitem requests a > >> deopt, it would save its HSAIL state, including all the appropriate > >> HSAIL registers in a place that the host side could access. > >> > >> If the JVM code that invokes the kernel sees that one or more > >> workitems have requested a deopt, for each one we could > >> > >> * map the HSAIL "PC" back to the appropriate infopoint > >> > >> * use the infopoint and the saved HSAIL registers to construct > the, > >> host-based interpreter frames > >> > >> * and then let things continue in the interpreter. > >> > >> Some questions: > >> > >> * What reason should we use for the InfopointReason? In > >> graalCodeInstaller.cpp, it seems that some types get "recorded" > >> in the debug_recorder via site_Safepoint or site_Call, while > >> others like InfopointReason::LINE_NUMBER do not. I am assuming > >> we should "record" ours but am not sure how this all plays > >> together. Can we map back to an infopoint that has not been > >> recorded? > >> > > > > Looking back we didn't really answer this question. > > I know now we do need to map to some Infopoint type that does get > recorded in ScopeDesc. > > The AMD64 backend for DeoptimizeNode issues a InfopointReason::CALL > > which is a side effect of making a Direct Foreign call. > > > > On the HSAIL side, we are not really making a foreign call and I am > > unsure of the full semantics of the other types. As an experiment I > > tried InfopointReason.IMPLICIT_EXCEPTION > > which does get recorded in the ScopeDesc thru site_Safepoint. > > But again, not sure if that is the recommendation. > > What you need is for deoptimization to record in a buffer all the values > described by a ScopeDesc that will be accessible to the subsystem that > inspects the deoptimization state (ie. where the ScopeDesc is used). > Deopt points in host compiled code will either be safepoints (e.g. > AMD64HotSpotSafepoint) or calls. On HSAIL, you need to expand on the > concept implemented in Eric's webrev[1] where code explicitly stores > state to a memory block (i.e. %_deoptInfo). This state will be at least > the HSAIL register values. I don't know what memory is used for the > stack in HSAIL, but if it is not accessible by the host or will not be > live when the host needs to access the debug info, then the values on > the stack also need to be written to the deopt info block. > Doug -- Right, I think we understand all the things we need to save. I was just curious the type of infopoint, whether we should use callInfoPoint or something that becomes a safepoint. Since we're not really calling anything, call didn't seem to make sense. But I'm not really sure what extra baggage comes along if we use something like IMPLICIT_EXCEPTION that gets recorded in graalCodeInstaller as a "safepoint". As far as really supporting safepoints on the gpu (pausing and continuing thru a safepoint), that is something we have thought about a little but it seems higher priority to get deoptimization working. For safepoints, at a high level, we would have to stop the workitems, and have them save their oops somewhere in shared memory where GC could fix them up, then restart and load up the new oops. Even just stopping all divergent workitems at a safe place and saving their state had its own challenges. Eric Caspole and Gary Frost may be able to add more on this. -- Tom > In addition, the identifier of the relevant ScopeDesc will also be > written to the deopt info block. For host execution, this is not needed > since the identifier is the program counter (pc) which is always > available to the debug info consumer. > > One thing I'm not sure about is how to handle safepoints in GPU code. > Can HSAIL/PTX code use signals? If not, we'll probably need some global > address that GPU will actively poll at safepoints. If this poll > determines safepoints are "triggered", a deoptimization path will be > taken, doing all the frame state saving mentioned above. This may be > less than ideal as it means any time safepoints are triggered (e.g. for > a garbage collection or for a biased lock revocation), all running GPU > code will be deoptimized. Or is there some mechanism for continuing GPU > code at safepoints? > > >> * Our infopoints have byteCodePositions. The ones that get > >> "recorded" go thru record_scope which has all sorts of > >> host-specific checking on the scope info. For instance, > >> get_hotspot_value will compare a register # with > >> RegisterImpl::number_of_registers (which refers to the host) and > >> if it is, assert that the type is FLOAT or DOUBLE. None of this > >> holds with HSAIL registers. What is the best way to resolve > >> this? > >> > > > > This issue will be handled by the virtualization of some of the calls > > in graalCodeInstaller that Doug will be implementing. > > -Doug > > [1] http://cr.openjdk.java.net/~ecaspole/hsail_exceptions/webrev/ From mario.wolczko at oracle.com Mon Dec 23 14:00:16 2013 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Mon, 23 Dec 2013 14:00:16 -0800 Subject: Graal on Mavericks In-Reply-To: <12FDE9D6-B545-468C-AEB5-4D8255A880EE@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> <12FDE9D6-B545-468C-AEB5-4D8255A880EE@oracle.com> Message-ID: <78D17F5C-9146-4AB4-A9F6-7C7D1D4720AE@oracle.com> fast_r is not using the latest Graal at the moment, so the build number difference is to be expected. Can you send me your .o for this file (and the .cpp, too)? At least that way I can make progress (assuming there's no significant difference between the two versions for this file). From the earlier logs it looked like clang was crashing several times, so I'll probably need a few .o's ... I'd get these from Michael H, but he's offline now until Jan. On Dec 23, 2013, at 12:19 PM, Doug Simon wrote: > Here?s what I get: > > clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/dsimon/linz/basic-graal/src/share/vm/prims -I/Users/dsimon/linz/basic-graal/src/share/vm -I/Users/dsimon/linz/basic-graal/src/share/vm/precompiled -I/Users/dsimon/linz/basic-graal/src/cpu/x86/vm -I/Users/dsimon/linz/basic-graal/src/os_cpu/bsd_x86/vm -I/Users/dsimon/linz/basic-graal/src/os_gpu/bsd_ptx/vm -I/Users/dsimon/linz/basic-graal/src/os/bsd/vm -I/Users/dsimon/linz/basic-graal/src/os/posix/vm -I/Users/dsimon/linz/basic-graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b63-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"dsimon\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/dsimon/linz/basic-graal/src/share/vm/compiler/abstractCompiler.cpp > > The only real difference is a different HotSpot build number which comes from make/hotspot_version. This is because fast_r must not have pulled from https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/ recently. Once someone does this, try again and see if the problem goes away. Not sure what else to do at this stage - write someone at Apple a nice email? ;-) > > I?ve attached my output and yours with the user dir prefix replaced by $GRAAL_HOME so you can see the difference better. > > -Doug > > > On Dec 23, 2013, at 8:56 PM, Mario Wolczko wrote: > >> It's failing on abtractCompiler.cpp. This is what I get: >> >> clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/mario/Work/Eclipse/graal/src/share/vm/prims -I/Users/mario/Work/Eclipse/graal/src/share/vm -I/Users/mario/Work/Eclipse/graal/src/share/vm/precompiled -I/Users/mario/Work/Eclipse/graal/src/cpu/x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_cpu/bsd_x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_gpu/bsd_ptx/vm -I/Users/mario/Work/Eclipse/graal/src/os/bsd/vm -I/Users/mario/Work/Eclipse/graal/src/os/posix/vm -I/Users/mario/Work/Eclipse/graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b59-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mario\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >> clang: error: unable to execute command: Segmentation fault: 11 >> >> Does this match the invocation you get? >> >> >> On Dec 22, 2013, at 1:11 AM, Doug Simon wrote: >> >>> You can be sure it is the compilation of ad_x86_64.cpp by invoking the build as such: >>> >>> mx -v build -D HOTSPOT_BUILD_JOBS=1 >>> >>> This will also show exactly the compile command being issued. >>> >>> -Doug >>> >>> On Dec 21, 2013, at 3:02 AM, Christian Thalinger wrote: >>> >>>> This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? >>>> >>>> On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: >>>> >>>>> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >>>>> >>>>> My mx/env contains: >>>>> >>>>> DEFAULT_VM=server >>>>> COMPILER_WARNINGS_FATAL=false >>>>> USE_CLANG=true >>>>> LFLAGS=-Xlinker -lstdc++ >>>>> USE_PRECOMPILED_HEADER=0 >>>>> >>>>> Here's the log: >>>>> >>>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>>> cd /Users/mario/Work/Eclipse/graal/make; \ >>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >>>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>>> >>>>> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >>>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>>> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >>>>> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >>>>> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >>>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>>> >>>>> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >>>>> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >>>>> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >>>>> make[4]: Nothing to be done for `all'. >>>>> make[4]: Nothing to be done for `all'. >>>>> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >>>>> -a "x86" != "arm" \ >>>>> -a "x86" != "ppc" \ >>>>> -a "x86" != "zero" ] ; then \ >>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >>>>> fi >>>>> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >>>>> echo "dtrace headers generated" >>>>> dtrace headers generated >>>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >>>>> Compiling ../generated/adfiles/ad_x86_64.cpp >>>>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>>>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>>>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>>>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>>>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>> >>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>> >>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>> >>>>> Target: x86_64-apple-darwin13.0.0 >>>>> >>>>> Thread model: posix >>>>> >>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>> >>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>> >>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>> >>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>> >>>>> Target: x86_64-apple-darwin13.0.0 >>>>> >>>>> Thread model: posix >>>>> >>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>> >>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>> >>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>> >>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>> >>>>> Target: x86_64-apple-darwin13.0.0 >>>>> >>>>> Thread model: posix >>>>> >>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> ******************** >>>>> >>>>> >>>>> >>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>> >>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> >>>>> >>>>> ******************** >>>>> >>>>> make[4]: *** [ad_x86_64_misc.o] Error 254 >>>>> >>>>> make[4]: *** Waiting for unfinished jobs.... >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> ******************** >>>>> >>>>> >>>>> >>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>> >>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> >>>>> >>>>> ******************** >>>>> >>>>> make[4]: *** [ad_x86_64_gen.o] Error 254 >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> ******************** >>>>> >>>>> >>>>> >>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>> >>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> >>>>> >>>>> ******************** >>>>> >>>>> make[4]: *** [ad_x86_64.o] Error 254 >>>>> >>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>> >>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>> >>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>> >>>>> Target: x86_64-apple-darwin13.0.0 >>>>> >>>>> Thread model: posix >>>>> >>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> ******************** >>>>> >>>>> >>>>> >>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>> >>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> >>>>> >>>>> ******************** >>>>> >>>>> make[4]: *** [ad_x86_64_expand.o] Error 254 >>>>> >>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>> >>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>> >>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>> >>>>> Target: x86_64-apple-darwin13.0.0 >>>>> >>>>> Thread model: posix >>>>> >>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> ******************** >>>>> >>>>> >>>>> >>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>> >>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> >>>>> >>>>> ******************** >>>>> >>>>> make[4]: *** [abstractCompiler.o] Error 254 >>>>> >>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>> >>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>> >>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>> >>>>> Target: x86_64-apple-darwin13.0.0 >>>>> >>>>> Thread model: posix >>>>> >>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> ******************** >>>>> >>>>> >>>>> >>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>> >>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> >>>>> >>>>> ******************** >>>>> >>>>> make[4]: *** [accessFlags.o] Error 254 >>>>> >>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>> >>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>> >>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>> >>>>> Target: x86_64-apple-darwin13.0.0 >>>>> >>>>> Thread model: posix >>>>> >>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> ******************** >>>>> >>>>> >>>>> >>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>> >>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> >>>>> >>>>> ******************** >>>>> >>>>> make[4]: *** [ad_x86_64_clone.o] Error 254 >>>>> >>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>> >>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>> >>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>> >>>>> Target: x86_64-apple-darwin13.0.0 >>>>> >>>>> Thread model: posix >>>>> >>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> ******************** >>>>> >>>>> >>>>> >>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>> >>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >>>>> >>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >>>>> >>>>> clang: note: diagnostic msg: >>>>> >>>>> >>>>> >>>>> ******************** >>>>> >>>>> make[4]: *** [ad_x86_64_format.o] Error 254 >>>>> >>>>> make[3]: *** [the_vm] Error 2 >>>>> >>>>> make[2]: *** [product] Error 2 >>>>> >>>>> make[1]: *** [generic_build2] Error 2 >>>>> >>>>> make: *** [product] Error 2 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > From ndrzmansn at gmail.com Mon Dec 23 14:10:23 2013 From: ndrzmansn at gmail.com (Wei Zhang) Date: Mon, 23 Dec 2013 14:10:23 -0800 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Hi Stefan, > Hm, ok. I still don?t exactly see why that is necessary. Is the frame layout different? I thought the FrameDescriptor is more or less just a declaration of what goes where, and that should be identical for inlined functions as well, no? It is the FrameSlots that need the separation. FrameDescriptor#copy() initializes the new copy with a fresh set of FrameSlots, so it does not share any state with the original one. Since, you know, a function can be invoked with different argument types.. Thanks, /Wei On Sun, Dec 22, 2013 at 3:00 AM, Stefan Marr wrote: > Hi Wei: > > On 22 Dec 2013, at 08:44, Wei Zhang wrote: > >> Hi Stefan, >> >>> The second difference I see is that you have a `prepareBodyNode()` operation that rewrites local variable access nodes. Why is that necessary? >> >> Inlined function in ZipPy has its own copy of the FrameDescriptor. I >> did this to make sure that it doesn't share any frame state with the >> original function. >> 'prepareBodyNode()' updates local variable accesses to use the new >> FrameDescriptor. >> It is just a correctness thing. > > Hm, ok. I still don?t exactly see why that is necessary. Is the frame layout different? I thought the FrameDescriptor is more or less just a declaration of what goes where, and that should be identical for inlined functions as well, no? > >> I'm actually curious about how easy/difficult was it for you to use RPython? >> Compare to Truffle was it easier to get the performance that you are >> happy with? or you also got some help from the PyPy guys? > > Well, there were a couple of phases, that are different from my work on TruffleSOM. > RPython is different enough from Python so that it took some work to get the interpreter running. There are a couple of things the type inference requires help with for instance lambdas need to be put in a scope static enough to be analyzable, and a stricter language for instance tuples and lists are not exchangeable, and another set of libraries. So some minor functionality such as reading from the REPL had to be implemented differently. > > For that, the RPython error messages were useful ?enough?, but I also got a hand from a colleague who has been using RPython for a while, and had been involved with SOM before. > > After that was done, I worked a bit on the object model of SOM. Especially in areas that were useful for TruffleSOM as well. So, actually, I changed the language a bit and hid more implementation details of the object layout behind methods (primitives) instead of representing them by fields in the objects. > > The third phase was then to add RPythons annotations throughout the code in order to communicate to the tracer what is constant, what is not going to change in the context of a trace, where to look for trace starts etc. And here, I actually got a hand from one of the core RPython guys, who had a look at the code and did the collect all the low hanging fruit. > Looking at his changes, many of them I could have done based on good document, and guidelines, I think. But some of them are experience I would say. > > If you are curious for the details, have a look at: > https://github.com/SOM-st/RPySOM/commits/non-recursive-with-jumps > > The changes by Carl Friedrich Bolz (cfbolz) around October 21st are probably most interesting for the performance. > > As a current result, the last time I measured, DeltaBlue wasn?t to far off from the PyPy numbers anymore. > And at the moment, we expect to still get a little more out of RPySOM. > I made the interpreter recursive, similar to the basic execution model in Truffle, which should give the tracer some more context. But currently we are hitting some problems, because that approach requires at least two general points for trace starts. One in the interpreter loop, and one in the loop primitives. However, that?s something not commonly used in other RPython languages, and it seems to be broken. So, for very recursive programs it doesn?t work that well, while benchmarks with loops benefit from this change a lot. > > Best regards > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > From christian.thalinger at oracle.com Mon Dec 23 18:45:13 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 23 Dec 2013 18:45:13 -0800 Subject: NullCheckOp In-Reply-To: References: Message-ID: I?m not an expert on this but it seems that a NullCheckOp (or a NullCheckNode) only does an implicit null check; there is no branch information attached to it. In order to do an explicit exception you?d need to add nodes to the graph that throw the exception. Not sure if something like this exists already. On Dec 23, 2013, at 1:24 PM, Deneau, Tom wrote: > I am trying to get null checks working on the hsail backend. > What is required of NullCheckOp in the HSAILLIRGenerator? > On Hsail, we can't support an implicit exception for this like amd64 does so I think we would just want to end up with an explicit compare and branch if null to something that would be similar to the code emitted for a deoptimizing node. How much of that does NullCheckOp have to do? > > -- Tom From java at stefan-marr.de Tue Dec 24 02:38:43 2013 From: java at stefan-marr.de (Stefan Marr) Date: Tue, 24 Dec 2013 11:38:43 +0100 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: Hi Chris: On 23 Dec 2013, at 16:41, Chris Seaton wrote: > Non-local returns in Ruby: > > Each method has a unique identifier allocated in the parser. The throw nodes also store this integer, and they put it into the ReturnException when they construct it. Then the ReturnException handlers check if the exception is meant for them, and if it?s not they re-throw it. Ehm, does that work? Perhaps you are simplifying your explanation, but that sounds problematic for recursion. In TruffleSOM, I implemented that part with a FrameOnStackMarker that is part of the Arguments object. The ReturnException looks it up by walking the chain of lexical contexts and compares it when caught. That way, it?s definitely the correct dynamic point to return to. > In Ruby it's very common to go through at least one scope like this - returns in a block within a method return from the method, not the block, even though the block is really a method in its own right. When the exception is finally caught I just return it as the return value from the execute method and it becomes a normal returned value. > > Note that in Ruby the return handler is a node all on its own. This logic isn't in RubyRootNode, RubyMethod, or the send node, like it looks like you are here. Methods which need it have a CatchReturnNode in their prelude. I also use this technique for things like checking that the number of arguments is correct. > > Then nodes which don?t ever catch returns, like blocks, don't even have this node to begin with. Good, that?s what I was looking for. I am still missing a bit the intuition when to create nodes, but I think I am slowly getting there. I also created such a catch node now in TruffleSOM. Works ok, and makes inlining simple as well. Thanks! Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From chris at chrisseaton.com Tue Dec 24 05:37:26 2013 From: chris at chrisseaton.com (Chris Seaton) Date: Tue, 24 Dec 2013 13:37:26 +0000 Subject: ZipPy status update In-Reply-To: References: <3B7840B6-BA81-4326-99BB-FED8DC172543@stefan-marr.de> Message-ID: On 24 December 2013 10:38, Stefan Marr wrote: On 23 Dec 2013, at 16:41, Chris Seaton wrote: > > > Non-local returns in Ruby: > > > > Each method has a unique identifier allocated in the parser. The throw > nodes also store this integer, and they put it into the ReturnException > when they construct it. Then the ReturnException handlers check if the > exception is meant for them, and if it?s not they re-throw it. > > Ehm, does that work? Perhaps you are simplifying your explanation, but > that sounds problematic for recursion. In TruffleSOM, I implemented that > part with a FrameOnStackMarker that is part of the Arguments object. The > ReturnException looks it up by walking the chain of lexical contexts and > compares it when caught. That way, it?s definitely the correct dynamic > point to return to. I investigated with a case that puts an activation in between the lexical return point and the return statement, and you're right it doesn't work as you might expect. However, it does pass all the relevant return tests in RubySpec, so I don't know if it's a bug or not. def run(&block) foo(block) puts "also doesn't reach here" end def foo(f) if f == nil run do return 14 end puts "doesn't reach here" else f.call end end puts foo(nil) I believe this should print 14 (but who really knows in Ruby), but both the 'doesn't reach here' lines are executed. Chris From tom.deneau at amd.com Tue Dec 24 10:31:50 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Tue, 24 Dec 2013 18:31:50 +0000 Subject: LIRFrameStates Message-ID: In the compilation of our Mandelbrot method test case (java code shown below), I noticed that besides the LIRFrameState for bci=0, there was also one created * the beginning of the while loop * the beginning of the first statement after the while loop so an exception detected at the final statement would use the LIRFrameState for the beginning of the first statement after the while loop. >From my reading of the http://design.cs.iastate.edu/vmil/2013/papers/p04-Duboscq.pdf paper, I would have thought that new LIRFrameStates are needed only when there is a bytecode with side effects, and I don't see any side effects until we get to the final java line. So just curious why were the two other LIRFrameStates created? -- Tom ============================= public static void run(int[] rgb, int[] pallette, float xoffset, float yoffset, float scale, int gid) { final int width = initWidth; final int height = initHeight; float lx = (((gid % width * scale) - ((scale / 2) * width)) / width) + xoffset; float ly = (((gid / width * scale) - ((scale / 2) * height)) / height) + yoffset; int count = 0; float zx = lx; float zy = ly; float newzx = 0f; // Iterate until the algorithm converges or until maxIterations are reached. while (count < maxIterations && zx * zx + zy * zy < 8) { newzx = zx * zx - zy * zy + lx; zy = 2 * zx * zy + ly; zx = newzx; count++; } rgb[gid + 1] = pallette[count]; // will cause exception on last of range } From mario.wolczko at oracle.com Tue Dec 24 12:26:17 2013 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Tue, 24 Dec 2013 12:26:17 -0800 Subject: Graal on Mavericks In-Reply-To: <78D17F5C-9146-4AB4-A9F6-7C7D1D4720AE@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> <12FDE9D6-B545-468C-AEB5-4D8255A880EE@oracle.com> <78D17F5C-9146-4AB4-A9F6-7C7D1D4720AE@oracle.com> Message-ID: <1CD8F7CA-A597-404B-A697-39BACB329D97@oracle.com> Problem solved. Long, long ago for some forgotten but undoubtedly sound reason I added the line ulimit -s 1528 to my ksh startup config (limiting the stack size to 1.5MB). Removing that line cures the problem. On Dec 23, 2013, at 2:00 PM, Mario Wolczko wrote: > fast_r is not using the latest Graal at the moment, so the build number difference is to be expected. > > Can you send me your .o for this file (and the .cpp, too)? At least that way I can make progress (assuming there's no significant difference between the two versions for this file). From the earlier logs it looked like clang was crashing several times, so I'll probably need a few .o's ... I'd get these from Michael H, but he's offline now until Jan. > > > On Dec 23, 2013, at 12:19 PM, Doug Simon wrote: > >> Here?s what I get: >> >> clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/dsimon/linz/basic-graal/src/share/vm/prims -I/Users/dsimon/linz/basic-graal/src/share/vm -I/Users/dsimon/linz/basic-graal/src/share/vm/precompiled -I/Users/dsimon/linz/basic-graal/src/cpu/x86/vm -I/Users/dsimon/linz/basic-graal/src/os_cpu/bsd_x86/vm -I/Users/dsimon/linz/basic-graal/src/os_gpu/bsd_ptx/vm -I/Users/dsimon/linz/basic-graal/src/os/bsd/vm -I/Users/dsimon/linz/basic-graal/src/os/posix/vm -I/Users/dsimon/linz/basic-graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b63-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"dsimon\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/dsimon/linz/basic-graal/src/share/vm/compiler/abstractCompiler.cpp >> >> The only real difference is a different HotSpot build number which comes from make/hotspot_version. This is because fast_r must not have pulled from https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/ recently. Once someone does this, try again and see if the problem goes away. Not sure what else to do at this stage - write someone at Apple a nice email? ;-) >> >> I?ve attached my output and yours with the user dir prefix replaced by $GRAAL_HOME so you can see the difference better. >> >> -Doug >> >> >> On Dec 23, 2013, at 8:56 PM, Mario Wolczko wrote: >> >>> It's failing on abtractCompiler.cpp. This is what I get: >>> >>> clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/mario/Work/Eclipse/graal/src/share/vm/prims -I/Users/mario/Work/Eclipse/graal/src/share/vm -I/Users/mario/Work/Eclipse/graal/src/share/vm/precompiled -I/Users/mario/Work/Eclipse/graal/src/cpu/x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_cpu/bsd_x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_gpu/bsd_ptx/vm -I/Users/mario/Work/Eclipse/graal/src/os/bsd/vm -I/Users/mario/Work/Eclipse/graal/src/os/posix/vm -I/Users/mario/Work/Eclipse/graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b59-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mario\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> Does this match the invocation you get? >>> >>> >>> On Dec 22, 2013, at 1:11 AM, Doug Simon wrote: >>> >>>> You can be sure it is the compilation of ad_x86_64.cpp by invoking the build as such: >>>> >>>> mx -v build -D HOTSPOT_BUILD_JOBS=1 >>>> >>>> This will also show exactly the compile command being issued. >>>> >>>> -Doug >>>> >>>> On Dec 21, 2013, at 3:02 AM, Christian Thalinger wrote: >>>> >>>>> This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? >>>>> >>>>> On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: >>>>> >>>>>> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >>>>>> >>>>>> My mx/env contains: >>>>>> >>>>>> DEFAULT_VM=server >>>>>> COMPILER_WARNINGS_FATAL=false >>>>>> USE_CLANG=true >>>>>> LFLAGS=-Xlinker -lstdc++ >>>>>> USE_PRECOMPILED_HEADER=0 >>>>>> >>>>>> Here's the log: >>>>>> >>>>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>>>> cd /Users/mario/Work/Eclipse/graal/make; \ >>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >>>>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>>>> >>>>>> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >>>>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>>>> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >>>>>> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >>>>>> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >>>>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>>>> >>>>>> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >>>>>> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >>>>>> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >>>>>> make[4]: Nothing to be done for `all'. >>>>>> make[4]: Nothing to be done for `all'. >>>>>> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >>>>>> -a "x86" != "arm" \ >>>>>> -a "x86" != "ppc" \ >>>>>> -a "x86" != "zero" ] ; then \ >>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >>>>>> fi >>>>>> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >>>>>> echo "dtrace headers generated" >>>>>> dtrace headers generated >>>>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>>>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_misc.o] Error 254 >>>>>> >>>>>> make[4]: *** Waiting for unfinished jobs.... >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_gen.o] Error 254 >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_expand.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [abstractCompiler.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [accessFlags.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_clone.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_format.o] Error 254 >>>>>> >>>>>> make[3]: *** [the_vm] Error 2 >>>>>> >>>>>> make[2]: *** [product] Error 2 >>>>>> >>>>>> make[1]: *** [generic_build2] Error 2 >>>>>> >>>>>> make: *** [product] Error 2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From mario.wolczko at oracle.com Tue Dec 24 12:26:17 2013 From: mario.wolczko at oracle.com (Mario Wolczko) Date: Tue, 24 Dec 2013 12:26:17 -0800 Subject: Graal on Mavericks In-Reply-To: <78D17F5C-9146-4AB4-A9F6-7C7D1D4720AE@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> <12FDE9D6-B545-468C-AEB5-4D8255A880EE@oracle.com> <78D17F5C-9146-4AB4-A9F6-7C7D1D4720AE@oracle.com> Message-ID: <4C7996D0-FACC-4283-A9EF-3D4DB60AA3EC@oracle.com> Problem solved. Long, long ago for some forgotten but undoubtedly sound reason I added the line ulimit -s 1528 to my ksh startup config (limiting the stack size to 1.5MB). Removing that line cures the problem. On Dec 23, 2013, at 2:00 PM, Mario Wolczko wrote: > fast_r is not using the latest Graal at the moment, so the build number difference is to be expected. > > Can you send me your .o for this file (and the .cpp, too)? At least that way I can make progress (assuming there's no significant difference between the two versions for this file). From the earlier logs it looked like clang was crashing several times, so I'll probably need a few .o's ... I'd get these from Michael H, but he's offline now until Jan. > > > On Dec 23, 2013, at 12:19 PM, Doug Simon wrote: > >> Here?s what I get: >> >> clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/dsimon/linz/basic-graal/src/share/vm/prims -I/Users/dsimon/linz/basic-graal/src/share/vm -I/Users/dsimon/linz/basic-graal/src/share/vm/precompiled -I/Users/dsimon/linz/basic-graal/src/cpu/x86/vm -I/Users/dsimon/linz/basic-graal/src/os_cpu/bsd_x86/vm -I/Users/dsimon/linz/basic-graal/src/os_gpu/bsd_ptx/vm -I/Users/dsimon/linz/basic-graal/src/os/bsd/vm -I/Users/dsimon/linz/basic-graal/src/os/posix/vm -I/Users/dsimon/linz/basic-graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b63-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"dsimon\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/dsimon/linz/basic-graal/src/share/vm/compiler/abstractCompiler.cpp >> >> The only real difference is a different HotSpot build number which comes from make/hotspot_version. This is because fast_r must not have pulled from https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/ recently. Once someone does this, try again and see if the problem goes away. Not sure what else to do at this stage - write someone at Apple a nice email? ;-) >> >> I?ve attached my output and yours with the user dir prefix replaced by $GRAAL_HOME so you can see the difference better. >> >> -Doug >> >> >> On Dec 23, 2013, at 8:56 PM, Mario Wolczko wrote: >> >>> It's failing on abtractCompiler.cpp. This is what I get: >>> >>> clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/mario/Work/Eclipse/graal/src/share/vm/prims -I/Users/mario/Work/Eclipse/graal/src/share/vm -I/Users/mario/Work/Eclipse/graal/src/share/vm/precompiled -I/Users/mario/Work/Eclipse/graal/src/cpu/x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_cpu/bsd_x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_gpu/bsd_ptx/vm -I/Users/mario/Work/Eclipse/graal/src/os/bsd/vm -I/Users/mario/Work/Eclipse/graal/src/os/posix/vm -I/Users/mario/Work/Eclipse/graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b59-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mario\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>> clang: error: unable to execute command: Segmentation fault: 11 >>> >>> Does this match the invocation you get? >>> >>> >>> On Dec 22, 2013, at 1:11 AM, Doug Simon wrote: >>> >>>> You can be sure it is the compilation of ad_x86_64.cpp by invoking the build as such: >>>> >>>> mx -v build -D HOTSPOT_BUILD_JOBS=1 >>>> >>>> This will also show exactly the compile command being issued. >>>> >>>> -Doug >>>> >>>> On Dec 21, 2013, at 3:02 AM, Christian Thalinger wrote: >>>> >>>>> This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? >>>>> >>>>> On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: >>>>> >>>>>> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >>>>>> >>>>>> My mx/env contains: >>>>>> >>>>>> DEFAULT_VM=server >>>>>> COMPILER_WARNINGS_FATAL=false >>>>>> USE_CLANG=true >>>>>> LFLAGS=-Xlinker -lstdc++ >>>>>> USE_PRECOMPILED_HEADER=0 >>>>>> >>>>>> Here's the log: >>>>>> >>>>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>>>> cd /Users/mario/Work/Eclipse/graal/make; \ >>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >>>>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>>>> >>>>>> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >>>>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>>>> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >>>>>> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >>>>>> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >>>>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>>>> >>>>>> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >>>>>> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >>>>>> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >>>>>> make[4]: Nothing to be done for `all'. >>>>>> make[4]: Nothing to be done for `all'. >>>>>> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >>>>>> -a "x86" != "arm" \ >>>>>> -a "x86" != "ppc" \ >>>>>> -a "x86" != "zero" ] ; then \ >>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >>>>>> fi >>>>>> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >>>>>> echo "dtrace headers generated" >>>>>> dtrace headers generated >>>>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>>>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>>>>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_misc.o] Error 254 >>>>>> >>>>>> make[4]: *** Waiting for unfinished jobs.... >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_gen.o] Error 254 >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_expand.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [abstractCompiler.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [accessFlags.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_clone.o] Error 254 >>>>>> >>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>> >>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>> >>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>> >>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>> >>>>>> Thread model: posix >>>>>> >>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> ******************** >>>>>> >>>>>> >>>>>> >>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>> >>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >>>>>> >>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >>>>>> >>>>>> clang: note: diagnostic msg: >>>>>> >>>>>> >>>>>> >>>>>> ******************** >>>>>> >>>>>> make[4]: *** [ad_x86_64_format.o] Error 254 >>>>>> >>>>>> make[3]: *** [the_vm] Error 2 >>>>>> >>>>>> make[2]: *** [product] Error 2 >>>>>> >>>>>> make[1]: *** [generic_build2] Error 2 >>>>>> >>>>>> make: *** [product] Error 2 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From doug.simon at oracle.com Wed Dec 25 07:37:49 2013 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 25 Dec 2013 16:37:49 +0100 Subject: LIRFrameStates In-Reply-To: References: Message-ID: On Dec 24, 2013, at 7:31 PM, Deneau, Tom wrote: > In the compilation of our Mandelbrot method test case (java code shown below), I noticed that besides the LIRFrameState for bci=0, there was also one created > * the beginning of the while loop > * the beginning of the first statement after the while loop > > so an exception detected at the final statement would use the LIRFrameState for the beginning of the first statement after the while loop. > >> From my reading of the http://design.cs.iastate.edu/vmil/2013/papers/p04-Duboscq.pdf paper, I would have thought that new LIRFrameStates are needed only when there is a bytecode with side effects, and I don't see any side effects until we get to the final java line. So just curious why were the two other LIRFrameStates created? The frame state at the beginning of the loop is for placing a safepoint in the loop. The second frame state is there to account for the fact that execution can restart before the array load instruction. -Doug > ============================= > public static void run(int[] rgb, int[] pallette, float xoffset, float yoffset, float scale, int gid) { > final int width = initWidth; > final int height = initHeight; > float lx = (((gid % width * scale) - ((scale / 2) * width)) / width) + xoffset; > float ly = (((gid / width * scale) - ((scale / 2) * height)) / height) + yoffset; > int count = 0; > float zx = lx; > float zy = ly; > float newzx = 0f; > > // Iterate until the algorithm converges or until maxIterations are reached. > while (count < maxIterations && zx * zx + zy * zy < 8) { > newzx = zx * zx - zy * zy + lx; > zy = 2 * zx * zy + ly; > zx = newzx; > count++; > } > rgb[gid + 1] = pallette[count]; // will cause exception on last of range > } > From christian.thalinger at oracle.com Wed Dec 25 11:47:29 2013 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 25 Dec 2013 11:47:29 -0800 Subject: Graal on Mavericks In-Reply-To: <1CD8F7CA-A597-404B-A697-39BACB329D97@oracle.com> References: <0A90EF8F-93C9-4A16-9A6A-A6A1F9230EFC@jku.at> <52968F9B.8060501@oracle.com> <5296BEDF.8010004@Oracle.COM> <018D989F-90D1-4F1F-A039-FC7259F0FBB6@oracle.com> <12FDE9D6-B545-468C-AEB5-4D8255A880EE@oracle.com> <78D17F5C-9146-4AB4-A9F6-7C7D1D4720AE@oracle.com> <1CD8F7CA-A597-404B-A697-39BACB329D97@oracle.com> Message-ID: <3A4FB52F-7FB2-4B55-A271-204ABFA298E7@oracle.com> On Dec 24, 2013, at 12:26 PM, Mario Wolczko wrote: > Problem solved. Long, long ago for some forgotten but undoubtedly sound reason I added the line > ulimit -s 1528 > to my ksh startup config (limiting the stack size to 1.5MB). Removing that line cures the problem. :-) > > > On Dec 23, 2013, at 2:00 PM, Mario Wolczko wrote: > >> fast_r is not using the latest Graal at the moment, so the build number difference is to be expected. >> >> Can you send me your .o for this file (and the .cpp, too)? At least that way I can make progress (assuming there's no significant difference between the two versions for this file). From the earlier logs it looked like clang was crashing several times, so I'll probably need a few .o's ... I'd get these from Michael H, but he's offline now until Jan. >> >> >> On Dec 23, 2013, at 12:19 PM, Doug Simon wrote: >> >>> Here?s what I get: >>> >>> clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/dsimon/linz/basic-graal/src/share/vm/prims -I/Users/dsimon/linz/basic-graal/src/share/vm -I/Users/dsimon/linz/basic-graal/src/share/vm/precompiled -I/Users/dsimon/linz/basic-graal/src/cpu/x86/vm -I/Users/dsimon/linz/basic-graal/src/os_cpu/bsd_x86/vm -I/Users/dsimon/linz/basic-graal/src/os_gpu/bsd_ptx/vm -I/Users/dsimon/linz/basic-graal/src/os/bsd/vm -I/Users/dsimon/linz/basic-graal/src/os/posix/vm -I/Users/dsimon/linz/basic-graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b63-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"dsimon\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/dsimon/linz/basic-graal/src/share/vm/compiler/abstractCompiler.cpp >>> >>> The only real difference is a different HotSpot build number which comes from make/hotspot_version. This is because fast_r must not have pulled from https://lafo.ssw.uni-linz.ac.at/hg/basic-graal/ recently. Once someone does this, try again and see if the problem goes away. Not sure what else to do at this stage - write someone at Apple a nice email? ;-) >>> >>> I?ve attached my output and yours with the user dir prefix replaced by $GRAAL_HOME so you can see the difference better. >>> >>> -Doug >>> >>> >>> On Dec 23, 2013, at 8:56 PM, Mario Wolczko wrote: >>> >>>> It's failing on abtractCompiler.cpp. This is what I get: >>>> >>>> clang++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DAMD64 -DPRODUCT -I/Users/mario/Work/Eclipse/graal/src/share/vm/prims -I/Users/mario/Work/Eclipse/graal/src/share/vm -I/Users/mario/Work/Eclipse/graal/src/share/vm/precompiled -I/Users/mario/Work/Eclipse/graal/src/cpu/x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_cpu/bsd_x86/vm -I/Users/mario/Work/Eclipse/graal/src/os_gpu/bsd_ptx/vm -I/Users/mario/Work/Eclipse/graal/src/os/bsd/vm -I/Users/mario/Work/Eclipse/graal/src/os/posix/vm -I/Users/mario/Work/Eclipse/graal/src/gpu -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.0-b59-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mario\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DTARGET_OS_FAMILY_bsd -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_bsd_x86 -DTARGET_OS_ARCH_MODEL_bsd_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -DGRAAL -DDONT_USE_PRECOMPILED_HEADER -fPIC -fno-rtti -fno-exceptions -fvisibility=hidden -m64 -mno-omit-leaf-frame-pointer -mstack-alignment=16 -pipe -fno-strict-aliasing -stdlib=libc++ -DDONT_USE_PRECOMPILED_HEADER -DMAC_OS_X_VERSION_MAX_ALLOWED=1070 -mmacosx-version-min=10.7.0 -flimit-debug-info -Os -g -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Wno-logical-op-parentheses -Wno-parentheses-equality -Wno-parentheses -Wno-switch -Wno-tautological-compare -Wno-delete-non-virtual-dtor -Wno-deprecated -Wno-format -Wno-dynamic-class-memaccess -Wno-empty-body -Wpointer-arith -Wsign-compare -Wundef -DDTRACE_ENABLED -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -MMD -MP -MF ../generated/dependencies/abstractCompiler.o.d -o abstractCompiler.o /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>>> clang: error: unable to execute command: Segmentation fault: 11 >>>> >>>> Does this match the invocation you get? >>>> >>>> >>>> On Dec 22, 2013, at 1:11 AM, Doug Simon wrote: >>>> >>>>> You can be sure it is the compilation of ad_x86_64.cpp by invoking the build as such: >>>>> >>>>> mx -v build -D HOTSPOT_BUILD_JOBS=1 >>>>> >>>>> This will also show exactly the compile command being issued. >>>>> >>>>> -Doug >>>>> >>>>> On Dec 21, 2013, at 3:02 AM, Christian Thalinger wrote: >>>>> >>>>>> This is odd. I?m building HotSpot on Mavericks with the same clang compiler as yours but I?ve never seen this problem. It looks like clang crashes trying to compile ad_x86_64.cpp which is a huge file. Does it happen every time? >>>>>> >>>>>> On Dec 20, 2013, at 5:52 PM, Mario Wolczko wrote: >>>>>> >>>>>>> I'm getting my build environment going again since upgrading to Mavericks. I'm getting a clang crash while compiling HotSpot - anyone seen this and know the fix? This is while building the graal version associated with fast_r. >>>>>>> >>>>>>> My mx/env contains: >>>>>>> >>>>>>> DEFAULT_VM=server >>>>>>> COMPILER_WARNINGS_FATAL=false >>>>>>> USE_CLANG=true >>>>>>> LFLAGS=-Xlinker -lstdc++ >>>>>>> USE_PRECOMPILED_HEADER=0 >>>>>>> >>>>>>> Here's the log: >>>>>>> >>>>>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>>>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>>>>> cd /Users/mario/Work/Eclipse/graal/make; \ >>>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make BUILD_DIR=/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2 BUILD_FLAVOR=product VM_TARGET=product generic_build2 >>>>>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>>>>> >>>>>>> python2.7 -u /Users/mario/Work/Eclipse/graal/mxtool/mx.py build --no-native --export-dir /Users/mario/Work/Eclipse/graal/build/bsd/shared >>>>>>> Excluding com.oracle.graal.api.meta.jdk8.test from build (Java compliance level 1.8 required) >>>>>>> Excluding com.oracle.graal.hotspot.jdk8.test from build (Java compliance level 1.8 required) >>>>>>> mkdir -p /Users/mario/Work/Eclipse/graal/build/bsd >>>>>>> cd /Users/mario/Work/Eclipse/graal/build/bsd; \ >>>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f /Users/mario/Work/Eclipse/graal/make/bsd/Makefile \ >>>>>>> LP64=1 MACOSX_UNIVERSAL=true BOOTDIR=/Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home OUTPUTDIR=/Users/mario/Work/Eclipse/graal/build/bsd GAMMADIR=/Users/mario/Work/Eclipse/graal MAKE_VERBOSE= HOTSPOT_RELEASE_VERSION=25.0-b59 JRE_RELEASE_VERSION="1.8.0" HOTSPOT_BUILD_VERSION=internal product >>>>>>> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >>>>>>> >>>>>>> cd bsd_amd64_compiler2/product && /Applications/Xcode.app/Contents/Developer/usr/bin/make " LP64=1 " >>>>>>> /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product >>>>>>> Rescanned ../generated/adfiles/bsd_x86_64.ad but encountered no changes. >>>>>>> make[4]: Nothing to be done for `all'. >>>>>>> make[4]: Nothing to be done for `all'. >>>>>>> if [ -d /Users/mario/Work/Eclipse/graal/agent -a "x86" != "ia64" \ >>>>>>> -a "x86" != "arm" \ >>>>>>> -a "x86" != "ppc" \ >>>>>>> -a "x86" != "zero" ] ; then \ >>>>>>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -f sa.make /Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar; \ >>>>>>> fi >>>>>>> make[5]: `/Users/mario/Work/Eclipse/graal/build/bsd/bsd_amd64_compiler2/product/../generated/sa-jdi.jar' is up to date. >>>>>>> echo "dtrace headers generated" >>>>>>> dtrace headers generated >>>>>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/compiler/abstractCompiler.cpp >>>>>>> Compiling /Users/mario/Work/Eclipse/graal/src/share/vm/utilities/accessFlags.cpp >>>>>>> Compiling ../generated/adfiles/ad_x86_64.cpp >>>>>>> Compiling ../generated/adfiles/ad_x86_64_clone.cpp >>>>>>> Compiling ../generated/adfiles/ad_x86_64_expand.cpp >>>>>>> Compiling ../generated/adfiles/ad_x86_64_format.cpp >>>>>>> Compiling ../generated/adfiles/ad_x86_64_gen.cpp >>>>>>> Compiling ../generated/adfiles/ad_x86_64_misc.cpp >>>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>>> >>>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>>> >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> >>>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>>> >>>>>>> Thread model: posix >>>>>>> >>>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>>> >>>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>>> >>>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>>> >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> >>>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>>> >>>>>>> Thread model: posix >>>>>>> >>>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>>> >>>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>>> >>>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>>> >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> >>>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>>> >>>>>>> Thread model: posix >>>>>>> >>>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> >>>>>>> >>>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>>> >>>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.cpp >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_misc-Gp9I3v.sh >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> make[4]: *** [ad_x86_64_misc.o] Error 254 >>>>>>> >>>>>>> make[4]: *** Waiting for unfinished jobs.... >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> >>>>>>> >>>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>>> >>>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.cpp >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_gen-m6LuAu.sh >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> make[4]: *** [ad_x86_64_gen.o] Error 254 >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> >>>>>>> >>>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>>> >>>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.cpp >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64-xGEQOn.sh >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> make[4]: *** [ad_x86_64.o] Error 254 >>>>>>> >>>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>>> >>>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>>> >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> >>>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>>> >>>>>>> Thread model: posix >>>>>>> >>>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> >>>>>>> >>>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>>> >>>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.cpp >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_expand-nHh9gT.sh >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> make[4]: *** [ad_x86_64_expand.o] Error 254 >>>>>>> >>>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>>> >>>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>>> >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> >>>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>>> >>>>>>> Thread model: posix >>>>>>> >>>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> >>>>>>> >>>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>>> >>>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.cpp >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/abstractCompiler-D5yMGV.sh >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> make[4]: *** [abstractCompiler.o] Error 254 >>>>>>> >>>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>>> >>>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>>> >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> >>>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>>> >>>>>>> Thread model: posix >>>>>>> >>>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> >>>>>>> >>>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>>> >>>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.cpp >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/accessFlags-Qe6EXv.sh >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> make[4]: *** [accessFlags.o] Error 254 >>>>>>> >>>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>>> >>>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>>> >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> >>>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>>> >>>>>>> Thread model: posix >>>>>>> >>>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> >>>>>>> >>>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>>> >>>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.cpp >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_clone-ZZQteN.sh >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> make[4]: *** [ad_x86_64_clone.o] Error 254 >>>>>>> >>>>>>> clang: error: unable to execute command: Segmentation fault: 11 >>>>>>> >>>>>>> clang: error: clang frontend command failed due to signal (use -v to see invocation) >>>>>>> >>>>>>> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) >>>>>>> >>>>>>> Target: x86_64-apple-darwin13.0.0 >>>>>>> >>>>>>> Thread model: posix >>>>>>> >>>>>>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script. >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> >>>>>>> >>>>>>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: >>>>>>> >>>>>>> Preprocessed source(s) and associated run script(s) are located at: >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.cpp >>>>>>> >>>>>>> clang: note: diagnostic msg: /var/folders/6f/v22tl__c8xj4030059bb3q1r000rbc/T/ad_x86_64_format-1WEK2i.sh >>>>>>> >>>>>>> clang: note: diagnostic msg: >>>>>>> >>>>>>> >>>>>>> >>>>>>> ******************** >>>>>>> >>>>>>> make[4]: *** [ad_x86_64_format.o] Error 254 >>>>>>> >>>>>>> make[3]: *** [the_vm] Error 2 >>>>>>> >>>>>>> make[2]: *** [product] Error 2 >>>>>>> >>>>>>> make[1]: *** [generic_build2] Error 2 >>>>>>> >>>>>>> make: *** [product] Error 2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From miguelalfredo.garcia at epfl.ch Thu Dec 26 13:18:35 2013 From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo) Date: Thu, 26 Dec 2013 21:18:35 +0000 Subject: additional unproxying that shouldn't hurt Message-ID: <7E4228B446372948BBB2916FC53FA49E26DFC037@REXMD.intranet.epfl.ch> I'm looking into Graal again, following the usual trail: GraphBuilderPhase, ConditionalEliminationPhase, and so on so forth. Regarding ConditionalEliminationPhase, the keys of `State.knownNonNull` (resp `knownNull`) must be in "unproxified form", at least that's what the following helper method suggests: public boolean isNull(ValueNode value) { return ObjectStamp.isObjectAlwaysNull(value) || knownNull.contains(GraphUtil.unproxify(value)); } Using that helper method is simple: the argument need not be un-proxified beforehand. In contrast, when directly querying the underlying map (using `contains` resp `containsKey`), the caller must unproxify the argument, right? Well, assuming the above, the following diff shows two places where unproxying appears to be necessary. In any case, it shouldn't hurt :) diff -r 72e2ec923b7b graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java --- a/graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Sat Dec 21 13:47:36 2013 +0100 +++ b/graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Thu Dec 26 22:05:23 2013 +0100 @@ -160,14 +160,14 @@ if (!(merge instanceof LoopBeginNode)) { for (PhiNode phi : merge.phis()) { if (phi.type() == PhiType.Value && phi.kind() == Kind.Object) { - ValueNode firstValue = phi.valueAt(0); + ValueNode firstValue = GraphUtil.unproxify(phi.valueAt(0)); ResolvedJavaType type = getNodeType(firstValue); boolean nonNull = knownNonNull.contains(firstValue); boolean isNull = knownNull.contains(firstValue); for (int i = 0; i < withStates.size(); i++) { State otherState = withStates.get(i); - ValueNode value = phi.valueAt(i + 1); + ValueNode value = GraphUtil.unproxify(phi.valueAt(i + 1)); ResolvedJavaType otherType = otherState.getNodeType(value); type = widen(type, otherType); nonNull &= otherState.knownNonNull.contains(value); Miguel -- Miguel Garcia Swiss Federal Institute of Technology EPFL - IC - LAMP1 - INR 328 - Station 14 CH-1015 Lausanne - Switzerland http://lamp.epfl.ch/~magarcia/ From thomas.wuerthinger at oracle.com Sat Dec 28 04:40:44 2013 From: thomas.wuerthinger at oracle.com (Thomas Wuerthinger) Date: Sat, 28 Dec 2013 13:40:44 +0100 Subject: NullCheckOp In-Reply-To: References: Message-ID: <967BFE02-87CC-46B9-9D6B-4E5B4934E3B9@oracle.com> Tom, The flag ?OptImplicitNullChecks? controls whether the compiler tries to create implicit null check instructions. If you set it to false, the code generated is equivalent to a comparison of the value against null and a deoptimization if the comparison yields true. - thomas On 24 Dec 2013, at 03:45, Christian Thalinger wrote: > I?m not an expert on this but it seems that a NullCheckOp (or a NullCheckNode) only does an implicit null check; there is no branch information attached to it. > > In order to do an explicit exception you?d need to add nodes to the graph that throw the exception. Not sure if something like this exists already. > > On Dec 23, 2013, at 1:24 PM, Deneau, Tom wrote: > >> I am trying to get null checks working on the hsail backend. >> What is required of NullCheckOp in the HSAILLIRGenerator? >> On Hsail, we can't support an implicit exception for this like amd64 does so I think we would just want to end up with an explicit compare and branch if null to something that would be similar to the code emitted for a deoptimizing node. How much of that does NullCheckOp have to do? >> >> -- Tom > From tom.deneau at amd.com Sat Dec 28 07:00:11 2013 From: tom.deneau at amd.com (Deneau, Tom) Date: Sat, 28 Dec 2013 15:00:11 +0000 Subject: NullCheckOp In-Reply-To: <967BFE02-87CC-46B9-9D6B-4E5B4934E3B9@oracle.com> References: <967BFE02-87CC-46B9-9D6B-4E5B4934E3B9@oracle.com> Message-ID: Thomas -- I tried -G:-OptImplicitNullChecks, it did not make any difference. I think the problem is here: private static void processBlock(Block block, SchedulePhase schedule, int implicitNullCheckLimit) { if (OptImplicitNullChecks.getValue() && implicitNullCheckLimit > 0) { new UseImplicitNullChecks(implicitNullCheckLimit).processNodes(block, schedule); } new LowerGuards(block).processNodes(block, schedule); } In that we still go thru LowerGuards.processNodes which eventually gets to GuardNode.lowerGuard and the if block conditions are all met here so the NullCheckNode is created... public FixedWithNextNode lowerGuard() { if (negated() && condition() instanceof IsNullNode) { IsNullNode isNull = (IsNullNode) condition(); NullCheckNode nullCheck = graph().add(new NullCheckNode(isNull.object())); setCondition(null); if (isNull.usages().isEmpty()) { isNull.safeDelete(); } return nullCheck; } return null; } I have confirmed that if I force GuardNode.lowerGuard to just return null, the explicit null comparison and deopt node works correctly. -- Tom > -----Original Message----- > From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] > Sent: Saturday, December 28, 2013 6:41 AM > To: Deneau, Tom > Cc: graal-dev at openjdk.java.net; Christian Thalinger > Subject: Re: NullCheckOp > > Tom, > > The flag "OptImplicitNullChecks" controls whether the compiler tries to > create implicit null check instructions. If you set it to false, the > code generated is equivalent to a comparison of the value against null > and a deoptimization if the comparison yields true. > > - thomas > > On 24 Dec 2013, at 03:45, Christian Thalinger > wrote: > > > I'm not an expert on this but it seems that a NullCheckOp (or a > NullCheckNode) only does an implicit null check; there is no branch > information attached to it. > > > > In order to do an explicit exception you'd need to add nodes to the > graph that throw the exception. Not sure if something like this exists > already. > > > > On Dec 23, 2013, at 1:24 PM, Deneau, Tom wrote: > > > >> I am trying to get null checks working on the hsail backend. > >> What is required of NullCheckOp in the HSAILLIRGenerator? > >> On Hsail, we can't support an implicit exception for this like amd64 > does so I think we would just want to end up with an explicit compare > and branch if null to something that would be similar to the code > emitted for a deoptimizing node. How much of that does NullCheckOp have > to do? > >> > >> -- Tom > > > From doug.simon at oracle.com Sat Dec 28 18:00:18 2013 From: doug.simon at oracle.com (doug.simon at oracle.com) Date: Sun, 29 Dec 2013 02:00:18 +0000 Subject: hg: graal/graal: 17 new changesets Message-ID: <20131229020135.8E7DD62F7A@hg.openjdk.java.net> Changeset: 69f3251332c9 Author: Doug Simon Date: 2013-12-22 22:34 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/69f3251332c9 modified eclipseinit and netbeansinit to save all created/copied/downloaded project related files in zip files ! mxtool/mx.py Changeset: 108ba3e82d3a Author: Michael Van De Vanter Date: 2013-12-22 15:12 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/108ba3e82d3a Truffle: add TextMap tests + graal/com.oracle.truffle.api.test/src/com/oracle/truffle/api/test/utilities/TextMapTest.java Changeset: 4a3628c79ff9 Author: Doug Simon Date: 2013-12-23 12:55 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/4a3628c79ff9 separated external libs out from zipped up IDE configs ! mxtool/mx.py Changeset: e6309fde98c8 Author: Doug Simon Date: 2013-12-23 20:57 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/e6309fde98c8 exposed ForceUnreachable to Graal and used it when emitting safepoint polling code ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotSafepointOp.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java Changeset: 37f0c86f58d4 Author: Doug Simon Date: 2013-12-23 21:21 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/37f0c86f58d4 fixed bug when safepoint polling page is not within 32-bit offset of code cache (exposed by -XX:+ForceUnreachable_ ! graal/com.oracle.graal.hotspot.amd64/src/com/oracle/graal/hotspot/amd64/AMD64HotSpotSafepointOp.java Changeset: fe03864a2c72 Author: twisti Date: 2013-12-25 12:14 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/fe03864a2c72 replaced CompilerToVM.getUniqueImplementor with getKlassImplementor and moved the logic into Java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 606959535fd4 Author: twisti Date: 2013-12-25 20:27 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/606959535fd4 remove Graal mirror from Class ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotVMConfig.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/VMToCompilerImpl.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedJavaType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedObjectType.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotResolvedPrimitiveType.java ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/graal/graalCompiler.cpp ! src/share/vm/graal/graalCompiler.hpp ! src/share/vm/graal/graalCompilerToVM.cpp ! src/share/vm/graal/vmStructs_graal.hpp Changeset: 6215ff792647 Author: Doug Simon Date: 2013-12-26 12:07 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/6215ff792647 put warning about missing Eclipse metadata directory behind -v option ! mxtool/mx.py Changeset: d3bd7a3bbb2b Author: Doug Simon Date: 2013-12-26 14:13 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/d3bd7a3bbb2b added support for JDT environment variable which forces all Java source compilation to use the Eclipse batch compiler, including compilation as part of other commands such as eclipseinit ! mxtool/mx.py Changeset: 7824f0c4dfcd Author: twisti Date: 2013-12-26 12:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/7824f0c4dfcd removed unused class definitions in graalJavaAccess.hpp ! src/share/vm/graal/graalJavaAccess.hpp Changeset: 37ec2cabf397 Author: twisti Date: 2013-12-26 12:37 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/37ec2cabf397 moved JavaType creation in CompilerToVM.lookupType into Java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotGraalRuntime.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVM.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/bridge/CompilerToVMImpl.java ! src/share/vm/graal/graalCompilerToVM.cpp Changeset: 079222c56786 Author: Doug Simon Date: 2013-12-27 20:47 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/079222c56786 added [netbeans|eclipse]-config*.zip to .hgignore ! .hgignore Changeset: 04a87dc2cfca Author: Doug Simon Date: 2013-12-27 23:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/04a87dc2cfca refactored common code into a separate function ! src/cpu/x86/vm/graalCodeInstaller_x86.hpp Changeset: 441b54753cda Author: Doug Simon Date: 2013-12-27 23:25 +0100 URL: http://hg.openjdk.java.net/graal/graal/rev/441b54753cda fixed grammar in comment ! mx/mx_graal.py Changeset: c5449c0d5909 Author: Christian Wimmer Date: 2013-12-27 15:11 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/c5449c0d5909 Move class SystemIdentityHashCodeNode to its own Java file to work around javac bug when compiling the inner class + graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemIdentityHashCodeNode.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/replacements/SystemSubstitutions.java Changeset: 83adefeb8e5c Author: Christian Wimmer Date: 2013-12-27 15:12 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/83adefeb8e5c The runtime cannot always compare two constants ! graal/com.oracle.graal.api.meta/src/com/oracle/graal/api/meta/ConstantReflectionProvider.java ! graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/meta/HotSpotConstantReflectionProvider.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/IfNode.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/calc/Condition.java ! graal/com.oracle.graal.nodes/src/com/oracle/graal/nodes/java/TypeSwitchNode.java Changeset: 780d53499ca2 Author: Christian Wimmer Date: 2013-12-27 17:13 -0800 URL: http://hg.openjdk.java.net/graal/graal/rev/780d53499ca2 merge From miguelalfredo.garcia at epfl.ch Sun Dec 29 09:48:55 2013 From: miguelalfredo.garcia at epfl.ch (Garcia Gutierrez Miguel Alfredo) Date: Sun, 29 Dec 2013 17:48:55 +0000 Subject: is this unreachable code? (ConditionalEliminationPhase) Message-ID: <7E4228B446372948BBB2916FC53FA49E26DFC167@REXMD.intranet.epfl.ch> There appears to be unreachable code in ConditionalEliminationPhase. I've included comments in-line, below. -- Miguel Garcia Swiss Federal Institute of Technology EPFL - IC - LAMP1 - INR 328 - Station 14 CH-1015 Lausanne - Switzerland http://lamp.epfl.ch/~magarcia/ diff -r 72e2ec923b7b graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java --- a/graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Sat Dec 21 13:47:36 2013 +0100 +++ b/graal/com.oracle.graal.phases.common/src/com/oracle/graal/phases/common/ConditionalEliminationPhase.java Sun Dec 29 18:44:15 2013 +0100 @@ -395,7 +395,7 @@ } } - private void registerGuard(GuardNode guard) { + private void registerGuard(final GuardNode guard) { LogicNode condition = guard.condition(); ValueNode existingGuards = guard.negated() ? state.falseConditions.get(condition) : state.trueConditions.get(condition); @@ -407,6 +407,9 @@ ValueNode anchor = state.trueConditions.get(condition); if (anchor != null) { if (!guard.negated()) { + // Unreachable: + // `!guard.negated() && state.trueConditions.get(condition) != null` + // already covered by then-branch of this method's first `if`. guard.replaceAtUsages(anchor); metricGuardsRemoved.increment(); GraphUtil.killWithUnusedFloatingInputs(guard); @@ -415,6 +418,9 @@ anchor = state.falseConditions.get(condition); if (anchor != null) { if (guard.negated()) { + // Unreachable: + // `guard.negated() && state.falseConditions.get(condition) != null` + // already covered by then-branch of this method's first `if`. guard.replaceAtUsages(anchor); metricGuardsRemoved.increment(); GraphUtil.killWithUnusedFloatingInputs(guard); From java at stefan-marr.de Mon Dec 30 09:41:28 2013 From: java at stefan-marr.de (Stefan Marr) Date: Mon, 30 Dec 2013 18:41:28 +0100 Subject: Truffle: Uncommon Traps in Graal graph code, TimSort Message-ID: <2D3708E0-F488-4C72-979C-AEF58B0E5174@stefan-marr.de> Hi: I?ll report later on all the changes in TruffleSOM. So just briefly: it is slowly getting faster. My actual question is related to strange behavior I am seeing. On benchmarks like DeltaBlue, Richards, and also: ./mx.sh --vm server vm -G:+TraceTruffleExpansion -G:+TraceTruffleExpansionSource -XX:+TraceDeoptimization -G:-TruffleBackgroundCompilation -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes:../som/libs/truffle.jar som.vm.Universe -cp ../som/Smalltalk:../som/Examples/Benchmarks/Richards ../som/Examples/Benchmarks/BenchmarkHarness.som FieldLoop 10 10 6000 [Please note in the command line, I adopted the truffle.jar, which changes the line slightly compared to previous examples posted.] I see a lot of: Uncommon trap occurred in com.oracle.graal.nodes.MergeNode$1::apply Uncommon trap occurred in com.oracle.graal.graph.iterators.NodePredicates$AndPredicate::apply Uncommon trap occurred in com.oracle.graal.virtual.phases.ea.PartialEscapeClosure$MergeProcessor::mergeObjectStates Uncommon trap occurred in com.oracle.graal.lir.LIRIntrospection::forEach Uncommon trap occurred in java.util.TimSort::sort and similar traps. This looks strange to me. Is this supposed to happen? One thing I feel might be the issue is that the benchmarks cause many recompilations because of long phases of specialization. From my subjective feeling, the inlining in TruffleSOM is rather slow, i.e., happens rather later. And it proper gates up the call tree which leads to many re-inlining/re-specialization of in the middle and at the bottom of the tree. So, reaching steady state takes pretty long. And I am talking here about many many iterations before it stabilizes, which results in long warmup times rather on the side of minutes than seconds. Something as simple as the WhileLoop benchmarks takes 30s. So, that?s perhaps unrelated to the original question of whether those uncommon traps in Graal code should happen. For the warmup, could it be that Smalltalk?s ?make a method not longer than 7 lines? could require different thresholds for inlining etc.? Thanks and best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 From christian.humer at gmail.com Mon Dec 30 11:13:18 2013 From: christian.humer at gmail.com (Christian Humer) Date: Mon, 30 Dec 2013 20:13:18 +0100 Subject: Truffle: Uncommon Traps in Graal graph code, TimSort In-Reply-To: <2D3708E0-F488-4C72-979C-AEF58B0E5174@stefan-marr.de> References: <2D3708E0-F488-4C72-979C-AEF58B0E5174@stefan-marr.de> Message-ID: Hi Stefan, I don't know exactly where the uncommon traps are coming from. Maybe someone else can have a look at it? I am also not sure if this is in fact a problem. Regarding the inlining heuristic. At the moment the Truffle inlining heuristic relies on re-profiling of the CallTarget after each inlining step. This requires the compilation to be delayed for some iterations and often this has very unfortunate effects on the timing of compilations. As you said its propagating up the call tree, which is clearly not what we want. As with TruffleSOM this effect as you mentioned may be even bigger due to the number of methods used even for simple constructs. As of now the heuristic was primarily focused on peak performance and not on startup. I also suspect that startup time may get better as soon as TruffleSOM compiles more specialized code. We are currently working on solutions to improve inlining startup and we expect to improve it by factors (its not tuned for that at all). We also plan to expose some additional language specific tuning opportunities for the inlining heuristic. There are already some interesting options available which you can experiment with. For a complete list see class TruffleCompilerOptions. To debug the inline decisions you can put a breakpoint in TruffleInliningImpl#InliningPolicy#isWorthInlining. It may also be the case that your implementation of the InlininableCallSite interface may return wrong or incomplete data which may also result in a bad inlining decision. To improve this situation a bit I recommend you (this is also what I think Chris Seaton with Ruby is doing) to force inline core methods like whileTrue (Don't know if TruffleSOM already does that). Please see the inlineImmediatly flag in SL FunctionRootNode on how forced inlining can be done. (see also CallNode#UninitializedCallNode#specialize) Cheers and a happy new year, - Christian Humer On Mon, Dec 30, 2013 at 6:41 PM, Stefan Marr wrote: > Hi: > > I?ll report later on all the changes in TruffleSOM. So just briefly: it is > slowly getting faster. > > My actual question is related to strange behavior I am seeing. > > On benchmarks like DeltaBlue, Richards, and also: > ./mx.sh --vm server vm -G:+TraceTruffleExpansion > -G:+TraceTruffleExpansionSource -XX:+TraceDeoptimization > -G:-TruffleBackgroundCompilation -G:+TraceTruffleCompilationDetails > -Xbootclasspath/a:../som/build/classes:../som/libs/truffle.jar > som.vm.Universe -cp ../som/Smalltalk:../som/Examples/Benchmarks/Richards > ../som/Examples/Benchmarks/BenchmarkHarness.som FieldLoop 10 10 6000 > > [Please note in the command line, I adopted the truffle.jar, which changes > the line slightly compared to previous examples posted.] > > I see a lot of: > > Uncommon trap occurred in com.oracle.graal.nodes.MergeNode$1::apply > Uncommon trap occurred in > com.oracle.graal.graph.iterators.NodePredicates$AndPredicate::apply > Uncommon trap occurred in > com.oracle.graal.virtual.phases.ea.PartialEscapeClosure$MergeProcessor::mergeObjectStates > Uncommon trap occurred in com.oracle.graal.lir.LIRIntrospection::forEach > Uncommon trap occurred in java.util.TimSort::sort > > and similar traps. > > This looks strange to me. Is this supposed to happen? > > One thing I feel might be the issue is that the benchmarks cause many > recompilations because of long phases of specialization. From my subjective > feeling, the inlining in TruffleSOM is rather slow, i.e., happens rather > later. And it proper gates up the call tree which leads to many > re-inlining/re-specialization of in the middle and at the bottom of the > tree. So, reaching steady state takes pretty long. And I am talking here > about many many iterations before it stabilizes, which results in long > warmup times rather on the side of minutes than seconds. Something as > simple as the WhileLoop benchmarks takes 30s. > > So, that?s perhaps unrelated to the original question of whether those > uncommon traps in Graal code should happen. For the warmup, could it be > that Smalltalk?s ?make a method not longer than 7 lines? could require > different thresholds for inlining etc.? > > Thanks and best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > From andreas.woess at jku.at Mon Dec 30 13:13:01 2013 From: andreas.woess at jku.at (Andreas Woess) Date: Mon, 30 Dec 2013 22:13:01 +0100 Subject: Truffle: Uncommon Traps in Graal graph code, TimSort In-Reply-To: <2D3708E0-F488-4C72-979C-AEF58B0E5174@stefan-marr.de> References: <2D3708E0-F488-4C72-979C-AEF58B0E5174@stefan-marr.de> Message-ID: <52C1E1DD.7000706@jku.at> Hi Stefan, the uncommon traps are expected behavior and the result of optimistic optimizations, here in the Graal compiler itself. I'm not familiar with your code base, but I suspect that you don't report loop counts in your while loop implementation. The main trigger for compilation is the compilation threshold, which is currently set to 1000 (see the TruffleCompilerOptions class for more options). Methods that have long-running loops and don't report their loop counts are only compiled if the method that contains the loop itself is called >1000 times. See the following exemplary implementation of a while loop for how you can report loop iteration counts: WhileNode::execute(VirtualFrame frame) { int count = 0; try { while (executeCondition(frame)) { executeBody(frame); if (CompilerDirectives.inInterpreter()) { count++; } } } finally { if (CompilerDirectives.inInterpreter()) { reportLoopCount(count); } } } and the reportLoopCount method would be: private void reportLoopCount(int count) { CompilerAsserts.neverPartOfCompilation(); RootNode rootNode = this.getRootNode(); if (rootNode != null && rootNode.getCallTarget() instanceof LoopCountReceiver) { ((LoopCountReceiver) rootNode.getCallTarget()).reportLoopCount(count); } } This should help methods with long loops be compiled earlier (and also quicken inlining). Let me know if this helps. Regarding the previous email thread, let's try, as Chris suggested, to optimize a simple benchmark like fannkuch (which we know performs well in other Truffle languages). We can provide some assistance after the holidays. Happy new year, - Andreas On 30.12.2013 18:41, Stefan Marr wrote: > Hi: > > I?ll report later on all the changes in TruffleSOM. So just briefly: it is slowly getting faster. > > My actual question is related to strange behavior I am seeing. > > On benchmarks like DeltaBlue, Richards, and also: > ./mx.sh --vm server vm -G:+TraceTruffleExpansion -G:+TraceTruffleExpansionSource -XX:+TraceDeoptimization -G:-TruffleBackgroundCompilation -G:+TraceTruffleCompilationDetails -Xbootclasspath/a:../som/build/classes:../som/libs/truffle.jar som.vm.Universe -cp ../som/Smalltalk:../som/Examples/Benchmarks/Richards ../som/Examples/Benchmarks/BenchmarkHarness.som FieldLoop 10 10 6000 > > [Please note in the command line, I adopted the truffle.jar, which changes the line slightly compared to previous examples posted.] > > I see a lot of: > > Uncommon trap occurred in com.oracle.graal.nodes.MergeNode$1::apply > Uncommon trap occurred in com.oracle.graal.graph.iterators.NodePredicates$AndPredicate::apply > Uncommon trap occurred in com.oracle.graal.virtual.phases.ea.PartialEscapeClosure$MergeProcessor::mergeObjectStates > Uncommon trap occurred in com.oracle.graal.lir.LIRIntrospection::forEach > Uncommon trap occurred in java.util.TimSort::sort > > and similar traps. > > This looks strange to me. Is this supposed to happen? > > One thing I feel might be the issue is that the benchmarks cause many recompilations because of long phases of specialization. From my subjective feeling, the inlining in TruffleSOM is rather slow, i.e., happens rather later. And it proper gates up the call tree which leads to many re-inlining/re-specialization of in the middle and at the bottom of the tree. So, reaching steady state takes pretty long. And I am talking here about many many iterations before it stabilizes, which results in long warmup times rather on the side of minutes than seconds. Something as simple as the WhileLoop benchmarks takes 30s. > > So, that?s perhaps unrelated to the original question of whether those uncommon traps in Graal code should happen. For the warmup, could it be that Smalltalk?s ?make a method not longer than 7 lines? could require different thresholds for inlining etc.? > > Thanks and best regards > Stefan >